Divisão de histórias – refinamento para uma granularidade ideal
Uma história aparentemente pequena pode acabar sendo muito maior do que o esperado. Somente através do refinamento ou da divisão da história você pode descobrir isso. A divisão da história pode ser feita no início ou logo antes do sprint anterior. Recomendamos fazê-lo o mais cedo possível para evitar surpresas tardias.
Consideramos a “divisão de histórias” e o “refinamento de histórias” como atividades muito semelhantes. Trata-se de otimizar a granularidade da história de usuário escrita.
O que são histórias de usuários
Para as equipes que conseguem co-localizar, a história do usuário pode ser apenas um lembrete de uma conversa. Na maioria das circunstâncias, contamos com a história do usuário como requisito funcional escrito. Para ser eficaz no fornecimento comunicação clara as histórias de usuários devem ser cuidadosamente escritas para minimizar mal-entendidos. Mas primeiro devemos entender como as histórias de usuários se enquadram no contexto mais amplo (hierarquia) de comunicação do que precisa ser feito para fornecer valor aos usuários:
O contexto das histórias de usuários
Uma história de usuário completa
Tendo estabelecido esse contexto, podemos agora ver onde as histórias de usuários se encaixam. O contexto dentro da hierarquia ajuda a entender o que é necessário em uma história de usuário, para que ela seja bem formada e de boa qualidade. Uma história de usuário completa deve:
- especifique um usuário ou pessoa deve ser especificado.
- descreva o funcionalidade de alto nível a ser executado como parte de uma única ação funcional discreta pelo usuário.
- incluir todas as etapas funcionais necessário para atender aos requisitos do usuário.
Quando fazer a divisão da história
Idealmente, o mais cedo possível no ciclo de vida do software. Não é tão oneroso como muitos afirmam e raramente é uma atividade dispendiosa. Confira nosso artigo no blog sobre atributos de qualidade de história de usuário recomendados
Técnicas para divisão de histórias
Pense primeiro quem é o usuário e quais tipos de dados eles precisam manipular para atingir um requisito específico que deixe o sistema em um estado estável no final.
Usuário – Orientado
Esta história descreve a funcionalidade de uma persona ou grupos de personas?
Mensurável (etapas funcionais claras)
Para sermos mensuráveis ou dimensionáveis, precisamos conhecer a funcionalidade em termos de grupos de dados que estão sendo tratados. por exemplo
como usuário registrado posso atualizar meu perfil.
Para mensurabilidade recomendamos o padrão de dimensionamento funcional COSMIC, que exige que os objetos de interesse sejam identificados.
Completo
Mencionamos todos os grupos de dados necessários para esta história? Se tivermos que pesquisar alguns dados de outro lugar, isso também precisará ser incluído. Muitas histórias de usuário exigem diversas pesquisas de dados antes que um tipo de objeto seja criado ou atualizado.
Regras do negócio
As regras de negócios geralmente são restrições baseadas no contexto ou em dados referenciados. Certifique-se de incluir todos os tipos de dados referenciados em sua história de usuário funcional. Ocasionalmente, as regras de negócios forçam uma história a ser dividida em duas histórias semelhantes. Às vezes, o contexto pode ser apresentado combinando o nome do usuário com um status específico, por exemplo, logado_user_with_cart_items
Conciso
Às vezes, especificamos demais uma história de usuário com todos os critérios de aceitação antes de acertarmos o básico. Evite fazer isso muito cedo.
