A estimativa do esforço necessário para entregar as histórias é um dos pontos em aberto do Scrum que permite mais variação. Como método ágil, Scrum atrai soluções participativas, como o “planning poker”, mas qualquer método que implique no compromisso da equipe com o valor encontrado é um bom método.

É interessante notar que a estimativa pode variar de duas maneiras no Scrum: variando a unidade da estimativa ou variando a forma de chegar a uma estimativa.

Scrum é surpreendente, pois descobrimos que a unidade escolhida não é tão importante. A questão não é realmente “quantos de quanto” estamos fazendo, mas sim qual a nossa velocidade, em uma unidade qualquer, e como as histórias são comparadas umas com as outras nessas unidades.

Uma unidade comum são os “pontos de história”. A prática diz: escolha a menor história do primeiro Product Backlog e determine que ela exige 2 pontos de história. A partir daí, avalie o esforço de todas as outras histórias comparando-as com a história de 2 pontos. Prestando atenção a essa descrição, podemos ver que a cada projeto a menor história poderá ser diferente. Logo, 2 pontos de histórias não significam sempre a mesma coisa.
O que temos de interessante nesse método? Em primeiro lugar, não é necessário realmente conhecer quanto esforço será necessário, apenas qual é a história mais fácil. Em segundo lugar, enquanto estivermos trabalhando com histórias pequenas (entre 0 e 8 pontos de história), será razoavelmente fácil acertar o esforço necessário para executá-las, usando a história de 2 pontos como referência. Em terceiro lugar, quando encontramos histórias muito grandes (20 pontos ou mais), temos imediatamente consciência que estamos falando de um “chute” e é melhor quebrá-las em mais histórias, que podemos estimar com maior certeza.

Relacionado com o uso de pontos de história está o uso de uma série de números fixos para determinar o esforço da história: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. Por que esses números? Porque estamos muito interessados nas proporções de dificuldade entre as histórias e pouco interessados em ter uma estimativa perfeita, principalmente para histórias muito grandes, que não serão atacadas da forma como estão definidas no momento. O erro entre 2 e 3 é pequeno, e também não é preciso ficar perdendo muito tempo para decidir se é 4, 3 ou 5. As proporções dessa série numérica são bastante adequadas.

O uso de horas de trabalho para medir histórias também é possível, porém acredito que essa medida é bem mais adequada para estimar as tarefas de uma Sprint do que as histórias.

Outra medida que tomei conhecimento: o uso de “tamanhos de camisa”. Uma história seria então extra-pequena (XP), pequena (P), média (M), grande (G), extra-grande (XG) ou extra-extra-grande (XXG). Uma vantagem dessa notação é que ela tem grande poder de comunicação com o Product Owner. Como os nossos números não significam uma unidade absoluta, apenas a relação entre eles tem significado, podem parecer muito arbitrários para o Product Owner. Usar tamanhos de camisa ou, teoricamente falando, valores nebulosos (fuzzy), pode facilitar a comunicação. No entanto, dificulta um pouco o cálculo  da velocidade da equipe.

Qual a sua forma de estimar? Qual a sua opinião?