Pular para o conteudo principal

Como estimar trabalho com honestidade

Estimativa de rotina precisa de corte, risco e uma faixa honesta para o tipo de trabalho que entrou.

Andrews Ribeiro

Andrews Ribeiro

Founder & Engineer

O problema

Estimativa de trabalho vira bagunça quando o time tenta dar resposta definitiva para coisa que ainda está crua.

A conversa costuma ser:

  • “isso cabe nesta sprint?”
  • “quantos pontos colocamos?”
  • “dá para prometer até sexta?”

E aí entra o erro clássico:

pegar um trabalho mal entendido e empacotar como se fosse um número confiável.

Modelo mental

Pensa assim:

estimar trabalho não é adivinhar o futuro com mais convicção. É reduzir o trabalho até ele caber em uma leitura honesta.

Na prática, isso significa fazer três coisas antes de falar número:

  • cortar escopo
  • separar descoberta de execução
  • explicitar dependência e risco

Quando isso não acontece, a estimativa parece objetiva, mas é só frágil.

Quebrando o problema

Trabalho grande demais não deveria ser estimado como pacote único

Se o item ainda cabe em frases como:

  • “melhorar onboarding”
  • “refatorar autenticação”
  • “fechar integração com parceiro”

então ele ainda está mais perto de tema do que de trabalho estimável.

Antes do número, vale quebrar:

  • o que é alinhamento
  • o que é investigação
  • o que é implementação
  • o que é validação

Descoberta não deveria parecer implementação previsível

Esse é um erro que sabota sprint o tempo todo.

Tem parte do trabalho que o time domina.

Tem parte que depende de descobrir:

  • comportamento do legado
  • resposta de terceiro
  • regra ainda não fechada
  • gargalo ainda não reproduzido

Se tudo isso vira “três dias”, o problema não está no número. Está na mistura.

Faixa costuma ser melhor do que compromisso seco

Em vários contextos, resposta melhor é:

  • “a parte que controlamos cabe em um ou dois dias”
  • “se a dependência responder bem, fechamos nesta sprint”
  • “o cenário base cabe; o risco está concentrado aqui”

Isso não enfraquece a resposta.

Isso deixa a resposta mais útil.

Estimativa boa precisa caber no ritual do time

Em planning, a estimativa não serve para parecer sofisticado.

Ela serve para ajudar o time a decidir:

  • o que entra
  • o que fica de fora
  • o que precisa ser quebrado antes
  • onde o risco está concentrado

Quando a conversa vira defesa de número, o ritual já começou errado.

Exemplo simples

Imagine uma task:

adicionar múltiplos cupons no checkout.

Resposta fraca:

  • “acho que é coisa de dois dias”

Resposta melhor:

  • regra de negócio: ainda precisa fechar com produto
  • cálculo no backend: o time conhece
  • efeito em recibo e analytics: precisa validar
  • maior risco: cupom cumulativo quebrar descontos existentes

Daí a estimativa fica menos fantasiosa:

Se a regra fechar sem exceção nova, a implementação conhecida cabe em dois dias. Se entrar descoberta em cálculo ou exceção promocional, o item precisa ser recortado porque deixa de ser trabalho previsível.

Erros comuns

  • Estimar tema vago em vez de trabalho cortado.
  • Tratar investigação como se fosse execução previsível.
  • Usar um número único para parecer mais confiante.
  • Esconder dependência dentro da estimativa.
  • Sair do planning com sensação de precisão e sem clareza de hipótese.

Como um senior pensa

Quem está mais maduro tenta proteger a honestidade operacional do time.

Então a conversa fica mais próxima de:

  • o que já está entendível o suficiente para entrar
  • o que ainda precisa de recorte
  • que parte é aposta
  • o que precisa ser separado em spike, fase ou item menor

Isso reduz frustração porque evita prometer como sólido algo que ainda está mole.

O que o entrevistador quer ver

Quando esse tema aparece em entrevista, o avaliador costuma procurar:

  • capacidade de quebrar trabalho
  • noção de risco e dependência
  • honestidade sobre incerteza
  • critério para transformar ambiguidade em plano

Uma resposta forte costuma soar assim:

Eu tento não estimar pacote amorfo. Primeiro separo o que é trabalho conhecido, o que é descoberta e o que depende de terceiro. Se ainda estiver grande demais, eu recorto antes de falar número. Quando faz sentido, prefiro faixa ou cenário com hipótese explícita a um compromisso seco que só parece seguro na reunião.

Estimativa útil não é a que parece mais exata. É a que ajuda o time a decidir melhor o que cabe agora.

Resumo rápido

O que vale manter na cabeça

Checklist de pratica

Use isto ao responder

Você concluiu este artigo

Próximo artigo O que é "done" de verdade e por que a definição importa Artigo anterior Scrum vs Kanban

Continue explorando

Artigos relacionados