A utilização de pontos de história e de velocidade vem sendo discutida por alguns agilistas da comunidade, que questionam se seriam ferramentas adequadas para as estimativas e medidas de progresso, pois seriam métricas propensas a abuso, raramente utilizadas de maneira efetiva.
Joshua Kerievsky escreveu um relato detalhado das suas experiências na utilização de pontos de história (story points) e sobre como a técnica é sujeita a abusos. Kerievsky cita um exemplo em que os pontos sofreram aumento irracional:
Um dia uma equipe foi cobrada a desempenhar melhor. Essa equipe tinha uma velocidade média bastante estável, por volta dos 52 pontos por iteração; havia flutuação, mas era de poucos pontos. Apesar disso, após uma cobrança por desempenho, a velocidade da equipe saltou para mais de 80 pontos! Perguntei o que havia acontecido. "Hoje em dia aqui um espirro conta como ponto de história", responderam. Como podia uma equipe madura como aquela, avaliada e treinada por mim e dois excelentes coaches da Industrial Logic, inflacionar as estimativas simplesmente para a equipe parecer mais rápida.
Minha confiança nos pontos de história e nos cálculos de velocidade começou a cair rapidamente após essa experiência.
Joshua Kerievsky também ressalta o anti-padrão de se comparar equipes por pontos.
Há muitos anos, venho sendo perguntado, por vários gerentes de empresas diferentes, "Por que a equipe X consegue fazer 24 pontos por sprint, enquanto a Y produz apenas 12? As duas equipes têm aproximadamente o mesmo tamanho, então qual a razão de tanta diferença?" Em vez de tratar a velocidade como específica à equipe, um indicador de capacidade, esses gerentes caem na armadilha de pensar na velocidade com medida geral de desempenho.
Uncle Bob Martin reforça essa visão, em comentário ao artigo de Kerievsky:
Muitas equipes têm problemas com pontos de história. Já vi equipes desvalorizarem a pontuação quando seus gerentes de projeto pedem mais velocidade; também já vi adulterarem gráficos de velocidade para satisfazer gerentes de projeto mais interessados na forma que na funcionalidade. Para equipes como essas, deve-se considerar uma nova abordagem.
Em uma discussão na lista de emails da Scrum Alliance Group, Ron Jeffries criticou a utilização da velocidade como métrica.
- A velocidade pode ser mal utilizada, e geralmente é;
- A velocidade pode ser utilizada como um jogo, e geralmente é.
Há um foco na parte errada da equação. O que o Agile considera importante no direcionamento de um projeto é a seleção das coisas a fazer e das que devem ser adiadas - e não em trabalhar no lado do custo dessa equação para tentar melhorá-lo. Uma equipe com enfoque na velocidade não está dando importância suficiente ao valor. Gostaria de nunca ter criado a métrica "velocidade", se é que o fiz.
Ron Jeffries elabora seu pensamento:
As questões sobre velocidade, na sua maioria, têm o objetivo de melhorar as estimativas. Mas quando investigamos mais detalhadamente, vemos equipes definindo quando terão finalizado o trabalho, e então se obrigando a concluir tudo. Vemos as equipes sendo medidas pela acurácia. Vemos também Product Owners distribuindo itens do backlog com pouco ou nenhum critério, apenas para "seguir o plano".
O Scrum funciona melhor quando o Product Owner utiliza o backlog de forma criativa, para entregar o melhor produto possível. Tenho percebido que um enfoque nas estimativas não ajuda a atingir esse objetivo.
Mike Cohn postou recentemente em seu blog um exemplo de conversa com um cliente que considera as estimativas importantes. O cliente diz:
Antes de tudo, para que eu sequer pense se continuo custeando o projeto, preciso saber se nossas estimativas foram boas nessa última fase. Se só fizermos metade do prometido, quando eu pedir mais recursos vão pensar que o dinheiro está indo para um buraco negro. Preciso saber se estamos com a abordagem adequada para conseguir boas estimativas e ter uma ideia de quanto precisaremos. Temos que melhorar as estimativas se elas não estiverem com a qualidade mínima.
Vou lutar para conseguir o financiamento, mas o dinheiro não vem de graça. É preciso haver algum nível de métricas dizendo como estamos em relação ao planejado. Em outras palavras, vou olhar o gráfico de burndown do projeto e acompanhar de perto todos os custos.
Vasco Duarte sugere uma alternativa aos pontos de história: estimar pelo número de histórias.
Considerando as estimativas e o progresso do projeto no longo prazo (note que isso só se aplica no longo prazo, por exemplo, mais de três iterações no futuro), pode-se considerar que todas as histórias sejam do mesmo tamanho e que podem, portanto, ter o progresso medido pelo número de itens concluídos por sprint.
Mike Cohn apresenta ideias semelhantes:
Concordo que equipes Kanban fazem menos estimativas explícitas. Isso porque partem do suposto que todo o trabalho tem aproximadamente o mesmo tamanho.
Neil Killick oferece outra abordagem para custeio que não envolve estimativas. Um exemplo utilizado é o da construção de um website, em que o fornecedor cria a melhor solução possível dado um orçamento pré-estabelecido; ao final, o cliente pode escolher se quer cancelar o contrato caso esteja insatisfeito, a qualquer momento. Sobre essa ideia, Killick argumenta:
Essa opção dispensa estimativas, permite que o design mude no meio do caminho, aceita mudanças conforme o andamento do trabalho, e mostra que a empresa está querendo trabalhar próxima ao cliente para atingir um resultado excelente. Mostra que a empresa está disposta a aceitar um risco maior (de perder dinheiro no contrato), porque confia na qualidade do que faz e no relacionamento que cria com seus clientes.
Você já percebeu práticas como velocidade e pontos de história induzirem a comportamentos inadequados? O que acha das alternativas sugeridas?