Estimativas Agile e previsões: pontos, capacidade e confiança

Estimativa ≠ compromisso: para que estimamos em Agile

Em gestão de projetos com Agile, estimativas existem para prever cenários e apoiar decisões (priorização, sequenciamento, alocação de pessoas, negociação de escopo e datas). Elas não são uma promessa de entrega “exata”. Uma boa estimativa é aquela que permite responder perguntas como:

• “Se mantivermos o time como está, qual a faixa provável de entrega até o fim do trimestre?”
• “Se adicionarmos 1 pessoa, quanto a previsão muda (e com qual risco)?”
• “Se o escopo crescer 20%, qual o impacto provável?”

Para isso, estimativas ágeis trabalham com incerteza explícita e com dados históricos sempre que possível. O objetivo é aumentar a confiança gradualmente conforme aprendemos (refinamento, descoberta, execução e feedback).

Dois tipos de “tamanho” que você precisa separar

• Tamanho do trabalho: quão grande/complexo é um item (história, tarefa, épico). Ex.: pontos, T-shirt sizes, classes de serviço.
• Capacidade do time: quanto trabalho o time consegue concluir em um período, dadas as restrições reais (pessoas, férias, suporte, interrupções, dependências).

Previsão surge da combinação: tamanho + capacidade + variabilidade.

Planning Poker (pontos): estimando por comparação

Planning Poker é uma técnica colaborativa para estimar tamanho relativo (não horas). Em vez de discutir “quanto tempo”, o time compara itens entre si e cria uma escala consistente. Pontos funcionam bem quando o time entrega em iterações e quer um indicador agregado para forecast.

Quando usar

• Backlog com itens pequenos o suficiente para caberem em uma iteração (ou que possam ser quebrados).
• Time estável o bastante para criar uma referência comum.
• Você precisa de previsões baseadas em velocidade histórica (com cuidado, ver seção de velocidade).

Passo a passo prático (Planning Poker)

1. Defina a escala (ex.: Fibonacci: 1, 2, 3, 5, 8, 13, 21). Evite muitos números intermediários para forçar decisões.
2. Escolha uma história de referência (ex.: uma história já entregue e bem compreendida) e atribua um valor (ex.: 5 pontos). Essa história vira âncora.
3. Apresente a história: objetivo, critérios de aceitação, dependências conhecidas, riscos.
4. Estimativa silenciosa: cada pessoa escolhe uma carta (número) sem influenciar os demais.
5. Revelação simultânea: todos mostram ao mesmo tempo.
6. Discuta divergências: foque nos extremos (maior e menor). Perguntas úteis: “O que você está assumindo que os outros não estão?”
7. Reestime até convergir (ou aceite uma faixa e trate como risco).
8. Registre suposições relevantes (ex.: “depende da API X estar disponível”). Isso melhora previsões futuras.

Exemplo prático

História: “Como analista, quero exportar relatório em CSV com filtros aplicados.” Referência: “Exportar PDF simples” foi 5 pontos. O time discute e percebe que CSV exige mapeamento de campos, volume grande e performance. Estimativas: 5, 8, 13. Após discutir, convergem em 8 com nota: “risco de performance; pode virar 13 se volume real for maior”.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Erros comuns no Planning Poker (e correções)

• Converter pontos em horas automaticamente: isso transforma pontos em contrato de tempo e destrói o propósito. Correção: use pontos para comparação e use histórico para forecast; se precisar de horas, trate como planejamento interno de curto prazo, não como métrica de performance.
• Estimar sem critérios claros: vira chute. Correção: antes de estimar, alinhe critérios de aceitação e principais riscos.
• “Vencer no grito”: a pessoa mais sênior impõe o número. Correção: mantenha estimativa silenciosa e peça que extremos expliquem suposições.
• Itens grandes demais (ex.: 40 pontos): previsibilidade cai. Correção: quebre em itens menores; se não der, use T-shirt size/épicos e forecast por throughput.

T-shirt sizes: estimativa rápida para níveis mais altos

T-shirt sizes (XS, S, M, L, XL) são úteis quando você precisa de estimativa rápida com baixa precisão, especialmente para épicos/iniciativas, triagem inicial e conversas com stakeholders. Elas funcionam bem para ordenar e identificar itens que precisam de decomposição.

