Comment gérez-vous une demande de changement de périmètre au milieu d'un Sprint ?

Question

Accepted Answer

Par défaut dans Scrum, il faut **protéger l'Objectif du Sprint** : aucune modification ne devrait être ajoutée si elle le compromet. Mais Scrum n'est pas rigide — le périmètre peut être *renégocié avec le Product Owner*, et un changement véritablement urgent peut être traité, avec des compromis explicitement énoncés.

## Un cadre de décision

```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.
```

## Exemple concret

Au milieu du Sprint, les ventes veulent un nouveau rapport « simple ». Le Scrum Master aide l'équipe et le Product Owner à voir que ce n'est pas urgent, donc ça va au sommet du backlog du prochain Sprint au lieu de perturber l'objectif actuel.

## Pièges courants

- Absorber silencieusement du travail supplémentaire, compromettre l'Objectif du Sprint et le cacher.
- Dire un « non » catégorique sans possibilité — le Product Owner peut toujours renégocier.
- Laisser chaque partie prenante injecter directement du travail, en contournant le Product Owner.

## Pourquoi c'est important

Protéger l'Objectif du Sprint est ce qui rend Scrum prévisible ; l'injection constante transforme les Sprints en listes de tâches chaotiques.

Gérer le changement par le Product Owner avec des compromis explicites permet à l'équipe de rester concentrée tout en restant réactive aux véritables urgences.