As histórias de usuários compõem o coração do desenvolvimento ágil. Elas são o principal input para a equipe scrum. Eles pegam as histórias de usuários e criam incrementos de produto baseados na conclusão dessas histórias. Infelizmente, acertar histórias de usuários não é tão fácil.
Você pode saber mais informações sobre histórias de usuários aqui:
Os proprietários dos produtos precisam aprender como criar histórias de usuários que atendam às necessidades da equipe. Para criar boas histórias de usuários, comece por lembrar de INVESTIR em boas histórias de usuários. INVEST é uma sigla que engloba os seguintes conceitos que compõem uma boa história de usuário:
Independente: Um Produto Backlog Item (PBI) deve ser auto-contido.
Negociável: Deve deixar espaço para discussão.
Valuável: Deve fornecer valor para os interessados.
P>Possuitivo: Deve sempre ser capaz de estimar o tamanho de um PBI.
Pequeno: Deve assim ser capaz de planear, executar e priorizar.
P>Testável: O desenvolvimento deve ser capaz de ser testado.
Stories deve ser tão independente quanto possível e você deve ser capaz de trabalhar neles em qualquer ordem. Isto permite uma verdadeira priorização de cada história. Quando as dependências entram em jogo, pode não ser possível implementar uma história valiosa sem implementar outras histórias muito menos valiosas.
Negociável
Uma boa história é negociável e não um contrato. Uma boa estória é um convite para uma conversa. Uma boa estória capta a essência do que é desejado. O resultado real precisa ser o resultado de uma negociação colaborativa entre o Proprietário do Produto e a equipe de desenvolvimento. O objetivo é atender as necessidades do cliente.
Valorizável
As histórias dos usuários devem ser priorizadas no backlog de acordo com o valor do negócio. A criação de itens de backlog de produtos que são realmente divertidos de codificar, mas que não trazem nenhum valor para as partes interessadas, viola um dos Princípios Ágeis, que é entregar continuamente software valioso
Estimável
Os desenvolvedores precisam ser capazes de estimar uma história. Ela deve ser escrita de forma que os desenvolvedores possam entendê-la e ter uma idéia de como implementá-la. Os factores chave para a estimativa são o conhecimento do domínio e o conhecimento técnico.
Small
As boas histórias tendem a ser pequenas, mas quão pequenas devem ser? A resposta depende da equipe e da metodologia que está sendo utilizada. Muitos Proprietários de Produtos sugerem duas iterações semanais, que permitem histórias de usuários de três ou quatro dias médios de trabalho. Isto inclui todo o trabalho para levar a história a um estado “feito”.
Testável
Estórias devem ser testáveis para ajudar a determinar a completude. Uma história deve ter um critério de aceitação. O critério de aceitação deve ser objetivo. Evite usar critérios como, fácil de usar, rápido ou livre de bugs. Try to write criteria that can be measured and tested.
Via: