Story Points vs Effort Points: Guia de Estimativa

Story points e effort points medem a complexidade do trabalho, mas abordam a estimativa de maneira diferente. O GitScrum usa effort points com uma escala simplificada (XS a XL) que inclui guias de horas, tornando a estimativa mais acessível para os times enquanto mantém os benefícios do dimensionamento relativo dos story points.

Visão Geral Comparativa

Entendendo Story Points

STORY POINTS TRADICIONAIS
═════════════════════════

CONCEITO:
─────────────────────────────────────
Story points medem complexidade RELATIVA
Não horas, não dias - comparação pura

"Quão complexa é a Tarefa B vs Tarefa A?"
Se Tarefa A = 3 pontos e Tarefa B é o dobro
Então Tarefa B = 5 ou 8 pontos

ESCALA FIBONACCI:
─────────────────────────────────────
1  - Trivial (linha base de referência)
2  - Simples
3  - Pequeno
5  - Médio
8  - Grande
13 - Muito grande
21 - Épico (deve ser dividido)

POR QUE FIBONACCI?
─────────────────────────────────────
├── A incerteza cresce com o tamanho
├── Difícil distinguir 14 vs 15
├── Os gaps forçam escolhas significativas
└── Reflete limites naturais de estimativa

EXEMPLO:
─────────────────────────────────────
Tarefa de referência: "Adicionar validação ao form" = 3 pts

Comparando novas tarefas:
├── "Mudar cor do botão" → menor → 1 pt
├── "Adicionar date picker" → similar → 3 pts
├── "Construir dashboard usuário" → muito maior → 13 pts
└── "Implementar sistema auth" → épico → 21 pts (dividir!)

Entendendo Effort Points

EFFORT POINTS DO GITSCRUM
═════════════════════════

CONCEITO:
─────────────────────────────────────
Effort points combinam dimensionamento
relativo com guias opcionais de horas

Mesmos benefícios de comparação relativa
Mais referências práticas de tempo

ESCALA DE TAMANHOS COM HORAS:
─────────────────────────────────────
┌────────┬─────────┬─────────────────────┐
│ Tamanho│ Pontos  │ Duração Típica      │
├────────┼─────────┼─────────────────────┤
│ XS     │ 1       │ Menos de 2 horas    │
│ S      │ 2       │ 2-4 horas           │
│ M      │ 3       │ 4-8 horas (1 dia)   │
│ L      │ 5       │ 1-2 dias            │
│ XL     │ 8       │ 2-5 dias            │
└────────┴─────────┴─────────────────────┘

POR QUE FUNCIONA:
─────────────────────────────────────
├── Simples de entender
├── Apenas 5 opções para escolher
├── Guias de horas reduzem debates
├── Ainda permite rastreamento de velocidade
└── Funciona para times novos e experientes

EXEMPLO:
─────────────────────────────────────
Tarefa: "Adicionar edição de perfil de usuário"

Quebrando:
├── Correção rápida? Menos de 2 hrs? → XS (1 pt)
├── Trabalho de meio dia? → S (2 pts)
├── Esforço de dia inteiro? → M (3 pts)
├── Alguns dias? → L (5 pts)
└── Semana de trabalho? → XL (8 pts)

Consenso do time: "Uns 2 dias" → L (5 pts)

Quando Usar Cada Um

ESCOLHENDO SUA ABORDAGEM
════════════════════════

USE EFFORT POINTS QUANDO:
─────────────────────────────────────
✓ Time novo em estimativa ágil
✓ Stakeholders perguntam "quanto tempo?"
✓ Precisa de referências concretas de planejamento
✓ Níveis de experiência mistos no time
✓ Mais simples é melhor para seu contexto
✓ Convertendo de estimativas em horas

USE STORY POINTS QUANDO:
─────────────────────────────────────
✓ Time tem prática madura de estimativa
✓ Complexidade abstrata funciona bem
✓ Precisa de granularidade Fibonacci
✓ Time resiste associações de tempo
✓ Grande variação em velocidades individuais
✓ Já tem velocidade estabelecida

ABORDAGEM HÍBRIDA:
─────────────────────────────────────
Effort points do GitScrum suportam ambos:
├── Use tamanhos (visual)
├── Rastreie valores de pontos (numérico)
├── Referencie horas (opcional)
└── Calcule velocidade (igual story points)

