Story Points não são uma promessa
“Você disse que eram 5 pontos. Por que não ficou pronto?” Se você já ouviu isso, sabe o problema: stakeholders confundem estimativas com promessas.
A confusão natural
Para quem não vive no dia a dia de desenvolvimento, uma estimativa soa como uma garantia. “Se o time estimou 5 pontos e um ponto vale meio dia, deveria ter sido feito em 2,5 dias.” Essa lógica parece racional mas está errada em vários níveis.
Por que estimativas não são promessas
Estimativas são previsões, não contratos
Uma estimativa é o melhor palpite educado do time com as informações disponíveis no momento. Não é um compromisso com perfeição.
O escopo pode revelar surpresas
Só se descobre a complexidade real ao começar a implementar. “Ah, essa tabela tem 500 linhas que precisam migrar” é o tipo de descoberta que muda tudo.
Impedimentos externos
API de terceiros fora do ar, dependência com outro time, mudança de prioridade — muitos fatores fogem do controle do time.
A incerteza é inerente
Desenvolvimento de software é trabalho de conhecimento, não de linha de montagem. Se fosse previsível, já estaria automatizado.
Como comunicar isso
Use intervalos, não números fixos
Errado: “Vai levar 3 sprints.” Certo: “Com base na nossa velocidade atual, estimamos entre 3-4 sprints, com mais probabilidade para 3.”
Mostre o nível de confiança
“Para essas 5 tarefas, temos alta confiança (já fizemos similares). Para essas 3, confiança média (tecnologia nova). E essa aqui tem baixa confiança — pode ser 5 ou 13 pontos.”
Eduque progressivamente
Convide stakeholders para uma Sprint Review. Mostre o que o time entrega, explique como as estimativas funcionam, e como a velocidade se estabiliza ao longo do tempo.
O que oferecer em vez de promessas
Previsibilidade, não precisão
“Nos últimos 4 sprints, entregamos entre 22-26 pontos. Podemos prometer 22 pontos para o próximo sprint com alta confiança.”
Transparência em tempo real
Compartilhe o board e o burndown. Stakeholders que acompanham o progresso diário são menos propensos a cobrar prazos no final.
Opções, não respostas fixas
“Temos 3 caminhos: (1) reduzir escopo e manter a data, (2) manter escopo e mover a data, (3) reduzir qualidade — não recomendo a opção 3.”
Quando estimativas DEVEM ser mais precisas
Há situações onde a margem de erro precisa ser menor:
- Regulatório/compliance — deadlines impostos por lei
- Eventos com data fixa — Black Friday, lançamento
- Contratos com multas — implicações financeiras
Nesses casos:
- Adicione buffers maiores (30-40%)
- Faça spikes técnicos antes de estimar
- Comunique riscos cedo e frequentemente
- Tenha um plano B
Conclusão
Story Points são ferramentas de planejamento, não de compromisso. O papel do time e do Scrum Master é educar stakeholders sobre isso, com dados e transparência. Confiança se constrói com previsibilidade consistente, não com promessas perfeitas.