Na hora de estimar, eu sempre recomendo o uso de story points no lugar de horas. Não vou explicar o que são story points, há bastante recurso na net. Mas eu vou explicar um dos melhores motivos pra isso.

Vamos imagina que você tem esse backlog:

Backlog no começo do projeto

Temos 3 histórias, A, B e C. Estimamos, com story points (em vermelho), que a primeira é um ponto, a segunda são dois pontos, e a terceira três pontos. E, simplificando bastante, imagine que cada ponto signifique uma tela. Assim o time estimou o primeiro item como tendo tamanho 1 por ter uma tela, o segundo em tamanho dois por ter 2 telas, e por aí vai (estou desconsiderando qualquer outra complexidade a fim de tornar o modelo mais didático). Digamos que nesse momento o time leva em média um dia (8 horas) pra terminar um ponto. Isso quer dizer que o time possui 6 pontos para trabalhar as três histórias, ou 6 dias de trabalho, ou 48 horas.

O projeto começa a ser entregue, o time passa pelas histórias A, B e C, e continua trabalhando. Ele começa a ganhar experiência, e na metade do projeto ele está 25% mais rápido. Isso quer dizer que agora cada ponto leva 6 horas em vez de 8. Agora o time encontra estas histórias pela frente:

 

Backlog no meio do projeto

As histórias D, E e F também possuem 1, 2 e 3 telas (olha que coincidência!). Só que diferente das primeiras histórias, estas não vão levar 1 dia, 2 dias e 3 dias pra terminar, mas 6 horas, 12 horas, e 18 horas, já que o time está mais rápido.

Isso significa que o tamanho dela em horas também deve ser menor, e que portanto a primeira deva ter 0,75 pontos, a segunda 1,6 pontos, e a terceira 2,4 pontos (se isso fosse permitido)?
Não!

O número de pontos não mede o tempo para um história ser feita, mas o tamanho relativo. Havíamos dito que nesse modelo simplificado uma história seria o dobro da outra se tivesse o dobro de telas, e isso não mudou. A história E, com duas telas, ainda é do dobro do tamanho da história A, que tem apenas uma tela. A história F ainda é 3 vezes maior que a A, e uma vez e meia maior que a B. Nada disso mudou.

Se estivéssemos utilizando horas pra estimar o backlog, sempre que a produtividade do time mudasse teríamos que rever a estimativa de todo o restante do projeto. E a produtividade é alterada toda hora, pra melhor e pra pior, de acordo com a evolução natural do projeto. Muitos gerentes de projeto tradicionais gastam muitas horas do seu tempo fazendo exatamente essa adaptação. Isso é desperdício, trabalho desnecessário.

O único motivo para alterar estimativas feitas com pontos é a alteração no escopo de uma história ou no entendimento deste escopo. Se isso não mudar, a estimativa não muda. O que muda é a velocidade a cada iteração.

É interessante notar como o fato de o projeto ser iterativo permite ser muito mais preciso do que se ele fosse feito em cascata. Conforme entregamos iteração após iteração vamos aprendendo qual a nossa real produtividade, ou seja, quanto tempo leva um ponto. Na prática esse valor nunca vai ser exato, ele vai variar em torno de uma média, mas isso é ainda mais preciso.

Com projetos ágeis abandonamos a ideia de que conseguimos ser perfeitos e dizer exatamente quanto tempo algo vai levar. Assumimos a imperfeição intrínsica ao processo como real, e trabalhamos empíricamente a fim impedir que tal imperfeição nos atrapalhe.

(A ideia de não usar horas mas tamanho também é vista em estimativas não vistas normalmente como ágeis, como em Pontos de Função ou Use Case Points, que também ganham o mesmo benefício. Mas normalmente estas medidas levam a outros problemas, mas isso é assunto para outro post.)