8 min leitura • Guide 79 of 877
Lidando com Mudanças de Escopo Durante Sprint
Mudanças de escopo durante um sprint são realidade, não fracasso. Mercados mudam, prioridades evoluem, e nova informação emerge. A questão não é se o escopo vai mudar, mas como lidar com mudanças sem destruir o foco do time ou compromissos do sprint. GitScrum fornece a estrutura para avaliar, comunicar, e integrar mudanças de escopo enquanto protege a integridade do sprint.
Entendendo Impacto da Mudança de Escopo
Tipos de Mudanças Durante Sprint
CATEGORIAS DE MUDANÇA DE ESCOPO:
┌─────────────────────────────────────────────────────────────┐
│ TIPOS E RESPOSTAS TÍPICAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ EMERGÊNCIA (Deve ser tratada imediatamente) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Exemplos: ││
│ │ • Queda produção afetando usuários ││
│ │ • Vulnerabilidade segurança descoberta ││
│ │ • Prazo cumprimento regulatório ││
│ │ • Mudança requisito legal ││
│ │ ││
│ │ Resposta: Puxar para sprint imediatamente ││
│ │ Algo deve sair ││
│ │ Documentar por que para retrospectiva ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ALTA PRIORIDADE (Importante mas não emergência) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Exemplos: ││
│ │ • Issue bloqueante de cliente chave ││
│ │ • Nova oportunidade negócio com prazo ││
│ │ • Dependência descoberta afetando roadmap ││
│ │ ││
│ │ Resposta: Avaliar tamanho e capacidade sprint ││
│ │ Pode esperar 3-5 dias para próximo sprint? ││
│ │ Se não, negociar troca escopo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MELHORIA (Bom ter) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Exemplos: ││
│ │ • Ideia melhoria de stakeholder ││
│ │ • Sugestão melhoria UX ││
│ │ • Oportunidade pagar dívida técnica ││
│ │ ││
│ │ Resposta: Adicionar ao backlog, priorizar normalmente ││
│ │ Não interromper sprint ││
│ │ Discutir na próxima planning ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SCOPE CREEP (Expansão feature) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Exemplos: ││
│ │ • "Já que você está aí, poderia também..." ││
│ │ • Gold-plating de requisitos ││
│ │ • Complexidade não descoberta emergindo ││
│ │ ││
│ │ Resposta: Separar escopo original de expansão ││
│ │ Completar escopo comprometido primeiro ││
│ │ Expansão vai para backlog ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Avaliação de Impacto
AVALIANDO IMPACTO DA MUDANÇA:
┌─────────────────────────────────────────────────────────────┐
│ MATRIZ IMPACTO MUDANÇA │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TAMANHO DA MUDANÇA ││
│ │ Pequeno Médio Grande ││
│ │ ┌──────────┬──────────┬──────────┐ ││
│ │ Início │ 🟢 │ 🟢 │ 🟡 │ ││
│ │ (Dia │ Pode │ Troca + │ Negociar │ ││
│ │ 1-2) │ trocar │ ajustar │ escopo │ ││
│ │ S ├──────────┼──────────┼──────────┤ ││
│ │ P Meio │ 🟢 │ 🟡 │ 🔴 │ ││
│ │ R (Dia │ Pode │ Risco │ Próximo │ ││
│ │ I 3-6) │ cuidado │ burndown │ sprint │ ││
│ │ N ├──────────┼──────────┼──────────┤ ││
│ │ T Final │ 🟡 │ 🔴 │ 🔴 │ ││
│ │ (Dia │ Só se │ Próximo │ Próximo │ ││
│ │ 7-10) │ urgente │ sprint │ sprint │ ││
│ │ └──────────┴──────────┴──────────┘ ││
│ │ ││
│ │ 🟢 Baixo risco - geralmente pode acomodar ││
│ │ 🟡 Risco médio - requer negociação cuidadosa ││
│ │ 🔴 Alto risco - proteger sprint, adiar para próximo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Gestão de Escopo GitScrum
Documentando Solicitações de Mudança
USANDO DISCUSSIONS PARA SOLICITAÇÕES DE MUDANÇA:
Antes de interromper sprint:
┌─────────────────────────────────────────────────────────────┐
│ DISCUSSION: Solicitação Mudança Escopo │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📋 Solicitação: Adicionar lógica retry pagamento │
│ │
│ ## Detalhes Solicitação │
│ **Solicitado por:** @stakeholder │
│ **Sprint:** 12 (Dia 4 de 10) │
│ **Urgência alegada:** Alta │
│ │
│ ## Análise Impacto │
│ **Esforço estimado:** 5 story points │
│ **Capacidade sprint restante:** 22 pts │
│ **Impacto objetivo sprint:** Atrasaria objetivo │
│ │
│ ## Opções │
│ 1. ✅ Adicionar ao próximo sprint (menor risco) │
│ 2. ⚠️ Trocar por PROJ-78 docs API (pontos iguais) │
│ 3. 🔴 Adicionar sem remover (risco burndown) │
│ │
│ ## Decisão │
│ [A discutir no sync do time] │
│ │
└─────────────────────────────────────────────────────────────┘
Acompanhamento Escopo Sprint
RASTREANDO ESCOPO ORIGINAL vs ATUAL:
┌─────────────────────────────────────────────────────────────┐
│ VISIBILIDADE ESCOPO SPRINT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Usar labels para rastrear mudanças escopo: │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ESTRATÉGIA LABELS ││
│ │ ││
│ │ scope:original Tarefas comprometidas na planning ││
│ │ scope:added Adicionado após início sprint ││
│ │ scope:removed Removido do sprint (razão) ││
│ │ scope:emergency Adicionado por resposta emergência ││
│ │ scope:expanded Tarefa original cresceu em escopo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Vista filtrada quadro: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SPRINT 12 - Status Escopo ││
│ │ ││
│ │ Comprometido: 42 pts (10 items) ││
│ │ ├── scope:original 37 pts (8 items) ││
│ │ ├── scope:added 5 pts (2 items) ││
│ │ └── scope:removed -5 pts (1 item → backlog) ││
│ │ ││
│ │ Mudança líquida: 0 pts (troca balanceada) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Protegendo Foco do Time
Estratégia Buffer
PLANEJANDO PARA MUDANÇA:
┌─────────────────────────────────────────────────────────────┐
│ CONSTRUINDO FLEXIBILIDADE NOS SPRINTS │
├─────────────────────────────────────────────────────────────┤
│ │
│ BUFFER CAPACIDADE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Se velocidade time é 40 pts, não comprometer 40 pts ││
│ │ ││
│ │ Capacidade time: 40 pts (velocidade histórica) ││
│ │ Trabalho objetivo: 32 pts (80%) ││
│ │ Buffer: 8 pts (20%) ││
│ │ ││
│ │ Usos buffer: ││
│ │ • Mudanças escopo inesperadas ││
│ │ • Tarefas levando mais que estimado ││
│ │ • Bug fixes e issues suporte ││
│ │ • Se não usado, puxar próximos items backlog ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OBJETIVOS STRETCH: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Identificar items baixo risco para puxar se há cap: ││
│ │ ││
│ │ Compromisso core: 32 pts ││
│ │ Stretch goal 1: 5 pts (documentação) ││
│ │ Stretch goal 2: 3 pts (dívida técnica) ││
│ │ ││
│ │ Stretch goals são primeiros a serem sacrificados se ││
│ │ mudanças escopo chegam no meio do sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Padrões Comunicação
Updates Stakeholders
COMUNICANDO MUDANÇAS ESCOPO:
┌─────────────────────────────────────────────────────────────┐
│ TRANSPARÊNCIA SOBRE MUDANÇAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ Ao aceitar mudança no sprint: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Adicionamos lógica retry pagamento ao Sprint 12. ││
│ │ Para acomodar isso, documentação API move para ││
│ │ Sprint 13. Objetivo sprint permanece alcançável." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Ao declinar mudança (adiar para próximo sprint): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Lógica retry pagamento está priorizada como top item ││
│ │ para Sprint 13, iniciando 20 de janeiro. ││
│ │ ││
│ │ Adicionar ao Sprint 12 arriscaria nosso compromisso ││
│ │ com marco beta launch de 15 de fevereiro." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Medindo Estabilidade Escopo
Métricas Mudança Escopo
RASTREANDO PADRÕES MUDANÇA:
┌─────────────────────────────────────────────────────────────┐
│ MÉTRICAS PARA RETROSPECTIVAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ MÉTRICA │ ALVO │ ATUAL │ STATUS ││
│ │────────────────────────┼───────────┼────────┼──────────││
│ │ Estabilidade escopo │ 85%+ │ 88% │ 🟢 ││
│ │ (pts completados / pts │ │ │ ││
│ │ originalmente compr) │ │ │ ││
│ │ │ │ │ ││
│ │ Frequência mudanças │ <3/sprint │ 2 │ 🟢 ││
│ │ (mudanças escopo/sprt) │ │ │ ││
│ │ │ │ │ ││
│ │ Adições emergência │ <1/sprint │ 1 │ 🟡 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Perguntas retrospectiva: │
│ • Mudanças escopo foram realmente urgentes? │
│ • O que causou as mudanças? (Análise padrão) │
│ • Tínhamos buffer adequado para mudanças? │
│ • Como mudanças afetaram moral e foco do time? │
│ │
└─────────────────────────────────────────────────────────────┘