Testar grátis
9 min leitura Guide 262 of 877

Rastreamento e Melhoria de Velocidade

Velocidade mede quanto trabalho uma equipe completa por sprint. É uma ferramenta de planejamento, não uma métrica de desempenho. Entender a velocidade ajuda equipes a se comprometer com trabalho alcançável e stakeholders a definir expectativas realistas. Melhorar velocidade significa remover fricção, não trabalhar mais.

Entendendo Velocidade

O Que É Velocidade

FUNDAMENTOS DE VELOCIDADE
═════════════════════════

DEFINIÇÃO:
─────────────────────────────────────
Velocidade = Story Points completados por sprint

Exemplo:
├── Sprint 1: 34 pontos
├── Sprint 2: 28 pontos
├── Sprint 3: 32 pontos
├── Sprint 4: 30 pontos
└── Velocidade média: 31 pontos

O QUE VELOCIDADE É:
─────────────────────────────────────
✓ Ferramenta de planejamento ("Podemos nos comprometer?")
✓ Indicador de capacidade ("Quanto podemos fazer?")
✓ Rastreador de tendência ("Estamos melhorando?")
✓ Medida específica da equipe
✓ Medida relativa

O QUE VELOCIDADE NÃO É:
─────────────────────────────────────
✗ Métrica de desempenho
✗ Medida de produtividade
✗ Comparável entre equipes
✗ Medida absoluta
✗ Alvo a maximizar
✗ Métrica individual

FAIXA DE VELOCIDADE:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────┐
│  Velocidade do Time Alpha                              │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  45 ┤                                                  │
│     │                        ◆ Alta: 38                │
│  35 ┤          ◆      ◆──────────── Média: 31         │
│     │      ◆       ◆      ◆                           │
│  25 ┤  ◆      ◆                     ◆ Baixa: 24       │
│     │                                                   │
│  15 ┤                                                  │
│     └──────────────────────────────────────────────────│
│       S1  S2  S3  S4  S5  S6  S7  S8  S9  S10         │
│                                                         │
│  Média: 31 pts  |  Faixa: 24-38  |  Variância: ±22%   │
└─────────────────────────────────────────────────────────┘

Use FAIXA para planejamento, não apenas média.
Espere variância—é normal.

Usando Velocidade

VELOCIDADE PARA PLANEJAMENTO
════════════════════════════

COMPROMISSO DE SPRINT:
─────────────────────────────────────
Passo 1: Conheça sua velocidade
├── Últimos 3 sprints: 32, 28, 34
├── Média: 31 pontos
├── Faixa: 28-34
└── Comprometer: 28-31 pontos (conservador)

Passo 2: Considere fatores
├── Semana de feriado? Reduza 20%
├── Membro do time ausente? Reduza proporcionalmente
├── Novos membros? Reduza para onboarding
└── Ajustado: 25 pontos

Passo 3: Puxe do backlog
├── Puxe items de maior prioridade
├── Até atingir capacidade
├── Deixe buffer para surpresas
└── Não exceda velocidade ajustada

PLANEJAMENTO DE LONGO PRAZO:
─────────────────────────────────────
Exemplo de planejamento de release:
├── Backlog restante: 180 pontos
├── Velocidade média: 30 pontos
├── Sprints necessários: 180 ÷ 30 = 6 sprints
├── Buffer (10%): +1 sprint
├── Estimativa: 7 sprints (14 semanas)
└── Comunique como faixa, não promessa

Apresente como:
"Baseado na velocidade atual, estimamos
6-8 sprints. Atualizaremos conforme aprendermos."

Rastreando Velocidade

Medição

RASTREAMENTO DE VELOCIDADE
══════════════════════════

O QUE CONTA:
─────────────────────────────────────
✓ Stories completamente DONE
✓ Critérios de aceitação atendidos
✓ Testado e aceito pelo PO
✓ Potencialmente deployável

O QUE NÃO CONTA:
─────────────────────────────────────
✗ Trabalho parcialmente feito
✗ Stories quase prontas
✗ Código commitado mas não testado
✗ Esperando review/aprovação

RASTREAMENTO NO GITSCRUM:
─────────────────────────────────────
Automático:
├── Stories movidas para Done
├── Soma de pontos no sprint
├── Histórico preservado
├── Gráfico de tendência
└── Relatório de velocidade

Manual (se necessário):
├── No final do sprint
├── Some pontos das stories Done
├── Registre no histórico
├── Compare com sprints anteriores
└── Atualize projeções

Padrões de Velocidade

