Cara,
só vou postar aqui pq estava escrevendo enquanto o sergio respondia! E deu mo trampo! kkkk
Eai Mateus,
falar de métricas num post rápido assim é meio complicado mas vamos lá.
Primeiro, existe uma razão onde a precisão da métrica esta ligada ao tempo que vc tem para medir, assim, se vc me der 1 ano para fazer uma analise de um use case / story com certeza vou conseguir te dar um estimativa muito boa e assertiva (não levando em consideração o livro The Mythical Man Month).
Sem duvidas essa situação não existe.
Uma outra coisa que precisa ser levado em consideração é que estimativas “estão sempre erradas”, o que quero dizer com isso é que impossível dizer se a data bate, não da para prever o caos, isso é coisa de esoterismo, um exemplo tosco é imagina uma epidemia H1N1, que não só tira gente da equipe como tira a paz das pessoas doentes e baixa a produtividade (ohhh minha irmã esta doente, meu deu estou preocupado!!)
O ponto é que precisamos estimar para ter uma idéia de recursos, como tempo e grana etc.
Mas a estimativa esta diretamente ligada a VELOCIDADE do SEU TIME, toda métrica só fica madura dentro depois de um tempo que essa equipe esta trabalhando junta, 6 meses mínimo, ai podemos entender sua velocidade e isso é o decisivo para uma boa estimativa.
Ao invés de “quanto tempo leva para fazer isso” o correto é “quanto tempo, esse time, leva pra fazer isso”.
Assim, o mais importante de tudo, não é estimar, e sim MEDIR!
Medir o tempo que sua equipe leva para fazer alguma coisa será a melhor maneira de conseguir estimar algo corretamente.
Agora, o que é esse alguma coisa? Um story? um epic? um use case?
Todos estão certos, o que vale é o que é melhor para vc e sua equipe!
Ai entra o Poker … Quando vc começa com o poker, vc pega a story, que todo mundo em consenso, acha que é a menor e pega a que todo mundo acha que é maior (lembre-se, não precisa ser necessariamente a maior ou a menor, o importante é existir algo para ser usado como referencia/comparação).
Ai vc DEFINE essa menor, digamos, representa o numero 2, quanto representa a maior? Ai todos juntos chegam a um
Consenso, digamos 13.
Ai vc começa a estimar as stories usando essas comparações como referencia.
No final, o que vc tem?
NADA? 
Vc tem um monte de stories com uns números que não querem dizer nada! Mas o que você tem na mão é a proporção entre elas!!!
Ai vc pega algumas dessas stories (priorização do back log) e começa a quebrar em tarefas menores, até que vc encha sua sprint. Nas tarefas menores, vc pode estimar um numero especifico de horas, já que vc ta no nível: “criar tabela X”, fazer DAO Y, etc …
Ai vc começa a sprint, e vê realmente, quanto tempo uma story que era 1 levou, quanto uma que era 5 levou, etc etc.
De posse desses números, vc pode rever, na próxima reunião de planejamento, os valores da sua métrica, fazendo acertos aos tamanhos das stories etc.
Em algumas iterações vc vai chegar a um numero médio de horas por story DA SUA EQUIPE! Você pode usar esse numero médio (tendo em mente o desvio padrão, etc) para estimar novos projetos que serão executados POR ESSA MESMA EQUIPE!
Essa é maneira que encontrei de chegar mais perto de estimar algo mais perto do real, mas sempre lembrando que NADA, NADA, NADA, mas NADA mesmo garante que vai estar certo!
Vc percebeu que o numero da carta do poker não esta tão diretamente ligada a um numero de horas, o segredo é começar com uma referencia para comparação, vc poderia usar raças de cachorros por exemplo:
“essa story é um chiuaua, essa aqui é um são bernardo”
Depois de umas sprints vc sabe quanto tempo leva um são bernardo!
O fibonatti é usado, por que a diferença entre os números cresce, representando a incerteza, que aumenta nas stories maiores, por exemplo, eu sei que fazer um insert no db é bico, leva exatamente 10 minutos, agora, fazer integração com um web service de um cliente X, é mais difícil:
Isso leva uma hora! (Fácil de estimar)
vs
Isso leva 234,5 horas! (Como chegou a precisão desses números quebrados? O correto seria umas 230 horas)
Te recomendo um livro chamado Agile Estimation and Planning, é muito phoda!
Abraço,
Claudio
