Story points: o guia do fundador que paga a conta

O time diz que a reconstrução do pagamento é 13 pontos. Você está tentando entender se isso vale o que você gasta por mês. O que os story points realmente medem, por que ninguém converte isso em horas para você, e o que olhar no lugar.

Três sprints depois do início do projeto, um fundador com quem trabalhamos interrompeu a review e fez a pergunta que a sala inteira estava evitando. “O time diz que a reconstrução do pagamento é 13 pontos. Eu pago um valor alto todo mês por isso. O que exatamente eu estou comprando?”

Ninguém deu uma resposta limpa. Isso é normal. Também é uma falha.

Então, de forma limpa: um story point é uma unidade de tamanho relativo, não de tempo. Ele junta três coisas num número só: o quanto o trabalho é complexo, o quanto ele é incerto, e o quanto de trabalho existe ali. A única função dele é comparar uma peça de trabalho com outra peça de trabalho do mesmo time. Uma story de 5 pontos deve ser mais ou menos cinco vezes o esforço de uma story de 1 ponto, para aquele time, naquele trimestre. Por definição, ela não diz nada sobre horas.

O que é um problema, porque horas são o que você está comprando.

Essa tensão é o assunto deste artigo. O cânone ágil diz para nunca converter story points em tempo. O cânone está certo, e também é silenciosamente inútil para a única pessoa da sala que precisa assinar a nota fiscal. As duas coisas são verdade, e você consegue segurar as duas se entender para que o instrumento foi construído.

O que um story point realmente mede

Story points nasceram do Extreme Programming no fim dos anos 1990, e resolviam uma falha específica: desenvolvedores são notoriamente ruins em estimar horas, e são bem menos ruins em estimar proporções. Pergunte a um engenheiro “quanto tempo isso leva?” e você recebe um número moldado pelo otimismo, por quem está perguntando e pelo que ele acha que você quer ouvir. Pergunte “isso é maior ou menor do que aquilo que entregamos semana passada?” e você recebe algo mais perto da verdade.

O truque é esse, inteiro. Um ponto é uma comparação, ancorada em trabalho que o time já terminou.

Três ingredientes entram no número:

• Complexidade. Quantas partes móveis, quantas incógnitas no desenho, quantos lugares onde pode dar errado. Integrar um meio de pagamento que o time nunca tocou é complexo mesmo que o código seja curto.
• Incerteza. Quanto disso é descoberta? Uma story que depende de uma API de terceiro sem documentação carrega um risco que um campo de formulário não carrega.
• Volume. A quantidade pura de trabalho. Quarenta telas quase idênticas podem ser simples e ainda assim grandes.

Uma story de 8 pontos não é “uma de 3 pontos difícil”. É uma story que o time, comparando com tudo que já construiu junto, acredita ser mais ou menos oito vezes o tamanho da menor story de referência que ele tem. Se o seu time não consegue apontar para uma story pronta e dizer “este é o nosso 1”, os pontos dele são decoração.

Essa é a primeira coisa que vale conferir como comprador. Pergunte qual story terminada é a âncora. Um time com uma resposta real está estimando. Um time sem resposta está chutando fantasiado.

Por que os story points vão de 1, 2, 3, 5, 8, 13

A maioria dos times estima numa escala Fibonacci modificada: 1, 2, 3, 5, 8, 13, 21. Os intervalos ficam mais largos conforme os números crescem, e isso é proposital, não um acidente de aritmética.

A precisão desmorona conforme o tamanho cresce. Um time consegue de fato distinguir um 1 de um 2. Ele não consegue distinguir um 20 de um 21, e, se você der a opção, vai passar quarenta minutos fingindo que consegue. A escala que se abre força a estimativa para dentro de baldes que são honestos sobre a própria margem de erro.

A escala também funciona como alarme. Assim que uma story chega a 13 ou 21, times disciplinados nem estimam. Eles quebram. Um 21 não é uma estimativa, é a confissão de que o trabalho ainda não foi entendido. Se você está vendo 21 sobreviver até dentro de uma sprint, isso é um sinal para puxar, e normalmente significa que as user stories foram escritas grossas demais para serem construídas.

O padrão 1, 3, 5, 8 do Jira é a mesma ideia com vocabulário menor. Nada na ferramenta muda a lógica.

