Story points vs horas: como responder "quando fica pronto?" sem converter

O que cada unidade mede

As duas unidades parecem responder à mesma pergunta, mas medem coisas diferentes. Ponto mede o tamanho relativo de uma história em comparação com outras. Hora mede tempo de relógio de quem executa o trabalho.

Nenhuma das duas é mais honesta que a outra. Elas respondem a perguntas diferentes, e usar a unidade errada para a pergunta errada produz um número com cara de precisão que não se sustenta na sprint seguinte.

Por que pontos funcionam melhor no backlog

No backlog, quase nada é repetível o bastante para virar hora com confiança. Uma integração nova, uma tela inédita ou uma migração têm surpresas que só aparecem durante o trabalho. Comparar histórias entre si funciona mesmo quando o desconhecido é grande.

• Comparar é mais fácil que prever duração. Dizer que uma história é maior que outra é mais confiável do que dizer quantas horas cada uma vai levar.
• O ponto vale para qualquer pessoa que pegar a tarefa. Horas mudam conforme quem executa; pontos descrevem o item, não a agenda de quem o pega.

A escala, o Fibonacci e a calibração com história de referência estão no guia de story points. Aqui o foco é a decisão entre as duas unidades e o que fazer quando alguém pede uma data.

Quando horas são a unidade certa

Horas não são proibidas. Existem contextos em que elas são a unidade mais útil, e forçar pontos neles só cria trabalho extra.

• Quebra de uma história em tarefas. Depois que o escopo está claro, tarefas pequenas e repetíveis cabem em horas sem enganar ninguém.
• Contrato de escopo fechado. Quando o escopo está congelado por contrato, o compromisso é de prazo e a conversa acontece em dias ou horas.
• Trabalho repetível e operacional. Suporte, manutenção e atividades com histórico longo permitem estimar em tempo com boa margem de acerto.

Repare que os três casos têm algo em comum: o escopo já está estável ou o trabalho é conhecido o bastante para não mudar no meio. Sem essa estabilidade, horas viram chute com vírgula.

O erro não é usar horas, é misturar as duas unidades no mesmo planejamento. Uma história estimada em pontos com prazo cobrado em horas abre espaço para conversão, e a conversão é justamente o problema da próxima seção.

A armadilha da conversão "1 ponto = 4 horas"

Alguém sempre propõe a fórmula: se 1 ponto virou quatro horas nas últimas sprints, basta multiplicar. O cálculo parece funcionar uma vez e para de funcionar quando o time muda, o produto muda ou o tipo de história muda de tamanho.

Pior que o erro do cálculo é o efeito no comportamento. No momento em que o ponto vira hora, o time começa a estimar horas com outro nome: infla o número para caber no prazo, evita item incerto e a escala relativa perde o sentido. Ninguém estima com honestidade quando o número vira compromisso.

Se o time precisa de uma ponte entre pontos e datas, a ponte é a velocidade, não a conversão. A velocidade vem do histórico real e é lida como faixa, não como um número fixo de horas por ponto.

Há quem defenda a conversão como ferramenta de comunicação para gente de fora do time, do tipo "isso dá mais ou menos duas semanas". Se precisar fazer isso, use a faixa de velocidade e não uma taxa fixa de horas por ponto, e deixe claro que é uma estimativa de prazo, não um compromisso.

Respondendo "quando fica pronto?" com velocidade

A previsão honesta vem de três ingredientes: a velocidade recente do time, em pontos por sprint; o total de pontos que falta; e uma margem para o desconhecido. O exemplo abaixo é ilustrativo, com números redondos escolhidos para mostrar a conta.

Exemplo com números fictícios. Imagine um time que fechou as últimas três sprints com 22, 26 e 24 pontos, ou seja, algo entre 22 e 26 por sprint. O backlog restante soma 60 pontos. Dividindo 60 por 24, dá cerca de 2,5 sprints; com a variação observada, a resposta honesta é "entre dois e três sprints", não uma data exata de calendário.

Repare que a resposta veio em faixa. Velocidade é uma medida instável por natureza: férias, troca de time e feriados mexem no número. Uma faixa comunica essa incerteza; uma data exata finge que ela não existe.

Se o prazo pedido não cabe na faixa, as opções continuam as mesmas de sempre: cortar escopo, dividir histórias ou aceitar mais incerteza. Estimar de novo para agradar o pedido só transfere o problema para a próxima sprint.

Migrando de horas para pontos

A migração é mais simples do que parece e não exige parar o time por uma sprint.

1. Escolha três histórias já entregues. Uma pequena, uma média e uma grande, todas bem conhecidas pelo time.
2. Atribua pontos por comparação. A pequena vira 1 ou 2; as outras entram por comparação com ela, não por conversão de horas.
3. Estime o backlog em rodadas. Cada item novo entra comparado às referências, no voto secreto do planning poker.
4. Registre os pontos concluídos por sprint. A soma do que foi concluído a cada sprint forma a velocidade do time.
5. Use a velocidade para prever, não para cobrar. A faixa de pontos por sprint vira a faixa de previsão; ela não é meta individual de ninguém.

Quer testar o fluxo sem compromisso? Crie uma sala no Pointly e rode uma rodada com as histórias do próximo sprint.

Veja também: t-shirt sizing para triar o backlog em tamanhos antes de estimar em pontos e o comparativo de ferramentas para escolher a sala.

Perguntas frequentes