Como aplicar na prática

1. Defina o significado de cada tamanho com exemplos reais (ex.: S = mudança simples em tela existente; L = envolve múltiplos sistemas e validações).
2. Crie um “catálogo” de referência: 2–3 exemplos por tamanho, já entregues.
3. Classifique em grupo (rápido): para cada item, escolha o tamanho mais provável.
4. Use regras de decisão: itens L/XL não entram em planejamento de curto prazo sem decomposição.

Convertendo T-shirt para números (com cuidado)

Às vezes é útil mapear tamanhos para uma escala numérica (ex.: XS=1, S=2, M=3, L=5, XL=8) para fazer simulações. Faça isso apenas como ponte para forecast e sempre valide com histórico. Evite usar o mapeamento como “contrato”.

Erros comuns (e correções)

• Tamanhos viram opinião sem referência. Correção: mantenha exemplos âncora e revise periodicamente.
• Usar T-shirt para microplanejamento. Correção: use para triagem e roadmap; para execução, refine e estime em nível adequado.

Estimativa por throughput: previsões sem pontos

Throughput é a quantidade de itens concluídos por unidade de tempo (ex.: histórias concluídas por semana). Em vez de estimar “tamanho”, você mede entrega real e usa o histórico para prever. Essa abordagem é especialmente útil quando:

• O time trabalha com itens relativamente homogêneos (ou consegue padronizar o “tamanho” dos itens).
• Há muita variabilidade e pontos não trazem consistência.
• Você quer previsões mais objetivas e baseadas em dados.

Pré-requisito: padronizar o que conta como “item”

Throughput só é útil se “item concluído” tiver significado consistente. Ex.: “história pronta” com critérios claros de pronto e itens fatiados em tamanhos semelhantes.

Passo a passo prático (forecast por throughput)

1. Defina a unidade: semana, quinzena ou iteração.
2. Coleta histórica: registre quantos itens foram concluídos em cada período (ex.: últimas 8–12 semanas).
3. Calcule uma faixa: use percentis simples para comunicar variabilidade. Ex.: P50 (mediana) e P85 (mais conservador).
4. Estime o backlog em número de itens: quantos itens faltam para o objetivo (ou para um conjunto de features).
5. Projete a data: tempo ≈ itens restantes / throughput. Faça isso para P50 e P85 para ter uma faixa de previsão.

Exemplo numérico

Histórico semanal de itens concluídos (12 semanas): 6, 5, 7, 4, 6, 8, 5, 6, 7, 3, 6, 5. Mediana (P50) ≈ 6 itens/semana. Um valor conservador (aprox. P85 para “tempo”, ou seja, throughput mais baixo) pode ser 5 itens/semana. Se faltam 30 itens:

• Previsão P50: 30/6 = 5 semanas
• Previsão conservadora: 30/5 = 6 semanas

Você comunica: “Provável entre 5 e 6 semanas, assumindo que o padrão de trabalho se mantenha”.

Erros comuns (e correções)

• Itens com tamanhos muito diferentes distorcem throughput. Correção: fatiar melhor e/ou separar classes (ex.: “histórias pequenas” vs “médias”).
• Contar itens parcialmente prontos. Correção: conte apenas concluídos com critérios de pronto atendidos.

Forecast com base histórica: faixas de previsão e confiança

Previsão ágil madura é feita em faixas, não em uma data única. A faixa reflete incerteza real: variação de demanda, interrupções, dependências e mudanças.

Três formas práticas de criar faixas

• Percentis com throughput: como no exemplo, use P50/P85 para comunicar “provável” e “conservador”.
• Velocidade histórica (pontos por iteração): use média/mediana e variação para projetar quantas iterações são necessárias para um total de pontos.
• Simulação simples (Monte Carlo): sorteie valores históricos de throughput/velocidade para simular muitos cenários e obter probabilidades de datas. Mesmo sem ferramenta, dá para fazer em planilha.

Passo a passo (faixa por velocidade em pontos)

