Será que todos as equipes ágeis entendem realmente como a pontuação de histórias funciona? Aparentemente não. Um post recente de Mike Cohn, da Mountain Goat Software, reafirmou que estimar custo de funcionalidades através da pontuação de histórias trata-se de medir o esforço relativo e não no ranqueamento de funcionalidades em relação a sua complexidade.
Para ilustrar a diferença entre pontuação tradicional e esforço relativo, Mike utilizou o exemplo da compra de um carro. Uma equipe utilizando o ranqueamento em uma sequência (ordinal) listaria os carros a partir do modelo mais barato até o mais carro, atribuindo um ponto adicional a cada carro. Desta forma, um Tata Nano (carro popular da Tata Motors) seria classificado com 1 ponto enquanto que um Bugatti, seguindo na escala, receberia 10 pontos. O exemplo ilustra como que o ranqueamento do backlog através de uma pontuação tradicional pode nos levar a uma má interpretação com relação ao custo, pois o Bugatti é 960 vezes superior ao Nano em termos de custo.
Mas porquê esta má interpretação começou? Será que existem equipes ágeis que não entendem que estimar funcionalidades em pontos é uma medida de esforço, custo e não uma classificação das funcionalidades?
Mike Cohn afirma que aparentemente algumas equipes estão realmente estimando errado:
Estranhamente as pessoas estão fazendo isto. Recebi um e-mail no sábado de alguém que respeito muito relatando que pontuava histórias desta forma e fiquei surpreso. Não consigo visualizar nenhum motivo para classificar itens de um backlog desta maneira, mas sim, existem pessoas utilizando este critério de pontuação.
E você, conhece equipes que confundem a técnica de estimativa e pontuação de histórias? Já participou de equipes que utilizavam a pontuação para classificar as funcionalidades de um backlog através de uma ordem ao invés de classifica-lás considerando o esforço relativo?