O que é Estimativa Ágil?

Estimar trabalho e planejar entregas são práticas anteriores aos métodos ágeis; não existe um criador único da Estimativa Ágil. Mike Cohn sistematizou técnicas de tamanho relativo, planejamento e revisão de previsões em Agile Estimating and Planning, publicado em 2005.

O Scrum Guide 2020 atribui aos Desenvolvedores o dimensionamento dos itens do Product Backlog e fala em previsão do trabalho de uma Sprint, mas não exige Story Points ou uma técnica específica. O Kanban Guide 2025 usa dados de fluxo e uma Service Level Expectation para expressar prazo com probabilidade. Essas abordagens podem ajudar a responder perguntas diferentes.

Antes de escolher uma técnica, pergunte o que precisa decidir. Uma estimativa pode ajudar a comparar alternativas, perceber que um item é grande demais, planejar capacidade aproximada, comunicar uma janela de entrega ou negociar escopo. Se a decisão não mudará com o número, calcular o número pode ser desperdício. A estimativa também pode servir à conversa: divergências entre pessoas revelam riscos e interpretações incompatíveis.

Separe tamanho, esforço e prazo. Tamanho relativo descreve como um item se compara a outro segundo critérios do time. Esforço refere-se ao trabalho necessário; prazo inclui filas, dependências, interrupções e disponibilidade. Um item pequeno pode demorar semanas se aguardar uma decisão externa. Um item grande pode avançar rapidamente quando várias pessoas colaboram sem espera. Converter automaticamente pontos em horas ou dias ignora essas diferenças.

Estimativa relativa. Um time pode escolher itens conhecidos como referência e dizer que um novo trabalho parece menor, semelhante ou maior. Story Points e tamanhos como P, M e G são formas de registrar essa comparação. A escala é local: oito pontos de um time não equivalem a oito de outro. O número não mede desempenho individual, não é moeda para cobrar pessoas e não torna o item pronto para ser construído. Itens muito amplos merecem divisão e investigação antes de um palpite detalhado.

Conversa estruturada. Planning Poker permite que pessoas escolham estimativas sem serem imediatamente influenciadas pela primeira voz. Quando aparecem valores distantes, pergunte que trabalho ou risco cada uma viu. Uma pessoa pode conhecer uma integração obrigatória; outra pode saber um caminho mais simples. O ganho principal pode ser o entendimento compartilhado. Se o grupo discute apenas qual número entrará na ferramenta, sem resolver a divergência, a cerimônia perdeu propósito.

Agrupamento rápido. Estimativa por afinidade compara muitos itens em conjunto e pode identificar os que exigem conversa adicional. É adequada quando a decisão pede uma visão grosseira do conjunto, não precisão para cada item. Se a maioria dos itens está longe da execução, investir minutos detalhando todos eles pode gerar uma base que ficará desatualizada. Refine mais perto da escolha real.

Histórico de entrega. O throughput mostra quantos itens foram concluídos por período no fluxo observado. Se o trabalho futuro for razoavelmente comparável ao histórico, essa distribuição pode apoiar previsão de quantos itens cabem num intervalo. O cycle time ajuda a expressar quanto tempo um item levou de início a fim; o lead time pode incorporar uma espera anterior, conforme fronteiras. Sem definir tipo de item, início e fim, o histórico pode parecer preciso e ser inadequado.

Previsão probabilística. Em vez de declarar uma data única como certeza, use cenários ou uma distribuição de resultados possíveis. Uma simulação de Monte Carlo, por exemplo, pode sortear valores a partir de um histórico de throughput para mostrar em quantos períodos um conjunto de itens poderia ser concluído, segundo as premissas. O cálculo não prevê mudanças inéditas de equipe, mercado ou escopo; ele apenas explicita variação observada. Uma faixa e sua probabilidade são mais honestas que uma data isolada, mas ainda precisam de contexto.

Service Level Expectation no Kanban. O Kanban Guide define uma expectativa de nível de serviço como previsão de quanto tempo um item deve levar de iniciado a concluído, com período e probabilidade. Ela se baseia em histórico quando disponível e pode começar como aproximação a ser revista. Isso ajuda a conversar sobre itens semelhantes num fluxo definido. Não responde automaticamente à data de terminar um projeto inteiro ou ao tempo antes de o item começar.

Previsão de Sprint no Scrum. Durante a Sprint Planning, o Product Owner discute objetivo e itens com os Desenvolvedores; estes selecionam trabalho e criam plano para o Incremento. Desempenho passado, capacidade futura e DoD informam a previsão. A Meta da Sprint orienta adaptação; o Sprint Backlog pode mudar conforme se aprende. Tratar a seleção inicial como contrato imutável compromete transparência.

Estimar para priorizar. Tamanho pode importar quando duas oportunidades têm valor e prazo diferentes, mas “menor primeiro” não é estratégia universal. Um item curto pode ter pouco valor; outro exige ação antes de uma janela se fechar. A pergunta econômica é o que se perde ao adiar. O verbete Custo do Atraso aprofunda essa escolha. Estimativa de esforço é uma entrada, não decisão automática de ordem.