PADRÕES E INTERPRETAÇÃO
═══════════════════════

VELOCIDADE ESTÁVEL (BOM):
─────────────────────────────────────
30 → 32 → 29 → 31 → 30
Variância: ±7%

Indica:
├── Equipe madura
├── Processo estável
├── Estimativas calibradas
├── Previsibilidade alta
└── Planejamento confiável

VELOCIDADE CRESCENTE:
─────────────────────────────────────
20 → 24 → 27 → 30 → 32
Tendência: +10% por sprint

Causas positivas:
├── Equipe amadurecendo
├── Processo melhorando
├── Ferramentas melhores
├── Menos dívida técnica
└── Colaboração melhor

Causas negativas (cuidado):
├── Inflação de estimativas
├── Corte de qualidade
├── Pressão por números
└── Gaming da métrica

VELOCIDADE DECRESCENTE:
─────────────────────────────────────
35 → 32 → 28 → 25 → 22
Tendência: -10% por sprint

Investigar:
├── Mais dívida técnica?
├── Problemas de equipe?
├── Escopo mudando?
├── Bloqueios frequentes?
├── Burnout?
└── Saída de membros?

VELOCIDADE ERRÁTICA:
─────────────────────────────────────
40 → 15 → 35 → 20 → 38
Variância: >50%

Indica problemas:
├── Estimativas inconsistentes
├── Escopo mudando mid-sprint
├── Dependências externas
├── Problemas de disponibilidade
└── Processo instável

Melhorando Velocidade

Identificando Oportunidades

ANÁLISE DE IMPEDIMENTOS
═══════════════════════

CATEGORIAS DE PERDA:
─────────────────────────────────────
1. ESPERA:
   ├── Aguardando review
   ├── Aguardando deploy
   ├── Aguardando resposta
   └── Bloqueado por dependência

2. REUNIÕES:
   ├── Muitas reuniões
   ├── Reuniões longas
   ├── Participantes incorretos
   └── Sem agenda clara

3. INTERRUPÇÕES:
   ├── Suporte urgente
   ├── Bugs de produção
   ├── Pedidos "rápidos"
   └── Multitasking forçado

4. RETRABALHO:
   ├── Bugs encontrados tarde
   ├── Requisitos mal entendidos
   ├── Code review extensivo
   └── Refatoração forçada

5. DÍVIDA TÉCNICA:
   ├── Código difícil de mudar
   ├── Testes faltando
   ├── Documentação ruim
   └── Tooling antiquado

QUANTIFICANDO:
─────────────────────────────────────
Para cada categoria:
├── Quantas horas/sprint perdidas?
├── Qual impacto em pontos?
├── É recorrente?
└── Pode ser eliminado?

Exemplo:
├── Espera em review: 8h/sprint = ~3pts
├── Reuniões: 10h/sprint = ~4pts
├── Interrupções: 6h/sprint = ~2pts
├── Retrabalho: 5h/sprint = ~2pts
└── TOTAL RECUPERÁVEL: ~11pts (35% da velocidade!)

Estratégias de Melhoria

AÇÕES PARA CADA CATEGORIA
═════════════════════════

REDUZIR ESPERA:
─────────────────────────────────────
├── PRs menores (review mais rápido)
├── SLA de review (4h máximo)
├── Deploy automatizado (CI/CD)
├── Comunicação assíncrona eficiente
├── Reduzir dependências externas
└── Pair programming (review built-in)

Impacto: +2-4 pontos/sprint

OTIMIZAR REUNIÕES:
─────────────────────────────────────
├── 25 min em vez de 30
├── 50 min em vez de 60
├── Agenda obrigatória
├── Participação mínima
├── Dias sem reuniões
├── Gravações para ausentes
└── Stand-up < 15 min

Impacto: +2-4 pontos/sprint

GERENCIAR INTERRUPÇÕES:
─────────────────────────────────────
├── Rotação de suporte
├── Horários de foco protegidos
├── Triagem antes de interromper
├── Buffer no sprint para urgências
├── Escalation path definido
└── "Office hours" para perguntas

Impacto: +1-3 pontos/sprint

REDUZIR RETRABALHO:
─────────────────────────────────────
├── Definition of Done clara
├── Critérios de aceitação detalhados
├── Testes automatizados
├── Refinamento adequado
├── Three Amigos sessions
└── Demo frequente ao PO

Impacto: +1-3 pontos/sprint

