História de referência
Uma história de referência serve como suporte para uma equipe no Desenvolvimento Ágil de Produtos, ajudando a estimar o esforço de trabalho de uma User Story a ser realmente trabalhada. A história de referência é uma User Story cujos requisitos, complexidade e implementação são compreensíveis para todos os membros da equipe. Dessa forma, ela é utilizada para estimativas relativas.
Como as histórias de referência são utilizadas no Scrum?
A equipe primeiro analisa o esforço da story que serve como referência e depois a avalia com os Story Points correspondentes. Novos requisitos em forma de User Stories são então avaliados em relação ou referência ao esforço dessa história de referência. Se a equipe Scrum estimar que o esforço para implementar a nova User Story é maior, por exemplo, ela receberá mais Story Points.
Por que as histórias de referência fazem sentido para a tua equipe?
O Scrum e outros métodos ágeis não medem o esforço para implementação de tarefas em "dias-pessoa" ou tempo em geral, mas sim em Story Points abstratos. A razão é que todos os membros da equipe e outros colaboradores da empresa devem estar cientes de que as informações sobre esforço são estimativas relativas e não indicações concretas de tempo. Indicações e estimativas precisas de tempo são, em muitos casos, muito imprecisas para alcançar resultados significativos. No entanto, com a ajuda das histórias de referência e da soma de pontos em um Sprint, é possível, com alguma experiência, fazer uma estimativa adequada do esforço a ser realizado por equipe.
Como funciona a estimativa de uma User Story em relação à história de referência?
Para estimar uma story como item do Product Backlog, são utilizadas no Scrum cartas de poker especiais para o chamado Estimation Poker (também conhecido como Scrum Poker ou Planning Poker). Essa estimativa geralmente acontece, dependendo da equipe, no Refinement ou no Sprint Planning.
No Estimation Poker, cada membro da equipe recebe seu próprio baralho de cartas. Os membros então, simultaneamente, cada um por si, puxam a carta de poker com a quantidade de Story Points que consideram realista para a implementação da story. Nessa estimativa, eles se orientam pelo esforço da história de referência previamente estabelecido pelo grupo.
Após revelar as cartas e discutir eventuais diferenças nas estimativas e ideias de implementação por parte dos Developers, fica claro se a equipe deseja consultar novamente o Product Owner para esclarecimentos adicionais sobre os requisitos da story.
Dica:
Estimativas de esforço muito altas, como 40 ou 100 Story Points, indicam que a User Story pode ser dividida em várias stories.
Quando a estimativa para a User Story estiver concluída após outra rodada de Planning Poker, os Story Points estimados são registrados no item do Product Backlog como preparação para o Sprint Planning.
Conclusão sobre histórias de referência na Estimativa Ágil
Quando uma story facilmente estimável é utilizada como referência, a estimativa de novas stories pela equipe ocorre em uma base comum. Somente dessa forma os membros conseguem chegar a um esforço estimado em conjunto e posteriormente se comprometer com essas stories no Sprint.
As stories concluídas em um Sprint servem, por sua vez, para calcular a Velocity (velocidade de trabalho da equipe), com base na qual futuros Sprints podem ser planejados de forma mais eficaz.
