Re-estimativa de histórias do Scrum

Todos os dias, após o stand-up , minha equipe e eu atualizamos nossas estimativas para cada história. Sinto que há algo errado com a maneira como fazemos isso, então preciso da sua ajuda.

É assim que nós fazemos:

História Uma estimativa: 24 horas (8 horas por dia - usamos os "dias ideais" como medida)

• Dia N: o desenvolvedor começa a trabalhar na História A pela manhã (8 horas de trabalho concluídas até o final do dia)
• Dia N + 1: Re-estimativa da História A = 16 horas (um dia útil retirado da História A, do dia N)
• Dia N + 2: Re-estimativa da História A = 8 horas (um dia útil retirado da História A, do dia N + 1)
• Dia N + 3: A história A deve estar pronta agora. Mas isso não. O desenvolvedor calcula que levará mais 3 horas para concluir. Atualizamos a história no quadro branco e o burndown de acordo.
• Dia N + 4: História A demorou o dia inteiro para terminar em vez de apenas 3 horas! Agora está feito. A diferença, 5 horas, é completamente inexplicável em nosso planejamento.

Como devemos reestimar diariamente nossas histórias?

A diferença, 5h, é completamente inexplicável em nosso planejamento.

Sim, é considerado implicitamente porque as tarefas a seguir estão atrasadas. Se houvesse um gráfico de burndown apenas para esse desenvolvedor, você notaria que a curva permaneceu "plana" por um dia, enquanto teria diminuído se o desenvolvedor o tivesse terminado cedo o suficiente para executar outra tarefa.

Não há nada errado com a maneira como você está re-estimando durante a reunião diária, a re-estimativa é mais sobre descobrir se podemos chegar até o final do sprint do que sobre rastrear o atraso exato de cada tarefa. Tudo o que você precisa no Scrum para poder ajustar seu plano diariamente é algo que indica o progresso da Sprint e a que distância está do alcance da meta da Sprint (normalmente, um gráfico de burndown).

A pergunta que você deve fazer é: devemos reestimar nossas histórias?

Eu argumentaria que você deveria permitir que a "mágica" do Agile equilibre suas sub e superestimações em uma iteração ao calcular sua velocidade para a próxima (que é a única razão para corrigir um valor). Consulte Estimativa e planejamento ágeis de Mike Cohn para obter mais informações.

No entanto, há um caso em que você deve reestimar: onde algo que você aprendeu sobre uma categoria de trabalho ajusta todas as estimativas daqui para frente.

por exemplo. Estima-se que a adição de uma coluna a um banco de dados leva uma hora ideal, mas leva 3 horas por causa de algum fator que ninguém considerou e parece que esse fator será aplicado toda vez que você adicionar um campo ao banco de dados então todas as estimativas para o trabalho dessa natureza deve ser ajustada, incluindo o que você está trabalhando.

O que eu achei mais eficaz é:

• Tamanho de histórias por pontos (ou tamanhos de camiseta).
• Reestime qualquer história na lista de pendências do produto a qualquer momento (mas especialmente antes do planejamento do sprint).
• Não re-estime as histórias que estão agendadas para este sprint - sinta-se à vontade para levantar preocupações em pé, mas não altere as estimativas.
• Use o clima de ontem para agendar sprints

Se as histórias estiverem entrando no sprint com estimativas falsas, as re-estimativas do planejamento pré-sprint permitirão corrigi-las antes que elas se tornem um problema. Se as histórias estiverem demorando mais que o esperado, porque a equipe está otimista demais, o clima de ontem o manterá nos trilhos.

As re-estimativas diárias do que resta ainda são totalmente falsas, como você descreveu na sua pergunta. O trabalho concluído / restante é um número falso, projetado para parecer que você está trabalhando "bastante". Muito melhor é perguntar: "Quando você acha que vai terminar" e deixar claro que, se houver um problema com uma história, a equipe se esforçará para ajudar.

Eu acho que isso não é um problema. Pelo contrário, pode ser falta de experiência. Quanto mais você segue o scrum, mais desenvolvedores se acostumam a fornecer estimativas mais precisas. Esta é a nossa experiência na implementação do scrum após 5 meses.

Ao planejar as sessões de pôquer , nossos desenvolvedores sugeriram estimativas muito diversas para cada PBI e cada tarefa no primeiro sprint. No entanto, agora, somos quase iguais no tempo e na estimativa. Há quanto tempo você usa o scrum? Se não for assim, dê um tempo. Mas, se demorar muito, então, como o @pdr sugeriu, considere adicionar margem extra para tarefas com maiores riscos . Por exemplo, toda vez que nossa equipe deseja criar um pedaço de navegador cruzado da interface do usuário, passamos nossa estimativa. Assim, sempre multiplicamos a estimativa de tarefas entre navegadores por um fator para garantir que possamos cobri-la.

Reestimar as histórias de usuários comprometidas durante o sprint não faz sentido. Só desperdiça seu tempo. Você já se comprometeu e não importa se você re-estimar ou não.

A situação diferente é com histórias de usuários que não estão comprometidas com o sprint atual. De tempos em tempos, é bom fazer uma nova estimativa (não mais que uma vez por sprint antes do planejamento). As situações pelas quais pode ser razoável reestimar podem ser:

• O proprietário do produto alterou qualquer história do usuário
• O proprietário do produto divide ou mescla qualquer história do usuário
• O proprietário do produto adicionou a história do usuário
• Você tem algum conhecimento adicional que não estava disponível na última história do usuário
• Você descobriu que algumas histórias de usuário estão relacionadas e já fez parte de outra ainda não confirmada
• etc.

Você não precisa necessariamente reestimar cada história de usuário, mas pode. Para uma reavaliação completa, você geralmente precisa de um método rápido. O planejamento do pôquer pode ser extremamente lento, ineficiente, chato e às vezes também impreciso se você levar mais de 10 a 20 histórias para estimar. Alternativa pode ser estimativa mágica .