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:

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:

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.)

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.