O que são User Stories (Estórias de Usuário)?

Quando dizemos que no framework Scrum não existe documentação, não é verdade! O que precisa é de uma documentação mínima necessária para o desenvolvimento de produtos! E uma “User Story” (estória de usuários) faz parte dessa documentação mínima.

Quando usamos a metodologia cascata (waterfall), no início da execução do projeto fazemos o levantamento de todos os requisitos de negócio, e registramos em um documento que chamamos de “Definição de Negócio”, com isso, geramos uma documentação gigantesca e aí sim, partimos para o desenvolvimento.

Caso precise alterar algum desses requisitos é considerado uma “Mudança de Escopo”, que precisamos documentar a alteração e solicitar aprovação, e claro, em TODO projeto isso acontece.  E é obvio, que tudo isso gera um grande desperdício financeiro para o seu projeto.

Já nas metodologias ágeis, criamos as “User Stories” para registrarmos esses requisitos,

onde descrevemos uma necessidade de negócio na linguagem do usuário, de uma forma simples e de fácil entendimento. Teremos uma “User Story” para cada item do Product Backlog.

Como construir uma User Story?

Existe um conceito chamado de “3 C’s”, que indica como construir a sua estória de usuário.  Neste artigo vou assumir que você, como PO, e o seu time Scrum, já criou e priorizou o seu Product Backlog e vão criar uma “User Story” para cada item.  Então vamos aos 3 C’s:

• Cartão: Claro que atualmente não usamos um cartão, e sim, ferramentas desenvolvidas para essa finalidade, mas o conceito do cartão ainda é mantido, que indica que a descrição estória deve ser curta e simples, e se não couber em um cartão, pode ser indício que ela precisa ser dividida. E o que deve conter na descrição da sua estória?
  • Quem: definir quem é o ator. Ex.: Eu, como vendedor…;
  • O que: definir qual é o objetivo. Ex: Quero validar o CNPJ do meu cliente na Receita Federal…;
  • Por que?: É a justificativa para o objetivo, é opcional, mas pode ajudar fornecendo mais conhecimento para o time. Ex: Evitar fraudes e que o concorrente peça propostas para descobrir nosso preço de venda.
• Conversas: São conversas (“reuniões”) onde o PO, o time de desenvolvimento e até um Q.A. (se houver) conversam sobre como fazer para atender o que o Cartão solicita. É a hora de determinar a solução que será desenvolvida. E também um momento para esclarecer as dúvidas.
• Confirmação: É necessário ter critérios de aceites que vão ajudar a determinar que uma estória está concluída. São cenários que quando executados, se obtiverem os resultados descritos, está OK, caso contrário será devolvido para o time de desenvolvimento corrigir os bugs.

Você também poderá utilizar um outro conceito que vai te ajudar a avaliar a qualidade da sua “User Story”, que é um acrônimo recomendado por um dos pais do Scrum que é o INVEST:

• Independente: Sua estória precisa ser independente, isto é, não pode depender de outra estória para ser construída;
• Negociável: Tem que ser possível negociar, ser passível de alteração, não um contrato imutável;
• Valor: Tem que agregar valor ao negócio;
• Estimável: Ser possível que o time possa estimar o desenvolvimento;
• Smal (Pequena): Ela deve caber dentro de uma Sprint, e você precisa lembrar que uma estória pequena, é mais fácil de estimar. Se o seu time não compreender a estória, eles vão jogar a estimativa para o céu!
• Testável: Tem que ser testável, se o PO não souber como testar uma estória, pode ser indício que ela está mal descrita.

Como escrever?

Passo 01: Manter o Product Backlog atualizado e visível a todos!

Passo 02:  Descrever o Product Backlog do seu projeto, conforme exibido na tabela abaixo:

Você pode criar um código de identificação (ID), o item do Backlog (Estória) e a indicação em qual Sprint está planejado o desenvolvimento. E agora vamos ao que é o “escopo” deste artigo, o que deve conter em uma User Story?

Passo 03: Registrar as User Stories.

Como você pode ver, é possível registrar “O que” o negócio necessita, e o “por que”.  Tem o espaço para todo o time detalhar a solução, e mais abaixo como será o executado os testes para que a estória seja dada como concluída!

Vale ressaltar que aqui não estou levando em conta a ferramenta, mas sim a forma, o método. Ferramentas temos aos montes no mercado. A mais utilizada hoje é o Jira, mas existem várias outras opções, inclusive gratuítas! 😊

Granularidade: Temas, Épicos, Features, Estórias, Tarefas)