PAGAR DÍVIDA TÉCNICA:
─────────────────────────────────────
├── 10-20% do sprint para tech debt
├── Boy scout rule (deixe melhor)
├── Refactoring contínuo
├── Atualizar dependências
├── Melhorar cobertura de testes
└── Automatizar tarefas manuais

Impacto: +2-5 pontos/sprint (longo prazo)

Implementação no GitScrum

Configurando Rastreamento

SETUP NO GITSCRUM
═════════════════

PONTOS DE STORY:
─────────────────────────────────────
Configurações do projeto:
├── Habilitar story points
├── Definir escala (Fibonacci recomendado)
├── Campo obrigatório ou opcional
└── Visível no card

BURNDOWN/BURNUP:
─────────────────────────────────────
Dashboard do sprint:
├── Gráfico de burndown
├── Pontos restantes vs ideal
├── Burnup (escopo vs completo)
└── Atualização automática

RELATÓRIO DE VELOCIDADE:
─────────────────────────────────────
Histórico:
├── Velocidade por sprint
├── Média móvel (3-5 sprints)
├── Gráfico de tendência
├── Exportar dados
└── Comparação com compromisso

Usando Dados para Planejamento

PLANEJAMENTO BASEADO EM DADOS
═════════════════════════════

SPRINT PLANNING:
─────────────────────────────────────
GitScrum mostra:
├── Velocidade média: 31 pontos
├── Último sprint: 28 pontos
├── Capacidade disponível: 5 devs × 10 dias
├── Feriados/férias: -20%
└── Capacidade ajustada: 25 pontos

Workflow:
1. Ver velocidade histórica
2. Ajustar para disponibilidade
3. Puxar stories até capacidade
4. Deixar 10-15% buffer
5. Confirmar compromisso

RELEASE PLANNING:
─────────────────────────────────────
Backlog: 150 pontos
Velocidade: 30 ± 5 pontos

Cenários:
├── Otimista (35 pts): 5 sprints
├── Realista (30 pts): 5 sprints
├── Conservador (25 pts): 6 sprints
└── Comunicar: "5-6 sprints"

Refinando ao longo do tempo:
├── Sprint 1: reestimar backlog
├── Sprint 2: ajustar projeção
├── Sprint 3: confirmar data
└── Cada sprint: atualizar forecast

Boas Práticas

O Que Fazer e Não Fazer

BOAS PRÁTICAS DE VELOCIDADE
═══════════════════════════

FAÇA:
─────────────────────────────────────
✓ Use para planejamento, não avaliação
✓ Aceite variância como normal
✓ Mantenha histórico para tendências
✓ Considere fatores externos
✓ Use faixa, não número único
✓ Recalibre após mudanças de equipe
✓ Comunique incerteza a stakeholders

NÃO FAÇA:
─────────────────────────────────────
✗ Comparar equipes por velocidade
✗ Usar como meta a maximizar
✗ Avaliar indivíduos por pontos
✗ Pressionar para aumentar
✗ Punir sprints de baixa velocidade
✗ Ignorar qualidade por velocidade
✗ Inflacionar estimativas artificialmente

SINAIS DE ALERTA:
─────────────────────────────────────
⚠ "Precisamos aumentar velocidade 20%"
⚠ "Time X tem velocidade maior que Y"
⚠ "Você só fez 5 pontos esse sprint"
⚠ Velocidade subindo sem mudanças reais
⚠ Qualidade caindo enquanto velocidade sobe
⚠ Equipe sob pressão constante

Velocidade Sustentável

RITMO SUSTENTÁVEL
═════════════════

CONCEITO:
─────────────────────────────────────
Velocidade que a equipe pode manter
indefinidamente sem burnout.

Sinais de velocidade insustentável:
├── Horas extras frequentes
├── Trabalho no fim de semana
├── Burnout de membros
├── Rotatividade alta
├── Qualidade declinando
└── Moral baixo

CALIBRANDO:
─────────────────────────────────────
Perguntas ao time:
├── "Conseguimos manter esse ritmo?"
├── "Estamos sacrificando qualidade?"
├── "Estamos descansando adequadamente?"
├── "Temos tempo para aprender?"
└── "Estamos nos divertindo?"

Se respostas negativas:
├── Reduzir compromisso
├── Endereçar impedimentos
├── Proteger tempo pessoal
├── Investir em melhorias
└── Velocidade menor mas sustentável

LONGO PRAZO:
─────────────────────────────────────
Velocidade sustentável = Mais valor
├── Menos turnover
├── Menos bugs
├── Melhor moral
├── Melhor colaboração
├── Inovação possível
└── Carreira sustentável

Artigos Relacionados