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!
BAIXE NOSSO E-BOOK GRATUÍTO!
Sobre o Autor
1 Comentário
Parabéns pelo artigo, ficou muito bom,
tenho uma dúvida:
No caso de uma História do usuario, exemplo: “Efetuar Login” , que já está em produção.
Ai cliente solicita criar mais um campo no “Efetuar Login” com o campo “data de expiração”, que deverá ser superior a Data de Hoje.
Aí o analista deve criar essa historia do “Data Expiração” onde?
Ou deve atualiza a antiga?
Caso for criar a nova ele deixa as 2 relacionas?
Pra quando o desenvolvedor for alterar o código saber agora é responsável por 2 historias?
Muito obrigado