Como você lida com uma solicitação para alterar o escopo no meio de um Sprint?

Question

Accepted Answer

O padrão no Scrum é **proteger a Meta do Sprint**: nenhuma mudança deve ser adicionada que a coloque em risco. Mas o Scrum não é rígido — o escopo pode ser *renegociado com o Product Owner*, e uma mudança verdadeiramente urgente pode ser tratada, com trade-offs explícitos.

## Um framework de decisão

```text
1. Does the new request threaten the Sprint Goal?
     NO  → can it wait for the next Sprint? Usually yes → backlog it.
     YES → talk to the Product Owner about trade-offs.
2. Is it a genuine emergency (prod down, legal, security)?
     YES → the PO may cancel/replace work; something must drop.
3. Make the trade-off visible: pulling X in means Y comes out.
```

## Exemplo concreto

No meio do Sprint, o departamento de vendas quer um "pequeno" novo relatório. O Scrum Master ajuda o time e o Product Owner a ver que não é urgente, então vai para o topo do backlog do próximo Sprint em vez de prejudicar a meta atual.

## Armadilhas comuns

- Absorver silenciosamente trabalho extra, explodindo a Meta do Sprint e escondendo.
- Dizer um "não" categórico sem caminho — o Product Owner sempre pode renegociar.
- Deixar cada stakeholder injetar trabalho diretamente, contornando o Product Owner.

## Por que isso importa

Proteger a Meta do Sprint é o que torna o Scrum previsível; injeção constante transforma Sprints em listas de afazeres caóticas.

Lidar com mudanças através do Product Owner com trade-offs explícitos mantém o time focado enquanto permanece responsivo a emergências reais.