Minha primeira resposta é não. Vamos aos pontos:
Ponto 1 - Comparando bananas com maças
Cenário hipotético:
Time Bar
Backlog:
- Estoria A - 3 Pontos
- Estória B - 5 Pontos
- Estória C - 2 Pontos
- Estória D - 13 Pontos
- Estória E - 5 Pontos
- Estória F - 13 Pontos
- Estória G - 20 Pontos
Imaginemos que a equipe fez seu primeiro Sprint e entregou as estórias A, B e C, tendo uma velocidade de 13. Assim, começam o próximo com apenas a estória D.
Ao final do sprint a equipe percebe que, na verdade, aquela estória deveria ter sido 20, dado o esforço não previsto de trabalhar com uma biblioteca legada, por exemplo. Esses 20 pontos são registrados e passam a contar na velocidade da equipe.Então temos que a nova velocidade da equipe pode ser considerada 20, e não mais 13. Desta forma, para o próximo Sprint, a equipe deve ser capaz de incluir os itens 5 e 13, certo?
Errado. Quando estimamos os itens em uma sessão de planning, todos os itens são tratados da mesma forma, considerando apenas as informações que temos antes de iniciar o desenvolvimento. É por isso que usar Fibonacci faz todo o sentido [referencia].
Quando misturamos estas estimativas com itens já desenvolvidos e por isso re-estimados, passamos a trabalhar com medidas que não são comparáveis. Nosso backlog irá ser todo estimado com bananas, mas teremos uma maça no meio, o que bagunçará tudo.
No exemplo, o time Bar deve continuar usando a velocidade de 13 pontos para estimar os próximos Sprints.
Caso o esforço extra encontrado na estória D possa ser novamente encontrado em estórias futuras, estas podem ser re-estimadas com as lições aprendidas, a fim de melhorar a previsibilidade. Mas veja que a incerteza continua tendo seu papel.
Ponto 2 - A média resolve
Todas as estórias de peso 3 são iguais? A resposta é obviamente não, algumas poderiam ser 2, outras 5, algumas raras seriam 1 ou 8. Mas se analisarmos uma quantidade grande o suficiente, veremos que a maior parte gravitará corretamente em torno de 3, e as exceções tenderão a se anular.
Ponto 3 - Vale a pena o esforço?
Se estórias sub estimadas forem revistas para tentar "acertar" a velocidade, estórias super estimadas também devem, correto? Quanto tempo seria perdido para rever os esforços das estórias? O pequeno (e na minha opinião, inexistente) benefício compensaria?
Ainda Rascunho
Senhores, este texto ainda é um rascunho, e precisa ser melhorado e finalizado, mas já serve para iniciarmos as discussões.
Anselmo, parabéns pelo post e por levantar essa questão. Vamos começar então:
ResponderExcluir1 - Fala-se em "reestimar", mas não verdade o termo é incorreto, pois não se trata mais de estimativa, mas de um "assessment" ou avaliação. Afinal, o time já sabe quanto esforço realizou
2 - Quanto a serem duas coisas distintas, passado e futuro, ou estimativa e avaliação, isto é fato. O que não significa que não possamos usá-los: Temos que sempre usar o que temos de melhor, e para o que já passou, a realidade é o melhor que temos, e para o futuro, uma estimativa com base na realidade.
3 - Outro ponto é que o baseline precisa ser atualizado, um release burndown por exemplo, deve mostrar que houve um aumento de escopo e possivelmente um aumento no tempo para a convergência.
4 - O argumento acima obviamente vale para "baixar" a pontuação de uma estória que gastou bem menos pontos que o estimado.
Só para finalizar, acho um desperdício fazer essa avaliação para toda estória, mas em casos gritantes, onde um estória saltou de 3 para 13 (ou vice versa), vale a pena atualizar a estimativa.