Pontos de história x #NoEstimates: nosso veredicto

Nenhum dos lados sai vencedor de forma definitiva. Faça estimativas para construir um entendimento comum e identificar divergências; não faça estimativas para prever uma data, mas sim para fazer projeções com base na produtividade. O número em si é praticamente inútil. A conversa que o gerou é o verdadeiro valor.

O debate é apresentado como uma escolha binária — pontos ou nenhum ponto —, mas não é assim. Ambos os lados têm razão em algum aspecto, e ambos contam com uma autoridade de peso por trás. A posição mais útil é aquela que analisa o argumento mais forte de cada lado e mantém apenas as partes que resistem ao teste do sprint real.

Argumentos a favor dos story points

O argumento de Mike Cohn, a posição definitiva a favor dos pontos, nunca se referiu realmente ao número em si. Trata-se de que o ato de estimar, por si só, força a equipe a discutir a complexidade, trazer à tona suposições ocultas e chegar a um consenso sobre o que uma história realmente envolve antes que alguém comece a escrever código. Os pontos também contornam uma patologia específica: se estimarmos em dias, todo número vira motivo de barganha; se estimarmos em uma unidade abstrata, a barganha não tem em que se basear. O problema é que todos percebem a indireta (“não estamos estimando tempo, apenas complexidade, para que possamos planejar o sprint, que dura duas semanas”), e a abstração só protege a equipe enquanto ninguém a converter diretamente de volta em uma data.

Steve McConnell oferece um contraponto rigoroso ao grupo que se opõe às estimativas. Sua tese é que a causa principal das estimativas ruins geralmente é a falta de habilidade em estimar, e não a prática de estimar em si, e que estimadores sérios distinguem três coisas que o debate costuma misturar: a estimativa (o que é provável), a meta (o que a empresa deseja) e o compromisso (o que a equipe promete). Se você misturar esses conceitos, é claro que a estimativa parecerá falha. Mantenha-os distintos e ela funcionará de verdade.

Os argumentos a favor do #NoEstimates

Agora, o outro lado, com força total. A objeção de Allen Holub é que as estimativas são sempre imprecisas — geralmente de forma exagerada — e que os “story points” foram criados para ofuscar a duração, de modo que os gerentes parassem de pressionar em relação ao prazo; no entanto, as equipes fazem a engenharia reversa e os convertem diretamente em horas, recriando exatamente a disfunção que os “story points” foram inventados para evitar. A escala de Fibonacci não adianta nada se todos mantiverem, em segredo, uma tabela de conversão de pontos para horas.

A afirmação mais contundente, baseada em dados, vem de Vasco Duarte: em projetos reais, simplesmente contar histórias permite fazer previsões tão bem quanto somar seus pontos de história. Se isso se aplica ao seu trabalho, os pontos são pura formalidade. Você fez cálculos aritméticos para chegar à mesma resposta que a contagem já lhe deu. Em vez disso, meça a produtividade e o tempo de ciclo; uma fila crescente é um indicador antecipado que você pode prever, enquanto a velocidade é um indicador atrasado.

E então veio a observação mais perspicaz de todo o debate. Ron Jeffries, amplamente reconhecido como o inventor dos story points, retratou-se em 2019: “Talvez eu tenha inventado os story points e, se o fiz, peço desculpas agora.” Seu problema é especificamente com o uso deles para prever quando o trabalho será concluído e para comparar equipes. Sua alternativa não é “parar de planejar”. É dividir as histórias em partes pequenas o suficiente para que seja necessário apenas um único teste de aceitação, idealmente com duração inferior a um dia cada, de modo que quase não reste nada para estimar.

Em que situações mudaríamos de ideia

Adotaríamos totalmente a abordagem #NoEstimates para uma equipe cujo trabalho já está dividido em partes pequenas e uniformes. Quando cada história leva aproximadamente um dia, contar as previsões das histórias e somar os pontos, e a reunião de estimativa se torna um custo adicional que pode ser eliminado. McConnell admite isso, citando o trabalho em ciclos rápidos — onde a missão é simplesmente “fazer a próxima coisa mais útil” — como um contexto em que as estimativas agregam pouco valor.

