Qual funciona melhor, qual é mais precisa?
E a minha resposta é ao mesmo tempo nenhuma e todas. O ponto não é este.
O que seu time deve buscar em uma reunião de estimativa não é uma certeza, mas sim conseguir entender que o time está alinhado e aprendendo sobre o negócio. Em uma brincadeira com planning poker, onde os números possíveis são 1,2,3,5,8,13… se uma pessoa indica o número 1 e outra pessoa indica o número 13, você tem um momento para discussão, para nivelar conhecimento ou conhecer um risco que estava “escondido” no sistema.
Todas as técnicas funcionam para guiar o time e criar um modelo de pensamento… conforme o time evolui em conhecimento de negócio e tecnologia, a tendência é a estimativa funcionar melhor e ajudar o time a visualizar questões que estejam “fora de padrão”.
O principal benefício dos exercícios de classificação/estimativa é gerar discussão e basear o conhecimento das pessoas sobre as funcionalidades a serem desenvolvidas. Ou seja, se você usa uma técnica de estimativa, deveria ser para crescer conhecimento da equipe. Não para poder culpar alguém depois.
E se você precisa estimar algo que é nebuloso? Você vai precisar seguir no conceito do 3C, para poder conhecer mais sobre a funcionalidade e possivelmente adicionar Spikes no planejamento, assim poderá experimentar e aprender mais sobre algo antes de fazer a definição da funcionalidade por completo.
Você deveria conversar até ter visão de que o que precisa ser feito é algo factível. Eu gosto de quebrar coisas e entender que elas cabem no máximo em três dias (idealmente no máximo 1 dia). No fim, isso é uma “regra de dedão“, ou seja: vamos aprender mais se o que temos para fazer ainda não está sendo percebido por todos da equipe. Vamos nos manter em modo descoberta, até que possamos caminhar para o modo entrega.
Se o seu time chegar nesta regra de que tudo tem um tamanho pequeno para executar, você não precisa mais estimar! Tudo vira “1”. E isso só quer dizer que o seu time tem um objetivo de “até quando vamos nos manter em modo descoberta” antes de iniciar a executar / entregar algo.
Pingos de Agilidade 
Muitos times ágeis usam o Planning Poker, que já falei a respeito no meu blog(http://micajeho.wordpress.com/2012/01/23/estimativa-em-projetos-ageis/). Eu particularmente gosto de games para estimar, acredito que devemos tambem nos divertir fazendo software, no meu blog justifico porque prefiro tambémo Team Estimation Game (http://micajeho.wordpress.com/2012/06/24/team-estimation-game-porque-usar/).
Jogos são sempre importantes Miguel! Eles ajudam a manter o time próximo. E neste caso que você fala, eles ajudam e apoiam a tarefa sempre importante e necessária de compartilhar e gerar conhecimento.
Exato. Além de importantes, tiram aquela pressão da métrica de cima do time, nem sempre o time vai acertar, principalmente no início do Projeto. Conforme o time vai conhecendo a tecnologia, o negócio e o próprio time ele vai ajustando as estimativas e tornando-as mais reais. Além de fazer software é necessário divertir-se pois isso é o que mais amamos fazer.
Concordo contigo sobre a importância de o time estar ciente do quê precisa ser desenvolvido na sprint durante reuniões de planjeamento. Porém, na minha opinião a estimativa tem um papel importante, mesmo em ambientes ágeis, para que seja possível obter um padrão formal de esforço necessário para resolver cada tipo de atividade. As estimativas que seguem a mesma técnica em longo prazo ajudam a entender o ritmo de produtividade e a eficiência do time, dados que são importantes para tomar decisões estratégicas.
Concordo com você Ralph. As estimativas ajudam a entender o ritmo.
Ainda assim, lembrar que estes momentos de reuniões para estimar e quebrar tarefas são mais importantes ainda para gerar conhecimento e alinhamento entre a equipe.
O ritmo e padrão que um time consegue desenvolver vai fazer sentido e ajudar no longo prazo, conforme o time busca maneiras diferentes de melhorar e produzir mais.
Valeu pelo comentário!
Pingback: Pratique para sempre | Pingos de Agilidade
Pingback: #blogabout 8/out | forming, storming, norming and performing