1. Some o tamanho do escopo (ex.: 120 pontos para um conjunto de histórias).
2. Levante a velocidade histórica (ex.: últimas 6 iterações: 18, 22, 15, 20, 19, 21).
3. Use mediana e um cenário conservador: mediana ≈ 19,5 (arredonde para 20). Conservador pode ser 18 (ou um percentil mais baixo).
4. Calcule iterações necessárias: 120/20 = 6 iterações (provável); 120/18 ≈ 6,7 (conservador: 7 iterações).
5. Converta para datas considerando calendário real (feriados, releases, janelas de aprovação).

Como comunicar confiança sem “vender certeza”

Use linguagem de probabilidade e condições. Modelos úteis:

• Faixa com probabilidade: “Temos ~50% de chance até 10/mai e ~85% até 24/mai.”
• Data-alvo + data de compromisso: “Alvo: 10/mai (se nada mudar). Compromisso: 24/mai (com margem para variabilidade).”
• Escopo variável: “Até 10/mai entregamos com alta confiança as features A e B; C é opcional dependendo do throughput.”

Inclua sempre as premissas que sustentam a previsão (ex.: time estável, dependência X resolvida até tal data, WIP controlado, sem aumento de suporte).

Velocidade e capacidade: como usar com cuidado

Velocidade (pontos concluídos por iteração)

Velocidade é um indicador interno do time para ajudar a prever. Ela é útil quando o time estima de forma consistente e mantém um padrão de fatiamento. Porém, velocidade é sensível a mudanças de contexto.

Capacidade (tempo/pessoas disponíveis)

Capacidade é a disponibilidade real do time no período. Ela ajuda a ajustar previsões quando há férias, treinamentos, suporte, incidentes ou mudanças na composição do time.

Boas práticas para combinar capacidade e velocidade

• Não “recalibre” pontos para caber na capacidade. Ajuste o escopo ou a previsão, não o tamanho.
• Use capacidade para ajustar expectativa: se 30% do time estará em suporte, espere queda no throughput/velocidade.
• Trate mudanças de time como “reset parcial” do histórico: entradas/saídas podem alterar a distribuição de entrega.
• Separe trabalho planejado de trabalho não planejado: registre interrupções para explicar variação e melhorar previsões.

Erro comum: usar velocidade como meta

Quando velocidade vira meta, surgem distorções: inflar pontos, fatiar artificialmente, reduzir qualidade para “fechar” mais pontos. Correção: velocidade é métrica de previsão, não de performance. Avalie performance por resultados (valor entregue, qualidade, satisfação, redução de risco) e use velocidade apenas para planejamento.

Técnicas rápidas de forecast para conversas com stakeholders

1) Forecast por “itens restantes” (quando não há pontos)

Se você tem 40 itens restantes e o throughput histórico varia entre 5 e 8 itens/semana, comunique: “Entre 5 e 8 semanas, com maior probabilidade em ~6–7 semanas”.

2) Forecast por “pontos restantes” (quando há pontos)

Se faltam 90 pontos e a velocidade típica varia entre 15 e 22 pontos/iteração, comunique: “Entre 5 e 6 iterações; mais provável 5, conservador 6”.

3) Forecast com escopo fixo vs escopo variável

• Escopo fixo: data vira variável (faixa de datas). Útil para compromissos regulatórios, contratos, eventos.
• Data fixa: escopo vira variável (faixa de escopo). Útil para janelas de mercado, campanhas, releases.

Uma forma prática de apresentar escopo variável é listar Must/Should/Could (sem repetir técnicas de priorização): “Must” entra com alta confiança; “Should” depende do cenário provável; “Could” apenas no cenário otimista.

Erros comuns de estimativas e previsões (e como corrigir)

Checklist prático para uma previsão confiável

• Itens estão fatiados em tamanho consistente (ou classificados por tamanho)?
• Definição de concluído está clara para contar throughput/velocidade?
• Histórico suficiente (ideal: 8–12 períodos) e representativo do contexto atual?
• Capacidade do período considerada (férias, suporte, mudanças de time)?
• Faixa de previsão definida (P50/P85 ou provável/conservador)?
• Premissas e riscos explicitados para stakeholders?
• Revisão periódica do forecast com dados reais (cadência fixa)?