No Estimates. Algumas equipes conseguem planejar com recortes pequenos e métricas de fluxo, reduzindo ou eliminando pontuação prévia por item. O verbete #NoEstimates explora esse recorte. Não estimar tamanho não significa deixar de prever prazos, investigar riscos ou conversar sobre capacidade. E estimar tamanho não significa abandonar dados históricos. A escolha depende da pergunta, do custo de coletar informação e da confiança no fluxo medido.

Quando dados históricos enganam. Uma mudança de produto, de composição do time, de Definition of Done ou de política de WIP pode tornar o passado menos representativo. Misturar correções pequenas com iniciativas grandes pode gerar médias irrelevantes. Uma amostra curta pode ter variação ainda não observada. Mostre essas condições ao comunicar a previsão e reveja os números à medida que o fluxo muda.

Como falar com stakeholders. Diga o recorte da previsão, o que foi assumido, qual grau de confiança é apropriado e o que pode mudar a resposta. “Com o escopo atual e o ritmo recente, esperamos concluir entre quatro e seis semanas; a integração externa ainda pode ampliar a faixa” oferece base para ação. Não é necessário recitar estatística em toda conversa. O essencial é distinguir hipótese de compromisso e explicar opções se o prazo for relevante: reduzir escopo, tratar dependência ou mudar prioridade.

Prazo fixo e escopo variável. Quando uma data é imposta por lei, evento ou contrato, a estimativa não muda o calendário. Ela informa o que provavelmente cabe até lá e que riscos precisam ser tratados. O time pode ordenar fatias por valor, reduzir escopo e preparar alternativas de entrega. Ocultar que o conjunto inteiro não cabe apenas transfere a decisão para o último dia, quando há menos opções. Se qualidade e segurança são obrigatórias, não devem ser variáveis de ajuste silenciosas.

Custos e orçamento. Uma organização pode precisar reservar dinheiro ou capacidade antes de ter detalhes completos. Nesse caso, estimativas por faixas e cenários de investimento podem ser suficientes para decidir se vale avançar para uma fase de descoberta ou uma primeira entrega. O orçamento deve ser revisto conforme a equipe aprende. Uma previsão financeira não exige fingir que cada item futuro já foi especificado e somado em horas.

O que medir depois. Compare previsões com resultados para aprender sobre tamanho, fluxo e riscos. Se uma previsão falha, pergunte se o escopo mudou, se houve fila não prevista ou se o histórico era inadequado. Não transforme erro em punição individual; isso incentiva acrescentar margem oculta e piora a informação. Uma boa prática de estimativa aprende com seus próprios desvios.

Software com Sprints. Imagine um time hipotético que quer adicionar confirmação de agendamento. Na conversa de refinamento, 5 pessoas atribuem tamanhos P, P, M, G e G ao mesmo item. A diferença aponta duas interpretações: algumas presumiram confirmação por e-mail; outras incluíram SMS e regras de cancelamento. O grupo divide o trabalho: primeiro, mostrar a confirmação na tela; depois, enviar aviso pelo canal escolhido. Antes, uma média das letras teria escondido a dúvida. Depois, o time tem recortes mais claros para selecionar na próxima Sprint. Não há conversão automática de P para dias.

Serviço fora de TI. Imagine uma equipe hipotética que responde solicitações de documentos. Nos últimos 8 períodos semanais, ela concluiu 6, 7, 5, 8, 6, 4, 7 e 5 solicitações semelhantes. Agora há 12 na fila, mas algumas exigem validação externa. Dizer “duas semanas” porque a média é perto de seis ignora variabilidade e dependências. A equipe pode usar a distribuição como referência inicial, separar os itens com validação externa e comunicar uma faixa. Se uma nova regra regulatória surgir, o histórico precisa ser revisto.

Coordenação em escala. Imagine 3 times trabalhando num mesmo produto. Um deles conclui pequenas mudanças de interface; outro mantém integrações complexas; o terceiro responde incidentes. Somar Story Points dos três para prever o projeto seria enganoso, pois as escalas locais e os tipos de trabalho diferem. A coordenação identifica resultados integrados e dependências, observa o throughput dos fluxos relevantes e modela cenários para as etapas críticas. Antes, a organização exibiria uma data única baseada numa soma sem significado. Depois, consegue ver que a aprovação externa domina a incerteza e discutir esse risco cedo.

Previsão numérica simples. Num cenário inventado, restam 10 itens semelhantes e o histórico semanal foi de 2, 3, 2 e 3 itens concluídos. Se o ritmo se repetisse exatamente, quatro semanas poderiam bastar. Mas o passado contém poucos períodos e o escopo pode mudar. O time comunica que quatro semanas é um cenário, não uma garantia; acompanha semanalmente itens concluídos, itens adicionados e bloqueios. Se três itens novos entrarem, recalcula a previsão. Uma simulação mais elaborada faria amostragens do histórico e mostraria uma distribuição, sem eliminar o risco de que o futuro seja diferente.

Esses casos demonstram propósitos diferentes. A conversa de tamanho descobre interpretações. O histórico ajuda a responder prazo de itens repetitivos. A coordenação entre times exige olhar dependências e resultados comuns. Usar uma técnica única para todos pode produzir números consistentes na aparência e decisões ruins na prática.

Cursos K21 recomendados