What is O Problema de Interrupções?

Urgências não gerenciadas destroem produtividade: - Falha do sprint — Não consegue completar trabalho planejado - Troca de contexto — Desenvolvedores perdem fluxo constantemente - Colapso de estimativas — Planos perdem sentido - Burnout do time — Combate constante a incêndios esgota - Falsas urgências — Tudo se torna "urgente"

What is Recursos Principais?

Gerencie solicitações urgentes e trabalho não planejado no GitScrum sem interromper compromissos de sprint usando capacidade de buffer, lanes de interrupção e políticas claras de escalação.

What is Planejamento de Capacidade de Buffer?

Gerencie solicitações urgentes e trabalho não planejado no GitScrum sem interromper compromissos de sprint usando capacidade de buffer, lanes de interrupção e políticas claras de escalação.

Lidando com Solicitações Urgentes Sem Descarrilar Sprints

Cada sprint enfrenta solicitações urgentes inesperadas que ameaçam o trabalho planejado. GitScrum fornece mecanismos de tratamento de interrupções incluindo planejamento de capacidade de buffer, lanes dedicadas de interrupção e fluxos de escalação.

O Problema de Interrupções

Urgências não gerenciadas destroem produtividade:

Falha do sprint — Não consegue completar trabalho planejado
Troca de contexto — Desenvolvedores perdem fluxo constantemente
Colapso de estimativas — Planos perdem sentido
Burnout do time — Combate constante a incêndios esgota
Falsas urgências — Tudo se torna "urgente"
Sem previsibilidade — Stakeholders perdem confiança na entrega

Solução de Tratamento de Interrupções GitScrum

Construa sistemas que absorvam trabalho inesperado:

Recursos Principais

Recurso	Uso para Interrupções
Capacidade de buffer	Reservar capacidade de sprint para incógnitas
Lanes de interrupção	Colunas dedicadas do board para trabalho urgente
Limites WIP	Prevenir sobrecarga durante interrupções
Labels/prioridades	Classificação clara de urgência
Automações	Rotear trabalho urgente apropriadamente

Planejamento de Capacidade de Buffer

Estrutura de Capacidade do Sprint

Planejamento de Capacidade do Sprint:

Capacidade Total Disponível: 100 story points

Alocação:
├── Trabalho Comprometido do Sprint: 75 pts (75%)
│   └── Features e melhorias planejadas
├── Buffer para Interrupções: 15 pts (15%)
│   └── Solicitações urgentes esperadas, bugs, suporte
└── Slack/Aprendizado: 10 pts (10%)
    └── Dívida técnica, exploração, treinamento

Orientação de Planejamento do Sprint:
"Não comprometer mais de 75 pontos. 
Reservar 15 pontos para interrupções esperadas.
Se interrupções excederem o buffer, remover 
itens comprometidos de menor prioridade."

Dimensionamento do Buffer por Histórico do Time

Análise de Interrupções: Últimos 6 Sprints

Sprint    │ Interrupções │ Pontos │ % da Capacidade
──────────┼──────────────┼────────┼────────────────
Sprint 18 │ 4 itens      │ 12 pts │ 12%
Sprint 17 │ 7 itens      │ 18 pts │ 18%  ← Incidente maior
Sprint 16 │ 3 itens      │ 8 pts  │ 8%
Sprint 15 │ 5 itens      │ 14 pts │ 14%
Sprint 14 │ 4 itens      │ 11 pts │ 11%
Sprint 13 │ 3 itens      │ 9 pts  │ 9%

Média: 12 pts por sprint (12%)
Buffer recomendado: 15 pts (fornece margem)

Ajustar se:
├── Sprint com muitas interrupções → Aumentar buffer
├── Sprint com poucas interrupções → Manter buffer, usar para dívida
└── Padrão consistente → Considerar alocação permanente

Lane de Interrupção no Board

Configuração do Board

Kanban Board com Lane de Interrupção:

┌─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐
│ Backlog     │ INTERRUPÇÃO │ Em Progresso│ Review      │ Done        │
│             │ 🔴          │             │             │             │
├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤
│ Trabalho    │ URGENTE: Fix│ Feature A   │ Feature B   │ Feature C   │
│ sprint      │ bug de pago │ (planejada) │ (planejada) │ (planejada) │
│ planejado   │             │             │             │             │
│ Feature D   │             │ INTERRUPÇÃO:│             │ INTERRUPÇÃO:│
│ Feature E   │             │ Patch de    │             │ Hotfix      │
│             │             │ segurança   │             │ deployed    │
└─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘

Limite WIP: 2 (coluna Interrupção)
Regra: Trabalho de interrupção recebe desenvolvedor dedicado
Visualização: Cor/label diferente

Classificação de Interrupções

Sistema de Classificação de Urgência:

🔴 P0 - Crítico (< 1 hora de resposta)
├── Produção fora do ar
├── Brecha de segurança ativa
├── Perda de dados ocorrendo
├── Sistema de pagamentos quebrado
└── Ação: Todos, largar tudo