Quantas horas é um story point?

Essa é a pergunta mais buscada sobre story points e a única que todo artigo da primeira página do Google se recusa a responder. A resposta honesta vem em três partes.

Parte um: oficialmente, nenhuma. Não existe conversão, e Mike Cohn repete isso há duas décadas. Um ponto não é uma hora, nem um dia, nem meio dia. Dois times da mesma empresa podem estar entregando 30 pontos por sprint e andando em velocidades completamente diferentes no mundo real, porque os pontos deles estão calibrados em âncoras diferentes. Pontos não são portáteis entre times, e não são portáteis entre trimestres se o time mudou.

Parte dois: o seu time já faz a conversão de cabeça. Claro que faz. Todo desenvolvedor que já pontuou uma story pensou “isso dá um dia e meio”. A conta existe. Ela só é informal, privada e reajustada o tempo todo.

Parte três: existe uma conversão que você pode calcular, e ela olha para trás. Pegue o que o time custa de fato numa sprint. Divida pelos pontos que ele de fato concluiu naquela sprint. Isso dá um custo por ponto para aquele time, naquele projeto, naquele período. Se uma sprint de duas semanas te custa R$ 100 mil e o time entrega de forma consistente 40 pontos, sua taxa efetiva é R$ 2,5 mil por ponto, e aquela reconstrução de pagamento de 13 pontos é uma decisão de ~R$ 32 mil.

Esse número é útil. É o número que te deixa decidir se vale construir a funcionalidade, o que é o seu trabalho, não o deles. E ele sobrevive ao contato com a realidade, porque vem do que aconteceu, não do que alguém torceu para acontecer.

Mas ele vem com uma regra, e a regra sustenta o resto.

No momento em que story points viram preço, eles deixam de ser estimativa

Faça a conversão. Não publique.

No instante em que um time descobre que os pontos estão sendo convertidos em dinheiro e devolvidos para ele, os pontos param de medir tamanho e passam a medir autoproteção. As estimativas inflam, de forma silenciosa e universal. Ninguém decide fazer isso. Simplesmente acontece, do jeito que a água encontra o declive.

É a lei de Goodhart, na formulação mais afiada que a antropóloga Marilyn Strathern deu: quando uma medida vira meta, ela deixa de ser uma boa medida. Story points são especialmente frágeis nesse ponto porque são autodeclarados, não verificáveis de fora, e estimados pelas mesmas pessoas cujo trabalho eles medem. Não existe auditoria independente para saber se uma story “era mesmo” um 5. A inflação de pontos é indetectável por construção. Você nunca vai pegar, porque não há nada contra o que comparar.

Ron Jeffries, uma das pessoas que colocou os story points no mundo, passou anos argumentando que eles são mal usados exatamente assim. O resumo dele, em Story Points Revisited, vale os quinze segundos de leitura: “Talvez eu tenha inventado os story points e, se inventei, hoje eu peço desculpas.”

Então guarde o custo por ponto para você, use para tomar as suas decisões de construir ou pular, e nunca balance esse número na frente do time numa review. Os fundadores que erram isso terminam com um time cujo gráfico de velocidade fica lindo e cuja data de entrega não para de andar. Eles otimizaram o número e perderam aquilo para que o número servia.

O que 1, 3, 5, 8 e 13 pontos parecem num projeto real

Pontos não são portáteis, então qualquer tabela como esta é um esboço, não um padrão. Mas fundadores continuam pedindo uma referência, e recusar essa referência é a razão pela qual os artigos existentes sobre o tema são inúteis. Aqui vai um formato aproximado, calibrado no tipo de trabalho que um time de produto em estágio inicial realmente faz:

Duas coisas para levar daqui. Primeira: o salto de 5 para 8 para 13 é onde mora o risco, e é ali que a sua atenção deveria estar no planejamento da sprint. Segunda: se os 13 do seu time parecem os 3 de outro time, eles não estão te cobrando caro. Estão calibrados de outro jeito, e a única comparação que importa é contra a própria história deles.

Velocity é o número para olhar de verdade, e como ler

Velocity é o total de pontos que um time conclui numa sprint. Média das últimas três a cinco sprints, é o instrumento de previsão mais próximo que você tem: pontos que sobram no backlog, divididos pela velocity, dão as sprints que faltam.

