Le piège du Sprint 0 dans Scrum

  • #Frameworks & développements

Publié le Mis à jour le Par

Le Sprint 0 est une étrange notion qui persiste dans de nombreuses équipes Scrum lors de la mise en place de l’agilité autour d’un produit. Il s’agit en fait d’une erreur fondamentale au regard de la structure même de Scrum.

Organiser l’inconnu est une perte de temps

Le Sprint 0 consiste en général à préparer de manière traditionnelle le lancement de l’agilité en tentant de figer un certain nombre de principes basés sur une réflexion totalement théorique sur ce que l’équipe devrait, en toute logique, découvrir de manière empirique, conformément aux trois piliers de l’agilité, transparence, adaptation, inspection..

Malheureusement, cette approche est en décalage avec les fondements mêmes de Scrum.

Tout d’abord, selon Scrum, l’objectif d’un Sprint est de “Livrer un produit fonctionnel” or le Sprint 0 entre en conflit avec ce principe car aucune livraison fonctionnelle n’est effectuée.

Ensuite, le fondement de Scrum nous entraîne dans une démarche empirique. Il s’agit de permettre à une équipe de découvrir et s’approprier les défis réels auxquels elle va être confrontée, lui permettant ainsi d’expérimenter les meilleures solutions qui s’offrent à elle en respectant toujours l’objectif du Sprint. Cela prive donc l’équipe de trouver le courage et l’engagement nécessaires pour surmonter les difficultés du premier Sprint.

Le Sprint 0 agit finalement comme une action déresponsabilisante de l’équipe qui devrait appliquer des décisions théoriques présentées comme factuelles. C’est à coup sûr un échec dont l’équipe ne saurait tirer aucune leçon. C’est une perte nette de temps et d’effort qui entrave la confiance de l’équipe là où le premier Sprint devrait permettre de la construire. 

Comment démarrer le premier Sprint avec succès

La clé du succès d’un premier Sprint réside dans la gestion des attentes et non dans l’application des conclusions d’un Sprint 0. Le premier Sprint peut être difficile, mais plutôt que d’ajouter une étape préliminaire, l’équipe doit être encouragée à viser un objectif de Sprint réaliste.

Le Product Backlog et le Sprint Backlog n’ont pas besoin d’être complets avant de lancer le premier Sprint. L’équipe peut commencer avec un objectif de Sprint basé sur quelques éléments du Sprint Backlog. Elle doit être capable d’accepter l’incertitude et de construire au fur et à mesure son fonctionnement en adaptant ses propres méthodes et en choisissant les outils adaptés à ce qu’elle découvre.

Pour que l’équipe puisse avoir une chance de réussir, il est essentiel qu’elle se plonge dans l’expérience réelle dès le départ. Parce que Scrum est facile à apprendre mais difficile à maîtriser, le premier Sprint demandera certainement beaucoup d’efforts, mais il sera riche d’enseignement sur les véritables défis de Scrum, apportant à l’équipe la connaissance lui permettant de s’améliorer. 

Voir d’autres contenus sur l’agilité :


Rédacteur : 
Jean-Marc Larroque – Coach agile, Scrum Master, formateur et Consultant en technologies Web e-Commerce chez Clever Age
Découvrez le blog de Jean-Marc pour découvrir plus de contenus autour de l’Agilité.

*Image générée par Midjourney spécialement pour cet article.


  • Agile

  • Framework

  • Scrum

  • sprint