🟠 P1 - Alto (< 4 horas de resposta)
├── Feature maior quebrada para muitos usuários
├── Impacto significativo em receita
├── Escalação importante de cliente
└── Ação: Manipulador de interrupções designado

🟡 P2 - Médio (dentro do sprint)
├── Feature quebrada para alguns usuários
├── Workaround existe
├── Solicitação de cliente com deadline
└── Ação: Adicionar ao sprint se buffer permitir

🟢 P3 - Baixo (próximo sprint)
├── Issues menores
├── Solicitações nice-to-have
├── Melhorias gerais
└── Ação: Backlog para priorização

Papel do Manipulador de Interrupções

Rotação de Dever de Interrupções

Rotação Semanal de Interrupções:

Semana 1: @alice (principal), @bob (backup)
Semana 2: @bob (principal), @carol (backup)  
Semana 3: @carol (principal), @dave (backup)
Semana 4: @dave (principal), @alice (backup)

Responsabilidades do Manipulador de Interrupções:
├── Monitorar canal #support-engineering
├── Triagem de solicitações urgentes entrantes
├── Tratar P0/P1 imediatamente
├── Proteger resto do time de interrupções
├── Documentar padrões de interrupção
└── Capacidade de sprint: 50% (trabalho planejado)

Benefícios:
├── Uma pessoa troca de contexto (não o time todo)
├── Rotação justa da carga de interrupções
├── Tempo protegido para trabalho focado
└── Propriedade clara de issues urgentes

Alocação de Sprint do Manipulador

Semana do Manipulador de Interrupções:

@alice Alocação Sprint 19:
├── Trabalho comprometido do sprint: 0 pts
│   └── Não atribuído a trabalho planejado
├── Capacidade de interrupção: 50% (~20 hrs)
│   └── Tratar todas as solicitações urgentes
├── Suporte/documentação: 30% (~12 hrs)
│   └── Escrever runbooks, melhorar docs
└── Flexível: 20% (~8 hrs)
    └── Dívida técnica, aprendizado, ajudar time

Se não ocorrerem interrupções:
├── Trabalhar no backlog de dívida técnica
├── Melhorar monitoramento/alertas
├── Escrever documentação
└── Pair programming com o time em trabalho complexo

Políticas de Escalação

Caminho de Escalação Claro

Matriz de Escalação:

Issue chega via:
├── Slack #support → Triagem pelo time de suporte
├── PagerDuty → Vai para engenheiro de plantão
├── Email de cliente → Account manager avalia
└── Solicitação interna → Solicitante cria ticket

Fluxo de Escalação:
1. Suporte cria ticket com avaliação de urgência
2. Manipulador de interrupções revisa dentro do SLA:
   ├── P0: Imediatamente (< 15 min)
   ├── P1: < 1 hora
   ├── P2: < 4 horas
   └── P3: Próximo dia útil
3. Manipulador confirma ou ajusta prioridade
4. Manipulador atribui ou adiciona ao sprint
5. Resolução rastreada no ticket

Regras de Auto-Escalação:
├── P0 não reconhecido > 15 min → Acionar backup
├── P1 não reconhecido > 1 hr → Acionar backup + gerente
└── Qualquer issue aberto > SLA → Notificar gerente

Comunicação com Stakeholders

Template de Solicitação de Interrupção:

Ao solicitar trabalho urgente:

Assunto: [URGENTE P1] Pagamentos falhando para contas enterprise

O que está acontecendo:
Clientes enterprise vendo erros de pagamento desde 2pm

Impacto:
- ~50 clientes afetados
- $20K receita potencial em risco
- 3 reclamações de clientes recebidas

Workaround:
Processamento manual de pagamento disponível (lento)

Ação solicitada:
Corrigir integração de pagamento dentro de 4 horas

Solicitado por: @sarah (Account Manager)
Gerente aprovador: @mike (VP Vendas)

---

Resposta da Engenharia:

Reconhecido: 2:15pm por @alice
Status atual: Investigando
ETA: Diagnóstico em 30 min, correção em 2 hrs
Atualizações: A cada 30 minutos em #incident-payment

Gerenciando Impacto no Sprint

Quando o Buffer é Excedido

Protocolo Buffer Excedido:

Situação: 20 pts de interrupções, 15 pts de buffer

Opções:
1. Estender trabalho do sprint → Risco de burnout, problemas de qualidade
2. Remover itens de menor prioridade → Manter sustentabilidade
3. Solicitar ajuda adicional → Se disponível
4. Negociar escopo → Reduzir escopo de interrupção se possível

Framework de Decisão:
├── Podemos reduzir o escopo da interrupção? → Tentar primeiro
├── É sustentável a hora extra (raro)? → Apenas curto prazo
├── O que podemos remover? → Discutir com PO
└── Precisamos de ajuda? → Escalar para gestão

Comunicação para Stakeholders:
"Recebemos 33% mais solicitações urgentes do que planejado.
Para manter a qualidade, estamos adiando Feature E para 
o próximo sprint. Todos os itens urgentes serão resolvidos."

