Un sprint qui déraille suit presque toujours un des scénarios suivants. Les connaître permet de les couper tôt.

Le périmètre qui bouge en cours de sprint

Une nouvelle demande « urgente » s'ajoute au milieu du sprint. Chaque ajout repousse ce qui était prévu et met l'objectif en danger. La règle : rien n'entre en cours de sprint sans qu'une story de valeur équivalente en sorte, et c'est le PO qui décide, pas le demandeur.

Les interruptions et le multitâche

Les membres de l'équipe sont sollicités pour du support, des réunions non liées, d'autres projets. Chaque changement de contexte coûte du temps de re-concentration. On protège des plages de travail et on canalise les demandes via le Scrum Master.

Le sur-engagement

L'équipe a pris trop de stories, par optimisme ou sous pression. À mi-sprint, tout est « en cours », rien n'est fini. Mieux vaut prendre moins et finir.

Les stories pas prêtes

Une story entrée dans le sprint sans critères clairs bloque au troisième jour, le temps d'obtenir les précisions. Elle aurait dû rester au refinement.

Le report systématique

Si chaque sprint traîne des stories non finies vers le suivant, la vélocité devient illisible et l'équipe perd le sens de l'engagement. On cherche la cause (sur-engagement ? stories trop grosses ? interruptions ?) plutôt que de reporter encore.

L'annulation de sprint (rare)

Si l'objectif de sprint devient obsolète (le marché a changé, la priorité a basculé), le PO — et lui seul — peut annuler le sprint. On replanifie alors immédiatement.

Exemple concret : au sprint 6, un bug critique en production arrive au jour 3. Plutôt que de l'empiler sur le sprint, le PO sort une story de l'objectif pour faire de la place, et l'équipe traite le bug sans exploser son engagement.

À vous de jouer : citez deux choses qui font dérailler un sprint et la parade pour chacune.