Como escrever boas histórias de usuário no Scrum

Aproximadamente 70% dos projetos de tecnologia falham. Durante décadas, acredita-se amplamente que os projetos falham porque não seguem as melhores práticas ou porque a equipe carece de todas as habilidades necessárias. No entanto, a adoção de melhores práticas, habilidades e competências melhorou ao longo das décadas—então por que os projetos ainda falham?

Considerando que 70% dos projetos de software falham devido a requisitos inadequados. O retrabalho estimado associado a essas falhas ultrapassa 45 bilhões de dólares anualmente.

A pergunta é—por que isso acontece? A resposta é dupla. Primeiro, os requisitos comerciais muitas vezes perdem o foco no cliente; segundo, os requisitos carecem de um quadro de referência geral que permita aos analistas de requisitos conduzir e rastrear os requisitos desde as necessidades do cliente e a estratégia até a solução sendo implementada.

Para escrever bons requisitos ou histórias de usuário, siga estas etapas:

1. Defina o maior número possível de personas para representar os usuários do sistema.Isso ajudará você a manter o foco no cliente e a conduzir e rastrear os requisitos com base nas necessidades do cliente. Introduzidas por Alan Cooper, as personas definem usuários arquetípicos do sistema—exemplos do tipo de pessoas que interagem com ele. Os usuários não precisam ser ou representar indivíduos. Um usuário também pode representar uma organização.
2. Certifique-se de que suas histórias de usuário sigam os “3Cs”:

• Cartão — Deve ser escrito em um cartão ou nota adesiva
• Conversa — Obtenha informações detalhadas do Proprietário do Produto
• Confirmação — Certifique-se de que seja implementado corretamente. Deve atender aos critérios de aceitação do usuário.

3. Divida as histórias de usuário para que sejam de tamanho apropriado para caberem em um Sprint. Algumas formas de dividir histórias incluem:

• Dividir por etapas do fluxo de trabalho
• Dividir por canais de entrada/saída
• Dividir por opções do usuário
• Dividir por persona/função
• Dividir por faixa de dados

4. Faça com que cada história de usuário siga o mnemônico INVEST:

O ágilmnemônico INVEST, criado por Bill Wake, serve como um guia para garantir itens de alta qualidade no Product Backlog (PBIs), geralmente escritos no formato de história de usuário.

• Independente: As histórias devem ser o mais independentes possível.
• Negociável: Uma história não é um contrato. Uma história é um convite para uma conversa. A história captura a essência do que é desejado.
• Valioso: Se uma história não tiver um valor óbvio, ela não deve ser feita.
• Estimável: Uma história deve ser estimável ou dimensionada para que possa ser priorizada corretamente.
• Pequeno: Para uma iteração de duas semanas, as histórias de usuário devem ter em média de 3 a 4 dias de trabalho — no total! Isso inclui todo o trabalho necessário para levar a história ao estado “Concluído”.Quanto menor a história do usuário, maior a precisão da estimativa!
• Testável: Cada história precisa ser testável para ser considerada “Concluída”.

• Escrevendo Metas SMART e INVEST para Histórias de Usuário
• Tema vs Épico vs História de Usuário vs Tarefa
• O que é DEEP na Lista de Produto?
• Como escrever uma Visão do Produto para um Projeto Scrum?
• Como usar um Quadro Scrum para Desenvolvimento Ágil?
• Quem cria itens da Lista de Produto ou histórias de usuário no Scrum?
• O que é Estimativa Ágil?
• O que é um Ponto de História no Ágil? Como estimar histórias de usuário?
• Divisão de Histórias de Usuário – Fatia Vertical vs Fatia Horizontal