Ajustes do Sprint

Reunião de Ajuste Mid-Sprint:

Quando: Buffer excedido por 50%+
Quem: Scrum Master, Product Owner, Team Lead

Agenda:
1. Revisar volume e impacto de interrupções
2. Avaliar capacidade restante do sprint
3. Decidir o que adiar
4. Comunicar a stakeholders
5. Documentar para retrospectiva

Exemplo de Decisão:
Correção Mid-Sprint Sprint 19:
├── Compromisso original: 75 pts
├── Interrupções recebidas: 22 pts (sobre 15 pts de buffer)
├── Capacidade ajustada: 75 - 7 = 68 pts
├── Adiado: Feature E (8 pts) → Sprint 20
└── Novo compromisso: 67 pts (alcançável)

Notificação para stakeholders enviada ✓

Prevenindo Falsas Urgências

Validação de Urgência

Antes de Aceitar P0/P1:

Checklist de Validação:
□ A produção está realmente impactada?
□ Quantos usuários afetados?
□ Qual é o impacto de negócio ($$)?
□ Existe workaround?
□ Pode esperar até amanhã?
□ Quem aprovou a prioridade?

Red Flags (provavelmente não é urgente):
├── "O cliente está irritado" (sem impacto em produção)
├── "Prometemos esta feature" (não urgente, planejamento ruim)
├── "Está quebrado há semanas" (não subitamente urgente)
├── "Preciso para um demo" (urgência pessoal, não de negócio)
└── Sem aprovação de gerente na prioridade

Resposta:
"Entendo que isso é importante. Baseado em nossos 
critérios, isso é P2 (Médio). Será tratado dentro 
deste sprint. Se você acredita que é realmente P0/P1, 
por favor obtenha aprovação do VP."

Rastreando Padrões de Urgência

Relatório Mensal de Interrupções:

Total Interrupções: 24
Por Prioridade:
├── P0 Crítico: 2 (8%)
├── P1 Alto: 6 (25%)
├── P2 Médio: 10 (42%)
└── P3 Baixo: 6 (25%) ← Não deveriam ser interrupções

Por Fonte:
├── Relatórios de clientes: 10 (42%)
├── Solicitações internas: 8 (33%)
├── Alertas de monitoramento: 4 (17%)
└── Escalações de vendas: 2 (8%)

Por Categoria:
├── Bugs: 12 (50%)
├── Solicitações de features: 6 (25%)
├── Perguntas de suporte: 4 (17%)
└── Segurança: 2 (8%)

Insights:
├── 25% das solicitações "urgentes" não eram urgentes
├── 50% são bugs → Precisa melhor QA
├── O mesmo sistema causou 4 incidentes → Precisa refactor

Ações:
├── Ajustar critérios de aceitação de P3
├── Investir em estabilidade do sistema de pagamentos
└── Adicionar monitoramento para top categorias de incidentes

Integração com Standup do Time

Status de Interrupções no Standup

Standup Diário com Interrupções:

@alice (Manipuladora de Interrupções):
"Tratando: 2 interrupções ativas
- P1 Bug de pagamento: 60% feito, ETA 2pm
- P2 Issue de export: Na fila, começando após P1
Buffer usado: 8/15 pontos
Status do buffer: Saudável ✓"

@bob:
"Feature A: No caminho, sem bloqueios
Não pegando interrupções esta semana"

@carol:
"Feature B: Em review
Heads up: Pode precisar de ajuda se chegarem mais P1s"

Scrum Master nota:
├── Buffer saudável, sprint no caminho
├── Acompanhar progresso do bug de pagamento
└── Carol marcada como backup se necessário

Retrospectiva de Interrupções

Retrospectiva do Sprint: Análise de Interrupções

O Que Aconteceu:
├── 4 interrupções P1 (acima da média)
├── 1 incidente P0 (outage de produção)
├── Buffer excedido por 5 pontos
├── 1 feature adiada para próximo sprint

O Que Deu Certo:
├── Papel do manipulador de interrupções protegeu o time
├── P0 resolvido em 45 minutos
├── Escalação clara funcionou
└── Stakeholders entenderam o adiamento

O Que Melhorar:
├── 2 P1s eram na verdade P2 (super-escalados)
├── Sem runbook para issues de pagamento → Criar um
├── Monitoramento não detectou issue cedo → Melhorar
└── Buffer era muito pequeno → Aumentar para 18 pts

Itens de Ação:
├── [ ] Criar runbook do sistema de pagamentos
├── [ ] Adicionar monitoramento para gateway de pagamento
├── [ ] Revisar critérios de urgência com vendas
└── [ ] Aumentar buffer para 18 pts próximo sprint

Melhores Práticas

Para Times

Proteger o buffer — Não super-comprometer trabalho planejado
Rotacionar justamente — Compartilhar carga de interrupções
Documentar interrupções — Padrões informam melhorias
Dizer não apropriadamente — Nem tudo é urgente
Melhorar sistemas — Reduzir interrupções futuras