Técnicas de Estimativa

COMO ESTIMAR
════════════

PLANNING POKER:
─────────────────────────────────────
1. Apresente a tarefa/story
2. Discuta requisitos
3. Todos escolhem tamanho simultaneamente
4. Revelar escolhas
5. Discutir outliers
6. Re-votar se necessário
7. Consenso ou média

Exemplo de sessão:
┌─────────────────────────────────────┐
│ Tarefa: "Implementar reset senha"   │
├─────────────────────────────────────┤
│ Voto 1:                             │
│ Dev A: M    Dev B: L    Dev C: M    │
│                                     │
│ Discussão: "E o email?"             │
│ Dev B: "Esqueci do template"        │
│                                     │
│ Voto 2:                             │
│ Dev A: M    Dev B: M    Dev C: M    │
│                                     │
│ Consenso: M (3 pontos)              │
└─────────────────────────────────────┘

TAMANHOS DE CAMISETA:
─────────────────────────────────────
Método rápido de dimensionamento:

1. Ordenar tarefas por complexidade
2. Atribuir tamanhos
3. Converter para pontos

┌────────────────────────────────────────┐
│ XS │ S │ M │ L │ XL │                  │
├────┼───┼───┼───┼────┤                  │
│ T1 │T2 │T4 │T6 │ T8 │ ← Tarefas orden. │
│    │T3 │T5 │T7 │    │                  │
│    │   │   │   │    │                  │
└────┴───┴───┴───┴────┘

COMPARAÇÃO DE REFERÊNCIA:
─────────────────────────────────────
1. Estabelecer tarefas de referência por tamanho
2. Comparar novas tarefas com referências
3. Combinar com referência mais próxima

Biblioteca de referências:
├── XS: "Atualizar valor de config"
├── S:  "Adicionar validação de form"
├── M:  "Criar novo endpoint API"
├── L:  "Construir widget de dashboard"
└── XL: "Implementar integração"

Planejamento de Sprint com Pontos

PLANEJAMENTO DE CAPACIDADE
══════════════════════════

CALCULANDO CAPACIDADE:
─────────────────────────────────────
Time: 4 desenvolvedores
Sprint: 2 semanas (10 dias úteis)
Velocidade histórica: 35-40 pts/sprint

Capacidade disponível:
├── Considerar PTO, reuniões
├── Incluir buffer para imprevistos
└── Não comprometer demais

Exemplo:
┌─────────────────────────────────────┐
│ CAPACIDADE DO SPRINT                │
├─────────────────────────────────────┤
│ Velocidade histórica: 38 pts avg    │
│ Este sprint:                        │
│ ├── Dev A: Completo (10 dias)       │
│ ├── Dev B: Completo (10 dias)       │
│ ├── Dev C: 8 dias (2 PTO)           │
│ └── Dev D: Completo (10 dias)       │
│                                     │
│ Capacidade ajustada: 38 × 0.9 = 34pt│
│ Buffer (10%): 3 pts                 │
│ Compromisso seguro: 31 pts          │
└─────────────────────────────────────┘

BACKLOG DO SPRINT:
─────────────────────────────────────
┌─────────────────────────────────────┐
│ Story/Tarefa           │ Effort    │
├────────────────────────┼───────────┤
│ Edição perfil usuário  │ L (5 pts) │
│ Fluxo reset senha      │ M (3 pts) │
│ Widgets dashboard      │ L (5 pts) │
│ API rate limiting      │ M (3 pts) │
│ Bug: Login timeout     │ S (2 pts) │
│ Notificações email     │ L (5 pts) │
│ Página de settings     │ M (3 pts) │
│ Atualizar docs         │ S (2 pts) │
├────────────────────────┼───────────┤
│ TOTAL COMPROMETIDO     │ 28 pts    │
│ Buffer restante        │ 3 pts     │
└────────────────────────┴───────────┘

Rastreamento de Velocidade

MEDINDO VELOCIDADE
══════════════════

O QUE É VELOCIDADE?
─────────────────────────────────────
Pontos completados por sprint
Média ao longo do tempo = capacidade previsível

