9 min leitura • Guide 771 of 877
Planejamento de Capacidade da Equipe
Comprometimento excessivo leva ao esgotamento e prazos perdidos. O GitScrum ajuda equipes a planejar capacidade de forma realista e manter entregas sustentáveis.
Fundamentos de Capacidade
Calculando Capacidade
CÁLCULO DE CAPACIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FÓRMULA: │
│ │
│ Horas disponíveis │
│ - Reuniões │
│ - Folgas planejadas │
│ - Treinamento/onboarding │
│ × Fator de foco (60-80%) │
│ = Capacidade produtiva │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EXEMPLO (sprint de 2 semanas, 5 desenvolvedores): │
│ │
│ Pessoa Dias Reuniões Folga Disponível │
│ ──────── ──── ──────── ───── ────────── │
│ Alex 10 1.5 dias 0 8.5 dias │
│ Sam 10 1.5 dias 2 6.5 dias │
│ Jordan 10 1.5 dias 0 8.5 dias │
│ Taylor 10 2 dias 0 8 dias (líder) │
│ Casey 10 1.5 dias 1 7.5 dias │
│ ──────────────────────────────────────── │
│ TOTAL 39 dias │
│ │
│ Aplicar fator de foco (70%): │
│ 39 × 0.70 = 27.3 dias produtivos │
│ │
│ Em story points (se 1 ponto ≈ 1 dia): │
│ Capacidade do sprint: ~27 pontos │
│ │
│ Reservar 15% para não planejado: │
│ Trabalho planejado: ~23 pontos │
│ Buffer: ~4 pontos │
└─────────────────────────────────────────────────────────────┘
Fator de Foco
ENTENDENDO O FATOR DE FOCO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ONDE O TEMPO VAI (dia típico): │
│ │
│ 8 horas total │
│ ├── Reuniões: 1.5 horas │
│ ├── Email/Slack: 1 hora │
│ ├── Code review: 0.5 horas │
│ ├── Troca de contexto: 0.5 horas │
│ ├── Pausas: 0.5 horas │
│ └── Trabalho focado: 4 horas │
│ │
│ Fator de foco: 4/8 = 50% │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ FATORES DE FOCO TÍPICOS: │
│ │
│ 80%: Poucas reuniões, interrupções mínimas │
│ (raro, talvez durante sprints focados) │
│ │
│ 70%: Trabalho de desenvolvimento normal │
│ (padrão razoável) │
│ │
│ 60%: Maior carga de reuniões, deveres de suporte │
│ (típico para líderes) │
│ │
│ 50%: Suporte pesado, muitas reuniões │
│ (plantão, gestão) │
│ │
│ CALIBRE AO LONGO DO TEMPO: │
│ Acompanhe real vs estimado │
│ Ajuste fator baseado na realidade │
│ Diferentes papéis podem ter fatores diferentes │
└─────────────────────────────────────────────────────────────┘
Planejamento de Sprint
Planejamento Baseado em Capacidade
PLANEJAMENTO DE SPRINT COM CAPACIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANTES DO PLANEJAMENTO DO SPRINT: │
│ │
│ 1. CALCULAR DISPONIBILIDADE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Capacidade Sprint 12 ││
│ │ ││
│ │ Alex: 10 dias - férias Seg-Ter = 8 dias ││
│ │ Sam: 10 dias - 1 dia treinamento = 9 dias ││
│ │ Jordan: 10 dias - consulta médica Qua = 9.5 dias ││
│ │ ││
│ │ Capacidade bruta: 26.5 dias ││
│ │ Com fator de foco (70%): 18.5 dias ││
│ │ Com buffer (15%): ~16 dias disponíveis ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ 2. COMPARAR COM VELOCIDADE │
│ Média histórica: 18 pontos │
│ Capacidade deste sprint: Menor que normal │
│ → Planejar para ~14-15 pontos │
│ │
│ 3. SELECIONAR BACKLOG │
│ Escolher itens totalizando capacidade planejada │
│ Deixar espaço para trabalho não planejado │
│ Considerar dependências │
└─────────────────────────────────────────────────────────────┘
Tipos de Capacidade
| Tipo | Descrição | Exemplo |
|---|---|---|
| Capacidade Bruta | Total de dias de trabalho | 50 dias (5 pessoas × 10 dias) |
| Capacidade Líquida | Menos reuniões e folgas | 39 dias |
| Capacidade Efetiva | Com fator de foco aplicado | 27 dias |
| Capacidade Planejável | Com buffer para não planejado | 23 dias |
Gerenciando Variabilidade
Tratando Incerteza
ESTRATÉGIAS DE BUFFER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BUFFER PARA TRABALHO NÃO PLANEJADO: │
│ │
│ Fontes de trabalho não planejado: │
│ • Bugs em produção │
│ • Solicitações urgentes de stakeholders │
│ • Dúvidas de suporte │
│ • Interrupções de outros times │
│ • Clarificação de requisitos │
│ │
│ Alocação de buffer: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Baixa interrupção: 10% buffer ││
│ │ Normal: 15-20% buffer ││
│ │ Alta interrupção: 25-30% buffer ││
│ │ Time de suporte: 40-50% buffer ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BUFFER PARA INCERTEZA: │
│ │
│ Quando adicionar buffer extra: │
│ • Nova tecnologia │
│ • Requisitos pouco claros │
│ • Membros novos na equipe │
│ • Integrações complexas │
│ • Dependências externas │
└─────────────────────────────────────────────────────────────┘
Monitorando Capacidade Real
ACOMPANHAMENTO DE CAPACIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MÉTRICAS PARA ACOMPANHAR: │
│ │
│ Capacidade Planejada vs Real: │
│ Sprint 10: Planejado 25 pts, Entregue 22 pts (88%) │
│ Sprint 11: Planejado 25 pts, Entregue 26 pts (104%) │
│ Sprint 12: Planejado 20 pts, Entregue 19 pts (95%) │
│ │
│ Trabalho Não Planejado Real: │
│ Sprint 10: 18% do tempo (estimativa era 15%) │
│ Sprint 11: 12% do tempo │
│ Sprint 12: 22% do tempo (problema de produção) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ AJUSTES BASEADOS EM DADOS: │
│ │
│ Se consistentemente sub-entregando: │
│ • Aumentar estimativa de buffer │
│ • Reduzir fator de foco │
│ • Investigar causa raiz │
│ │
│ Se consistentemente sobre-entregando: │
│ • Pode estar sub-comprometendo │
│ • Considerar aceitar mais trabalho │
│ • Verificar se qualidade está sendo mantida │
└─────────────────────────────────────────────────────────────┘
Planejamento de Capacidade no GitScrum
Recursos de Suporte
| Recurso GitScrum | Uso no Planejamento de Capacidade |
|---|---|
| Disponibilidade de Membros | Marcar folgas e ausências |
| Dashboards de Sprint | Ver distribuição de carga |
| Rastreamento de Velocidade | Dados históricos para estimativas |
| Cargas de Trabalho | Visualizar balanceamento da equipe |
Workflow de Planejamento
PROCESSO DE PLANEJAMENTO NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. PREPARAÇÃO (antes do planejamento): │
│ • Atualizar disponibilidade de membros no GitScrum │
│ • Marcar folgas conhecidas │
│ • Revisar velocidade dos últimos 3 sprints │
│ │
│ 2. CÁLCULO: │
│ • Somar dias disponíveis │
│ • Aplicar fator de foco │
│ • Determinar capacidade planejável │
│ │
│ 3. SELEÇÃO: │
│ • Puxar itens do backlog │
│ • Verificar total de pontos vs capacidade │
│ • Ajustar conforme necessário │
│ │
│ 4. COMPROMISSO: │
│ • Equipe concorda com escopo │
│ • Documentar premissas │
│ • Registrar capacidade calculada │
│ │
│ 5. MONITORAMENTO: │
│ • Acompanhar burndown │
│ • Registrar trabalho não planejado │
│ • Ajustar capacidade futura baseado em dados │
└─────────────────────────────────────────────────────────────┘
Armadilhas Comuns
O Que Evitar
ERROS DE PLANEJAMENTO DE CAPACIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✗ SUPER-OTIMISMO: │
│ Assumir 100% de disponibilidade │
│ Ignorar reuniões e overhead │
│ "Dessa vez vai ser diferente" │
│ │
│ ✗ IGNORAR HISTÓRICO: │
│ Não usar dados de velocidade │
│ Não aprender com sprints anteriores │
│ Repetir erros de estimativa │
│ │
│ ✗ PRESSÃO EXTERNA: │
│ Aceitar escopo irreal por pressão │
│ "Apenas encaixem mais isso" │
│ Comprometer qualidade por prazo │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ✓ BOAS PRÁTICAS: │
│ │
│ • Use dados reais, não desejos │
│ • Seja conservador com estimativas │
│ • Comunique capacidade claramente │
│ • Proteja tempo da equipe │
│ • Aprenda e ajuste continuamente │
└─────────────────────────────────────────────────────────────┘
Comunicando Capacidade
Para Stakeholders
COMUNICAÇÃO DE CAPACIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MENSAGEM CLARA: │
│ │
│ "Nossa capacidade para o Sprint 15 é de ~20 pontos. │
│ │
│ Fatores que afetam: │
│ • Maria em férias por 5 dias (-3 pontos) │
│ • Treinamento de segurança obrigatório (-2 pontos) │
│ • Buffer normal para bugs de produção (15%) │
│ │
│ Podemos comprometer com as seguintes features: │
│ • Feature A (8 pontos) ✓ │
│ • Feature B (5 pontos) ✓ │
│ • Feature C (6 pontos) ✓ │
│ Total: 19 pontos │
│ │
│ Se Feature D (10 pontos) é prioridade, precisamos │
│ mover Feature B ou C para o próximo sprint." │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REGRA: Seja transparente sobre limitações │
│ e ofereça opções, não desculpas. │
└─────────────────────────────────────────────────────────────┘