A imagem abaixo resume claramente como estruturamos os ítens de backlog, segundo refinamento. Quanto mais granulado, ou seja, mais quebrado e refinado, mais elegível a priorização:

A tríade Épico, Feature e User Story são os artefatos mais utilizados para estruturação de backlog de produto (product backlog) e para uso em backlog de sprints (sprint backlog).

Muitas das organizações que estando estão caminhando para um processo produtivo orientado ao mindset ágil se utilizam desses artefatos para tratar o escopo de seus produtos de software.

Para compararmos, antes de começarmos a falar mais sobre cada um dos três artefatos, vamos fazer uma rápida comparação destes artefatos com outros equivalentes utilizados em empresas com processos mais tradicionais.

Um Épico é o equivalente ao conceito de Módulo. Requisitos Não Funcionais geralmente atendem/suportam mais de um Requisito Funcional ou funcionalidade do sistema.

Na visão dos três artefatos, os Requisitos Não Funcionais equivalem a Features (afinal o aspecto não funcional do produto também é parte do produto) e seu escopo é representado em User Stories (geralmente chamamos de “estórias técnicas) quebradas e de menor tamanho.

Estória de Usuário

Uma User Story é a representação clara e informal que expressa a necessidade e/ou requisito de um potencial usuário. Também pode ser considerada uma parte de um objetivo final. A User Story é a menor unidade de trabalho com base na necessidade do cliente final que vai utilizar e/ou interagir com o Produto.

O Backlog do Produto normalmente é representado por uma lista de estórias ordenadas por valor de negócio. O Dono do Produto é o único responsável pelo Gerenciamento, Priorização e Atualização do Backlog, porém todas as partes envolvidas podem cooperar com suas ideias, sugestões e críticas.

Funcionalidade

A Funcionalidade ou Característica (Feature) é responsável por agrupar um conjunto de estórias de usuário. A Funcionalidade expressa uma função do Produto, da qual contém diversos requisitos funcionais com suas regras e exceções.

A Feature está relacionada a uma Funcionalidade em médio ou alto nível dentro do Produto e por isso precisa de requisitos funcionais e não funcionais expressos por User Story. Quando todas as estórias da Funcionalidade estiverem prontas, considera-se a Feature concluída.

A responsabilidade do gerenciamento do Backlog de Features também é do Product Owner e é altamente utilizado para organizar o seu dia a dia. Algumas organizações não utilizam a organização por Features, mas somente a relação Épico x Estórias.

Épico

O Épico (Epic) é uma grande parte do trabalho a ser realizado no Produto. É também conhecido como uma Grande Estória de Usuário, da qual expressa de forma macro a necessidade global.

O épico representa uma parte integral do Produto e deve ser suficiente para ter valor de negócio em sua utilização. Todos os épicos devem representar a entrega integral do Produto. Os Epics são formados por Features, ou seja, após a entrega de todas as funcionalidades, considera-se que o Épico esteja finalizado.

A responsabilidade do Gerenciamento do Backlog do Produto depende do modelo de Projetos da organização a depender da estratégia e direcionamento de Negócio.

• Em alguns casos o Product Owner é o próprio responsável, permitindo-o o total empoderamento sobre as decisões.
• Em outros locais, onde a organização mantém a estratégia do Produto na alta gerência, a responsabilidade do Gerenciamento dos Epics é do Product Manager, Business Owner ou algum profissional equivalente.

Cada um no seu papel!

O Product Owner precisa entender que quem vai definir a solução e a melhor forma de desenvolver o produto será o time de desenvolvimento. O PO precisa ter a capacidade de entender e conversar com os usuários, levantar os épicos, funcionalidades e estórias consistentes conforme tudo que apresentamos por aqui, além de priorizar o Backlog do Produto com qualidade e sempre visando o valor da entrega.

Sendo o PO o principal responsável por todas estas atividades, aprender sobre essa tríade ou qualquer outro modelo de estruturação de Backlog é imprescindível para um bom trabalho em qualquer framework ágil, bem como a transparência e apresentação do trabalho a ser realizado para o time de desenvolvimento, visto que é deste papel a missão de dar a visibilidade do valor entregue pelo time.

Conclusão

Neste artigo falamos um pouco sobre user stories e a importância de uma boa granularidade.

O assunto não se esgota aqui e este artigo é apenas uma referência geral, para ajudar a quem precisa.

Fique à vontade comentar, e claro, no que estiver ao meu alcance, estou aqui para ajudar, ou ao menos trocar algumas figurinhas! 😉

Mas lembre-se: Agilidade não é post-it na parede, é atitude, mentalidade, cultura!