UMA ABORDAGEM PRÁTICA

Quando voltar a estimar uma tarefa de software?

Uma estimativa reflete o que se sabia naquele momento. Novos dados podem justificar uma revisão.

3 min de leitura

Quando isto importa

Surge uma integração não documentada, o design muda após o refinement ou um pressuposto importante revela-se errado. Manter o número antigo não protege o plano. Vale a pena reestimar quando a mudança afeta de forma significativa a capacidade, o custo ou a data.

Uma abordagem prática

  • Guarda o intervalo, o nível de confiança e os pressupostos originais. Sem esta base é difícil explicar a alteração.
  • Separa novo âmbito de nova informação sobre o âmbito antigo. Uma funcionalidade adicional precisa de estimativa própria; uma dependência descoberta altera a anterior.
  • Estima o trabalho que falta e mostra separadamente o que já foi feito. Assim o progresso continua visível.
  • Apresenta o novo intervalo, o valor de planeamento e o impacto noutras tarefas. Define quem aprova mudanças de âmbito ou prazo.

Exemplo

Um ticket tinha 8–12 horas assumindo que a API já disponibilizava o estado do cliente. Após quatro horas, descobre-se a necessidade de um endpoint novo e uma revisão de permissões. O trabalho restante passa a 10–16 horas. Comunica as quatro horas feitas, o novo intervalo e a decisão sobre a API; não substituas silenciosamente o valor inicial.

Decidir o passo seguinte

Volta a estimar após uma descoberta relevante, não por cada pequena interrupção. Se a confiança for baixa, limita uma investigação curta e marca a próxima revisão. A estimativa inicial documenta o conhecimento da altura. A ferramenta ajuda a construir um novo intervalo para o âmbito confirmado.

Abrir a ferramenta.

← Voltar aos recursos