Técnicas de Estimativa de Projeto
Estime trabalho de projeto com precisão usando técnicas comprovadas. Melhore estimativas ao longo do tempo com calibração e dados históricos.
8 min de leitura
Estimativa precisa é a fundação de planejamento realista—subestime e você perde prazos, superestime e você perde confiança. Os effort points e dados históricos de velocity do GitScrum ajudam times a calibrar estimativas contra performance real, melhorando a precisão ao longo do tempo. A chave é tratar estimativa como uma habilidade a desenvolver, não uma ciência exata.
Abordagens de Estimativa
| Técnica | Melhor Para | Precisão | Esforço |
|---|---|---|---|
| Story Points | Sprint planning | Média-Alta | Médio |
| Planning Poker | Consenso do time | Média-Alta | Médio |
| T-Shirt Sizing | Planejamento roadmap | Baixa-Média | Baixo |
| Dados Históricos | Forecasting | Alta | Baixo |
| Três Pontos | Estimativas conscientes de risco | Média-Alta | Alto |
Estimativa com Story Points
FUNDAMENTOS DE STORY POINT
O QUE POINTS REPRESENTAM:
┌─────────────────────────────────────────────────┐
│ Story points medem esforço relativo: │
│ │
│ Esforço = Complexidade + Incerteza + Volume │
│ │
│ NÃO medido em horas porque: │
│ ├── Pessoas diferentes trabalham em velocidades│
│ │ diferentes │
│ ├── Mesma pessoa varia dia a dia │
│ └── Points são mais estáveis ao longo do tempo │
└─────────────────────────────────────────────────┘
ESCALA DE POINTS (Fibonacci):
┌─────────────────────────────────────────────────┐
│ 1 point: Trivial, bem entendido │
│ Exemplo: Mudança de texto, update cfg│
│ │
│ 2 points: Pequeno, direto │
│ Exemplo: Adicionar campo ao form │
│ │
│ 3 points: Médio, alguma complexidade │
│ Exemplo: Novo endpoint API │
│ │
│ 5 points: Grande, múltiplos componentes │
│ Exemplo: Feature com UI + backend │
│ │
│ 8 points: Muito grande, unknowns significativos│
│ Exemplo: Nova integração │
│ Considerar: Deveria ser dividido? │
│ │
│ 13 points: Tamanho de épico, muito grande │
│ Deve ser quebrado │
└─────────────────────────────────────────────────┘
STORIES DE REFERÊNCIA:
┌─────────────────────────────────────────────────┐
│ Estabelecer stories de calibração do time: │
│ │
│ "Adicionar novo widget no dashboard" = 3 pts │
│ "Bug fix simples" = 1 point │
│ "Nova feature end-to-end" = 5-8 points │
│ │
│ Comparar novas stories com referências: │
│ "Isso é mais difícil ou fácil que o widget?" │
└─────────────────────────────────────────────────┘
Planning Poker
PROCESSO DE PLANNING POKER
SETUP:
┌─────────────────────────────────────────────────┐
│ Participantes: Time de desenvolvimento (todos │
│ que vão trabalhar nos itens) │
│ │
│ Cartas: 0, 1, 2, 3, 5, 8, 13, ?, ☕ │
│ ├── 0: Já feito ou trivial │
│ ├── 1-13: Estimativas em story points │
│ ├── ?: Precisa mais informação │
│ └── ☕: Precisa de um break │
└─────────────────────────────────────────────────┘
PROCESSO:
┌─────────────────────────────────────────────────┐
│ 1. Product Owner lê user story │
│ │
│ 2. Time faz perguntas de clarificação │
│ (Time-box: 2-3 minutos) │
│ │
│ 3. Todos selecionam uma carta privadamente │
│ │
│ 4. Todos revelam simultaneamente │
│ │
│ 5. Discutir diferenças: │
│ ├── Mais alto: "Por que você acha 8?" │
│ ├── Mais baixo: "Por que você acha 2?" │
│ └── Discussão revela complexidade oculta │
│ │
│ 6. Re-votar se necessário │
│ (Geralmente converge em 2 rodadas) │
│ │
│ 7. Registrar estimativa de consenso │
└─────────────────────────────────────────────────┘
EXEMPLOS DE DISCUSSÃO:
┌─────────────────────────────────────────────────┐
│ Cenário: Votos são 2, 3, 3, 5, 8 │
│ │
│ Facilitador: "@alto, por que 8?" │
│ @alto: "Precisamos atualizar o sistema auth │
│ legado, que sempre é problemático." │
│ │
│ Facilitador: "@baixo, por que 2?" │
│ @baixo: "Achei que era só adicionar um │
│ botão. Não sabia que auth estava envolvido." │
│ │
│ Resultado: Time agora tem mesmo entendimento │
│ Re-voto: 5, 5, 5, 5, 8 → Consenso em 5 │
└─────────────────────────────────────────────────┘
T-Shirt Sizing
T-SHIRT SIZING PARA ROADMAP
ESCALA T-SHIRT:
┌─────────────────────────────────────────────────┐
│ XS: < 1 semana de trabalho │
│ P: 1-2 semanas │
│ M: 2-4 semanas │
│ G: 1-2 meses │
│ XG: 2-3 meses │
│ XXG: 3+ meses (precisa breakdown) │
└─────────────────────────────────────────────────┘
EXEMPLO DE ROADMAP:
┌─────────────────────────────────────────────────┐
│ Iniciativas Q2 2025: │
│ │
│ ├── Redesign app mobile [G] │
│ ├── Migração API v3 [XG] │
│ ├── Melhorias de performance [M] │
│ ├── Refresh dashboard usuário [M] │
│ └── Fixes de audit de segurança [P] │
│ │
│ Capacidade: 1 G + 2 M + 2 P por trimestre │
│ Carga atual: 1 XG + 1 G + 2 M + 1 P │
│ Decisão: Adiar API v3 ou obter mais capacidade │
└─────────────────────────────────────────────────┘
CONVERTENDO T-SHIRT PARA POINTS DE SPRINT:
┌─────────────────────────────────────────────────┐
│ Após aprovação do roadmap, quebrar: │
│ │
│ Redesign app mobile [G]: │
│ ├── Pesquisa UX & design: 20 pts │
│ ├── Navegação core: 25 pts │
│ ├── Paridade de features: 35 pts │
│ └── Polish & testes: 15 pts │
│ Total: 95 pts ≈ 3 sprints a 30 pts/sprint │
└─────────────────────────────────────────────────┘
Estimativa de Três Pontos
ESTIMATIVA DE TRÊS PONTOS
FÓRMULA:
┌─────────────────────────────────────────────────┐
│ Esperado = (Otimista + 4×MaisProvável + Pess) │
│ ───────────────────────────────── │
│ 6 │
│ │
│ Desvio Padrão = (Pessimista - Otimista) │
│ ───────────────────────── │
│ 6 │
└─────────────────────────────────────────────────┘
EXEMPLO:
┌─────────────────────────────────────────────────┐
│ Feature: Integração de pagamento │
│ │
│ Otimista: 2 semanas (tudo dá certo) │
│ Mais Provável:4 semanas (bumps normais) │
│ Pessimista: 8 semanas (issues maiores) │
│ │
│ Esperado = (2 + 4×4 + 8) / 6 = 4.3 semanas │
│ Desv Pad = (8 - 2) / 6 = 1 semana │
│ │
│ Estimativa: 4-5 semanas (com intervalo confiança)│
│ Dizer stakeholders: "Planeje para 5 semanas" │
└─────────────────────────────────────────────────┘
Melhorando Estimativas
CALIBRAÇÃO DE ESTIMATIVA
RASTREAR ATUAL VS ESTIMADO:
┌─────────────────────────────────────────────────┐
│ Análise Sprint 22: │
│ │
│ Story Estimado Atual Variância │
│ ────────────────────────────────────────── │
│ Perfil usuário 3 3 0% │
│ Filtro busca 5 8 +60% │
│ Dashboard 5 4 -20% │
│ Endpoint API 3 3 0% │
│ Export relatório 5 7 +40% │
│ │
│ Variância média: +16% │
│ Maior erro: Filtro busca │
│ │
│ Discutir: Por que filtro busca foi subestimado?│
│ Aprendizado: Filtragem com múltiplas fontes de │
│ dados é mais complexo que esperado. │
└─────────────────────────────────────────────────┘
LOOP DE MELHORIA DE ESTIMATIVA:
┌─────────────────────────────────────────────────┐
│ 1. Estimar antes do sprint │
│ 2. Rastrear tempo real durante sprint │
│ 3. Comparar no fim do sprint │
│ 4. Discutir grandes variâncias na retro │
│ 5. Atualizar stories de referência se preciso │
│ 6. Aplicar aprendizados às próximas estimativas│
│ │
│ Ao longo do tempo: Estimativas ficam mais │
│ precisas │
└─────────────────────────────────────────────────┘
ERROS COMUNS DE ESTIMATIVA:
┌─────────────────────────────────────────────────┐
│ ✗ Esquecer tempo de testes │
│ ✗ Ignorar ciclos de code review │
│ ✗ Não contabilizar reuniões │
│ ✗ Assumir melhor cenário │
│ ✗ Comparar com velocidade do dev senior │
│ ✗ Subestimar complexidade de integração │
│ ✗ Subestimar unknowns │
│ │
│ Fix: Incluir todo trabalho, adicionar buffer │
└─────────────────────────────────────────────────┘
Melhores Práticas
Anti-Padrões
✗ Uma pessoa estima para o time
✗ Converter points diretamente para horas
✗ Nunca revisar precisão de estimativas
✗ Estimar itens que não são entendidos
✗ Punir estimativas erradas
✗ Inflar todas estimativas