Sprint    │ Comprometido│ Completado
──────────┼─────────────┼──────────
Sprint 1  │ 35 pts      │ 32 pts
Sprint 2  │ 35 pts      │ 36 pts
Sprint 3  │ 38 pts      │ 35 pts
Sprint 4  │ 35 pts      │ 38 pts
Sprint 5  │ 38 pts      │ 37 pts
──────────┼─────────────┼──────────
Média     │             │ 35.6 pts

GRÁFICO DE VELOCIDADE:
─────────────────────────────────────
Pontos│
   40 │      ■         ■
      │  ■       ■         ■
   35 │──────────────────────  Média
      │
   30 │  ■
      │
   25 ├──────────────────────────
      S1  S2  S3  S4  S5  S6

USANDO VELOCIDADE:
─────────────────────────────────────
├── Planejar futuros sprints
├── Projetar datas de conclusão
├── Identificar mudanças de capacidade
├── Detectar deriva nas estimativas
└── Comunicar com stakeholders

Exemplo de projeção:
Trabalho restante: 180 pontos
Velocidade: 36 pts/sprint
Sprints estimados: 5 (10 semanas)

Erros Comuns

ANTI-PADRÕES DE ESTIMATIVA
══════════════════════════

ERRO 1: CONVERTER PARA HORAS
─────────────────────────────────────
❌ "1 ponto = 4 horas"
❌ "Quantas horas é um L?"
❌ Tratar pontos como unidades de tempo

✓ Pontos medem complexidade, não tempo
✓ Guias de horas são referências, não regras
✓ Velocidade normaliza com o tempo

ERRO 2: ESTIMATIVAS INDIVIDUAIS
─────────────────────────────────────
❌ "Isso é 5 pontos para mim"
❌ Ajustar por velocidade individual
❌ Escalas diferentes por pessoa

✓ Estimativas de time (consenso)
✓ Escala única para todos
✓ Velocidade considera mix do time

ERRO 3: NUNCA RECALIBRAR
─────────────────────────────────────
❌ Mesmas referências para sempre
❌ Ignorar deriva de estimativas
❌ Não revisar reais vs estimados

✓ Revisar tarefas de referência trimestralmente
✓ Comparar estimados com reais
✓ Ajustar quando o time muda

ERRO 4: SUPER-PRECISÃO
─────────────────────────────────────
❌ "Isso é exatamente 4.5 pontos"
❌ Debater XS vs S por 20 minutos
❌ Paralisia por análise

✓ Aceitar incerteza de estimativa
✓ Arredondar para tamanho mais próximo
✓ Timeboxar discussões (2 min/item)

Melhores Práticas

1. Estimar como time - consenso constrói entendimento compartilhado
2. Usar tarefas de referência - comparar, não calcular
3. Rastrear velocidade - padrões emergem após 5+ sprints
4. Incluir tudo - testes, revisão, documentação
5. Dividir itens grandes - nada maior que XL/8 pontos
6. Timeboxar estimativa - 2 minutos por item máximo
7. Revisar regularmente - retro sobre precisão de estimativa
8. Confiar no processo - velocidade normaliza variância

Configuração no GitScrum

CONFIGURANDO EFFORT POINTS
══════════════════════════

ESTIMATIVA DE TAREFAS:
─────────────────────────────────────
Ao criar/editar uma tarefa:
1. Abrir detalhes da tarefa
2. Encontrar campo Effort
3. Selecionar tamanho: XS, S, M, L, XL
4. Pontos calculados automaticamente

VISTA DE PLANEJAMENTO DE SPRINT:
─────────────────────────────────────
O backlog do sprint mostra:
├── Total de pontos comprometidos
├── Limite de capacidade
├── Efforts de tarefas individuais
└── Rastreamento de progresso

RELATÓRIOS DE VELOCIDADE:
─────────────────────────────────────
Workspace → Reports → Sprint KPIs
├── Pontos por sprint
├── Taxas de conclusão
├── Progressão do burndown
└── Análise de tendências

Soluções Relacionadas

• Planejamento e Execução de Sprint
• Técnicas de Estimativa Ágil
• Guia de Rastreamento de Velocidade
• Dívida Técnica com Effort Points