Nós relaxaríamos nossa vigilância em relação aos pontos no caso oposto: uma organização em que as estimativas genuinamente nunca se transformam em compromissos e ninguém compara equipes. Nesse caso, o perigo sobre o qual o grupo anti-estimativa alerta não existe, e os pontos são apenas um tema inofensivo para iniciar conversas. O problema é que esse tipo de organização é raro. A instrumentalização é a regra, e é por isso que nosso veredicto se inclina dessa forma.

A visão prática

• Considere o planning poker como um detector de divergências, não como uma ferramenta de previsão. Um 2 e um 13 na mesma tarefa são o sinal. Isso significa que a equipe não tem um entendimento comum sobre o trabalho. Conversem até que a variação entre os valores diminua; o resultado é o consenso alcançado, não o número final.
• Faça a previsão com base na produtividade e no tempo de ciclo, e não na soma dos pontos. Velocity é um dado de planejamento para a equipe, nunca uma promessa para o público externo.
• Separe a estimativa do compromisso, como diz Cohn. Uma estimativa é uma suposição; no momento em que se torna uma promessa, alguém alterou seu significado sem avisar a equipe.
• Se você for usar pontos, mantenha-os relativos. No momento em que eles forem associados a horas, você estará estimando a duração de forma velada, com toda a pressão das estimativas em horas, além de uma camada de ofuscação.
• Divida a história em partes, em vez de definir seu tamanho. Jeffries está certo ao afirmar que a maior parte do valor pelo qual se debate desaparece quando as histórias são pequenas o suficiente para que a estimativa quase não tenha importância.

O número não tem valor; o que importa é a conversa que o gerou. Essa única frase resolve a maior parte da discussão e faz com que uma sessão de planning poker seja genuinamente útil, sem fingir que pode prever o futuro.

Perguntas frequentes

Devemos usar story points ou o #NoEstimates?

Use o que for mais eficaz para estimular a conversa sobre estimativas e pare de tratar o número como uma previsão. Os pontos de história são úteis como um indicador de divergências: uma grande variação nas estimativas de uma história significa que a equipe não tem um entendimento comum sobre ela. O #NoEstimates é a escolha certa quando suas histórias já estão divididas em partes pequenas e uniformes, pois, nesse caso, contá-las serve tanto para fazer previsões quanto para somar pontos. De qualquer forma, preveja a entrega com base na produtividade e separe a estimativa do compromisso.

Será que o inventor dos story points realmente se desfez deles?

Ron Jeffries, amplamente reconhecido como o criador dos story points, escreveu em 2019: “Talvez eu tenha inventado os story points e, se foi o caso, peço desculpas agora.” Sua objeção é ao uso deles para prever datas de conclusão e para comparar ou classificar equipes. A alternativa que ele recomenda não é “nenhum planejamento”. Trata-se de dividir as histórias em partes pequenas o suficiente para que cada uma exija apenas um único teste de aceitação.

Como se faz uma previsão de lançamento sem estimar cada história?

Meça a produtividade — o número de histórias que a equipe realmente conclui por semana — e projete o backlog restante com base nessa taxa. A constatação de Vasco Duarte é que contar histórias permite fazer previsões tão bem quanto somar pontos de história; portanto, uma vez que as histórias sejam divididas em partes de tamanho semelhante, os pontos agregam pouca informação além daquela que a contagem já fornece.

Leitura relacionada

• O que são pontos de história?: o que os pontos medem e o que eles não medem.
• Pontos de história x horas: por que a conversão de pontos em horas é o ponto de discórdia que ambos os lados estão realmente debatendo.
• A velocidade é uma métrica útil?: a outra face dessa questão: o que acontece quando a previsão se torna uma meta.
• Teatro Ágil: o modo de falha na execução: a estimativa como ritual de “culto da carga” e como distinguir uma estimativa real do teatro.
• Planning Poker gratuito: uma ferramenta de diálogo, não uma máquina de previsões.