Leia por estabilidade, não por tamanho. Um time que roda 32, 30, 34, 31 é um time em cima do qual você consegue planejar uma captação. Um time que roda 45, 20, 50, 18 é um time cujas estimativas ainda não significam nada, e a média de 33 é uma mentira contada com aritmética. A variação é o sinal. Persiga a variação, não o teto.

Três coisas corrompem um gráfico de velocity em silêncio, e vale perguntar sobre as três:

• Carryover. Pontos contabilizados quando uma story pela metade rola para a sprint seguinte. Se trabalho inacabado pontua, velocity para de significar “entregue”.
• Repontuação. Uma story que era 5 na sprint passada e virou 8 nesta, sem o escopo ter mudado.
• Comparar entre times. Dois squads, duas calibragens. Nunca no mesmo gráfico.

Quatro perguntas para fazer no planejamento quando você não é técnico

Você não precisa entender o código para auditar a estimativa. Precisa entender se a estimativa é real. Estas quatro perguntas fazem isso, e nenhuma delas exige que você saiba o que é um índice de banco de dados.

1. “Qual é a story de referência de vocês para um 1?” Se não conseguem citar um trabalho terminado, a escala não tem âncora e todo número depois dela é inventado.
2. “Qual é a incerteza desta aqui, e o que faria ela crescer?” Um time bom responde na hora e com especificidade: “se aquela API não suportar estorno parcial, isso dobra”. Um time que diz “deve dar certo” não olhou.
3. “Quanto a gente pontuou uma parecida da última vez, e quanto ela custou de verdade?” É a única checagem de calibragem que existe. Times que acompanham isso melhoram. Times que não acompanham, derivam.
4. “Qual é a menor versão disso que um cliente conseguiria usar?” Não é uma pergunta sobre pontos, mas é a pergunta mais valiosa da sala. Um 8 quase sempre contém um 3 que teria sido suficiente.

Quando story points são o instrumento errado

Story points pressupõem um time contínuo, um backlog estável e uma relação em que você compra capacidade ao longo do tempo. Se esse não é o seu arranjo, eles são a ferramenta errada e você deveria parar de pedir.

Se você assinou um contrato de escopo fechado e preço fechado, os pontos são irrelevantes para você. Você comprou um resultado, não uma taxa, e o método interno de estimativa do fornecedor é problema dele. Se você está em time and materials, os pontos são úteis mas não são o contrato, e a diferença entre esses dois arranjos pesa muito mais no seu orçamento do que qualquer estimativa vai pesar.

E se um fornecedor está te cotando em story points numa proposta, antes de qualquer time ter construído qualquer coisa junto, esse número é decoração. Não existe história compartilhada para ancorar. Pontos não existem antes de um time ter terminado trabalho junto, e um ponto de um time com quem você nunca trabalhou é um número sem denominador.

Perguntas frequentes

Quantas horas são 5 story points?
Não existe conversão oficial, e qualquer fornecedor que te dê uma sem ressalva está falando o que você quer ouvir. Na prática: divida o custo de uma sprint pelos pontos que aquela sprint entregou, e você tem um custo por ponto daquele time. Use para as suas decisões, mantenha fora da pauta da review.

1 story point é igual a 1 dia?
Não, e os times que deixam essa equivalência pegar normalmente acabam com uma escala que é só “dias” fantasiada. Quando isso acontece, você perdeu a comparação relativa que tornava os pontos úteis e ficou com todo o overhead.

Por que os story points são 1, 3, 5, 8?
Porque a precisão da estimativa decai conforme o trabalho cresce. Os intervalos que se abrem impedem o time de discutir diferenças que ele não consegue perceber, e empurram trabalho grande e mal entendido para um balde que diz “quebre isso”.

O que são 5 story points em Agile?
Mais ou menos cinco vezes o tamanho da menor story de referência do time, somando complexidade, incerteza e volume. Na maioria dos times de produto em estágio inicial, esse formato parece um fluxo autocontido com estados e permissões próprios. No seu time, é o que a história do seu time disser que é.

Posso comparar a nossa velocity com a de outra empresa?
Não. Pontos são calibrados por time. Uma empresa a 60 pontos por sprint não é duas vezes mais rápida que uma a 30. É outra régua, e a comparação não diz nada além de que alguém na conversa quer ganhar a discussão.