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 — em vez disso, faça previsões com base na produtividade. O número em si é praticamente inútil. A conversa que o gerou é que constitui 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.

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. 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 à turma que se opõe à estimativa. Sua tese é que a causa principal das estimativas ruins geralmente é a falta de habilidade para estimar, e não a estimativa 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 tudo isso, é claro que a estimativa parecerá falha. Mantenha-as distintas 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 — mas 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 aplicar 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 o rendimento 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, em média, um dia para ser concluída, contar as previsões das histórias e somar 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, em que 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 cautela em relação aos pontos no caso oposto: uma organização em que as estimativas realmente nunca se transformam em compromissos e ninguém compara equipes. Nesse caso, o perigo contra 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

• Encare o planning poker como um detector de divergências, não como uma máquina 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 diferença entre os valores diminua; o consenso é o resultado, 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 informar 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 obscuridade.
• 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 mantém uma sessão de planning poker 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 o fiz, 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” — é 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 o rendimento — o número de histórias que a equipe realmente conclui por semana — e faça uma projeção do 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.

Leituras relacionadas

• 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 faceta dessa discussão: o que acontece quando a previsão se torna uma meta.
• Teatro Ágil: o modo de falha da apresentação — a estimativa como ritual de culto à 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.