Le Sprint et la Sprint Planning
Le Sprint, battement de cœur de Scrum où les idées deviennent de la valeur, et la Sprint Planning qui l'initie autour de trois questions : pourquoi, quoi, comment.
Après la théorie empirique et la Scrum Team, le Scrum Guide en vient à la mécanique qui fait vivre le tout : les événements (Scrum Events). Et il commence par une affirmation qui surprend souvent les débutants : le premier événement de Scrum n'est pas une réunion. C'est le Sprint lui-même, décrit comme le conteneur de tous les autres événements. La Sprint Planning, le Daily Scrum, la Sprint Review et la Sprint Retrospective ne flottent pas dans le calendrier : ils vivent tous à l'intérieur du Sprint, qui leur donne leur cadence. Ce chapitre couvre cette architecture d'ensemble, le Sprint lui-même, puis la Sprint Planning qui l'initie autour de trois questions — pourquoi, quoi, comment.
Des événements conçus pour la transparence
Le guide définit chaque événement de Scrum comme une opportunité formelle d'inspecter et d'adapter les artefacts Scrum. Le mot « formelle » n'est pas décoratif : l'inspection et l'adaptation ne sont pas laissées au hasard des bonnes volontés, mais inscrites dans la structure même du cadre. On retrouve ici, incarnés dans l'agenda, les piliers empiriques du chapitre sur la théorie : les événements sont spécifiquement conçus pour permettre la transparence requise — sans laquelle l'inspection est trompeuse et source de gaspillage.
La conséquence est énoncée sans détour : ne pas tenir un événement comme prescrit, c'est perdre des opportunités d'inspecter et d'adapter. L'équipe qui saute sa Retrospective « parce qu'on n'a pas le temps ce Sprint-ci » ne gagne pas du temps : elle renonce précisément aux moments où le cadre lui permettait d'apprendre et de corriger sa trajectoire.
Les événements servent aussi un objectif très concret d'hygiène organisationnelle : ils créent de la régularité et minimisent le besoin de réunions non définies dans Scrum. Une équipe qui utilise bien ses cinq événements devrait voir fondre les points de synchronisation improvisés et les réunions de crise. Enfin, de façon optimale, tous les événements se tiennent à la même heure et au même endroit, afin de réduire la complexité.
Astuce
Même heure, même lieu : ce conseil d'apparence anodine est un puissant réducteur de friction. Quand la Planning a lieu chaque premier lundi à 9 h au même endroit, personne ne dépense d'énergie à négocier des créneaux, et l'événement devient un réflexe collectif. On notera au passage que le guide parle d'événements, jamais de « cérémonies » — un vocabulaire répandu sur le terrain mais absent du texte officiel.
Le Sprint : le battement de cœur de Scrum
La formule du guide est devenue célèbre : « les Sprints sont le battement de cœur de Scrum, où les idées sont transformées en valeur ». Deux propriétés structurelles en découlent. D'abord, les Sprints sont des événements de durée fixe d'un mois ou moins, pour créer de la constance : on ne rallonge pas un Sprint qui « n'a pas fini ». Ensuite, un nouveau Sprint démarre immédiatement après la conclusion du précédent. Pas de semaine de battement, pas de phase intermédiaire : le cœur bat sans pause — les « sprints de stabilisation » intercalés que l'on croise parfois sur le terrain sont des inventions locales, pas du Scrum tel que défini.
Le Sprint est aussi le lieu unique du travail : tout le travail nécessaire pour atteindre le Product Goal (l'objectif de produit), y compris la Sprint Planning, les Daily Scrums, la Sprint Review et la Sprint Retrospective, se passe à l'intérieur des Sprints. Le schéma d'ensemble tient en une ligne :
┌──────────────────── LE SPRINT (durée fixe, un mois ou moins) ────────────────────┐
│ │
│ Sprint Planning ──► Daily Scrums (chaque jour) ──► Sprint Review ──► Sprint │
│ (initie le Sprint) Retrospective │
│ + tout le travail vers le Product Goal │
│ │
└─── fin du Sprint ──► un nouveau Sprint démarre IMMÉDIATEMENT ────────────────────┘Les trois autres événements internes seront détaillés au chapitre suivant ; retenons ici qu'ils n'existent que portés par le conteneur.
Ce qui est garanti pendant le Sprint
Le guide fixe quatre règles pour la durée du Sprint, qui dessinent un équilibre subtil entre stabilité et souplesse :
- aucun changement n'est fait qui mettrait en danger le Sprint Goal (l'objectif du Sprint) ;
- la qualité ne diminue pas ;
- le Product Backlog est affiné au besoin ;
- le périmètre peut être clarifié et renégocié avec le Product Owner à mesure que l'on en apprend davantage.
La lecture croisée de ces règles est essentielle. Le Sprint n'est pas un tunnel figé où plus rien ne bouge une fois la Planning terminée : le périmètre exact reste négociable, l'affinage continue. Mais il n'est pas non plus un flux ouvert où tout se rediscute chaque matin : le Sprint Goal est le point fixe, et la qualité n'est jamais une variable d'ajustement. Quand la réalité surprend l'équipe, on adapte le comment et l'étendue du quoi, jamais le pourquoi ni le niveau d'exigence.
À retenir
Stabilité ne veut pas dire rigidité. Le Sprint protège l'équipe des changements qui invalideraient son objectif, mais il autorise explicitement la clarification et la renégociation du périmètre avec le Product Owner. L'anti-pattern classique — observation de terrain, pas texte du guide — consiste à confondre les deux : une direction qui injecte des urgences en plein Sprint au mépris du Sprint Goal, ou une équipe qui refuse toute discussion « parce que le Sprint est verrouillé ». Le guide condamne la première dérive et n'a jamais prescrit la seconde.
Un mois ou moins : la maîtrise de l'horizon
Pourquoi cette limite d'un mois ? Parce que les Sprints rendent le travail prédictible en garantissant l'inspection et l'adaptation de la progression vers le Product Goal au moins une fois par mois calendaire. La prédictibilité, dans un cadre empirique, ne vient pas de plans détaillés à long terme mais de la fréquence des points de contrôle. Le guide décrit ce qui se dégrade quand l'horizon s'allonge trop : le Sprint Goal peut devenir invalide, la complexité peut monter, et le risque peut augmenter.
À l'inverse, des Sprints plus courts peuvent être employés pour générer davantage de cycles d'apprentissage et limiter le risque, en coût et en effort, à une fenêtre de temps plus réduite : plus le battement est rapide, plus l'équipe apprend souvent, et moins chaque erreur coûte cher. Le guide résume d'une image : chaque Sprint peut être considéré comme un court projet — avec son objectif, son plan, son résultat inspectable.
Les indicateurs ne remplacent pas l'empirisme
Le guide reconnaît diverses pratiques de projection de l'avancement — burn-downs, burn-ups, flux cumulés (cumulative flows) — et leur concède d'avoir prouvé leur utilité. Mais il enchaîne aussitôt sur l'un des passages les plus profonds du texte : ces pratiques ne remplacent pas l'importance de l'empirisme. Dans les environnements complexes, ce qui va se produire est inconnu ; seul ce qui s'est déjà produit peut servir à la prise de décision tournée vers l'avenir. Un graphique de tendance extrapole ; l'empirisme exige de regarder le produit réel, l'Increment réellement terminé, avant de décider. Le graphique peut informer la conversation — il ne peut pas la remplacer.
Note
On remarquera ce que le Scrum Guide 2020 ne contient pas : ni user stories, ni story points, ni vélocité n'y figurent. Ces outils, omniprésents dans les équipes agiles, appartiennent aux pratiques complémentaires que le guide laisse volontairement hors de son périmètre. Le texte se contente d'évoquer « la connaissance de la performance passée » sans imposer la moindre unité de mesure.
L'annulation : une autorité unique
Le Sprint peut-il s'arrêter avant son terme ? Oui, mais dans un seul cas et sur décision d'une seule personne : un Sprint peut être annulé si le Sprint Goal devient obsolète, et seul le Product Owner a l'autorité d'annuler le Sprint. Deux phrases dans le guide, mais lourdes de sens : ni le management, ni le Scrum Master, ni les Developers ne détiennent ce pouvoir. Et le critère n'est pas « le Sprint se passe mal », mais bien l'obsolescence de l'objectif — à titre d'illustration, un revirement stratégique ou un concurrent qui rend la fonctionnalité visée sans objet. L'annulation reste l'exception ; la règle, c'est le battement régulier.
La Sprint Planning : trois questions pour lancer le Sprint
La Sprint Planning initie le Sprint en établissant le travail à réaliser pour celui-ci. Premier point capital : le plan qui en résulte est créé par le travail collaboratif de toute la Scrum Team — pas par le Product Owner qui dicterait un contenu, ni par les Developers seuls dans leur coin.
La réunion se prépare : le Product Owner s'assure que les participants sont prêts à discuter les éléments les plus importants du Product Backlog et la façon dont ils se rattachent au Product Goal. Une Planning réussie commence donc avant la Planning. La Scrum Team peut par ailleurs inviter d'autres personnes pour fournir des conseils — un expert sécurité, un spécialiste du domaine — sans que ces invités deviennent décideurs.
Le guide structure ensuite l'événement autour de trois sujets (topics), qui répondent à trois questions :
| Sujet | Question du guide | Dynamique | Résultat |
|---|---|---|---|
| Topic One | Why is this Sprint valuable? — pourquoi ce Sprint a-t-il de la valeur ? | Le Product Owner propose comment le produit pourrait gagner en valeur et en utilité ; toute la Scrum Team collabore | Le Sprint Goal, finalisé avant la fin de la Planning |
| Topic Two | What can be Done this Sprint? — que peut-on terminer dans ce Sprint ? | Les Developers sélectionnent des éléments du Product Backlog en discussion avec le Product Owner ; la Scrum Team peut les affiner au passage | Les éléments du Product Backlog sélectionnés pour le Sprint |
| Topic Three | How will the chosen work get done? — comment le travail choisi sera-t-il réalisé ? | Les Developers planifient, à leur seule discrétion | Un plan actionnable pour livrer l'Increment |
Topic One — pourquoi ce Sprint a-t-il de la valeur ?
Tout commence par la valeur, pas par la liste des tâches. Le Product Owner propose comment le produit pourrait accroître sa valeur et son utilité dans le Sprint qui s'ouvre. Puis toute la Scrum Team collabore pour définir un Sprint Goal qui communique aux parties prenantes pourquoi ce Sprint a de la valeur. Le Sprint Goal n'est donc ni imposé par le Product Owner ni rédigé après coup pour habiller une liste de tickets : c'est une construction collective, et le guide est formel sur l'échéance — le Sprint Goal doit être finalisé avant la fin de la Sprint Planning.
Topic Two — que peut-on terminer dans ce Sprint ?
Vient ensuite la sélection : par la discussion avec le Product Owner, les Developers choisissent les éléments du Product Backlog à inclure dans le Sprint. Le verbe compte : ce sont les Developers qui sélectionnent, car ce sont eux qui s'engageront sur le travail. La Scrum Team peut affiner ces éléments pendant ce processus, ce qui accroît la compréhension et la confiance.
Le guide reconnaît avec honnêteté que choisir la quantité de travail réalisable dans un Sprint peut être difficile. Il ne fournit ni formule ni outil d'estimation, mais identifie trois sources de confiance : plus les Developers connaissent leur performance passée, leur capacité à venir et leur Definition of Done, plus ils seront confiants dans leurs prévisions de Sprint. L'historique réel, la disponibilité réelle, l'exigence de qualité réelle — encore l'empirisme, appliqué cette fois à la prévision.
Topic Three — comment le travail sera-t-il réalisé ?
Enfin, le plan : pour chaque élément sélectionné, les Developers planifient le travail nécessaire pour créer un Increment conforme à la Definition of Done. Le guide décrit une pratique fréquente : décomposer les éléments du Product Backlog en éléments de travail plus petits, d'une journée ou moins — une granularité qui rendra la progression inspectable jour après jour.
Et il ferme la porte à toute ingérence : la façon de faire est à la seule discrétion des Developers ; personne d'autre ne leur dit comment transformer des éléments de Product Backlog en Increments de valeur. Ni le Product Owner, ni le Scrum Master, ni un architecte ou un manager extérieur.
Attention
C'est l'une des frontières les plus nettes du cadre : le pourquoi se construit à plusieurs, le quoi se négocie entre Developers et Product Owner, mais le comment appartient exclusivement aux Developers. Une organisation qui impose aux équipes leur découpage technique ou leur manière de travailler pendant le Sprint viole cette règle — et sape au passage l'auto-gestion sur laquelle repose toute l'adaptation.
Le résultat : le Sprint Backlog, et une timebox
La Planning produit un artefact unique en assemblant ses trois réponses : le Sprint Goal, les éléments du Product Backlog sélectionnés pour le Sprint, plus le plan pour les livrer forment ensemble le Sprint Backlog. Pourquoi, quoi, comment : les trois couches du même engagement, examinées en détail au chapitre sur les artefacts.
Côté durée, la Sprint Planning est limitée à un maximum de huit heures pour un Sprint d'un mois ; pour des Sprints plus courts, l'événement est généralement plus court. Huit heures peuvent sembler considérables, mais rapportées à un mois de travail d'équipe, elles représentent l'investissement qui évite des semaines d'efforts mal dirigés. La timebox est un plafond, pas une cible : une équipe rodée, servie par un Product Backlog bien affiné, aboutit souvent bien plus vite.
À retenir
- Le Sprint est le conteneur de tous les autres événements ; chaque événement est une opportunité formelle d'inspecter et d'adapter les artefacts — ne pas les tenir comme prescrit, c'est perdre ces opportunités. Les événements créent de la régularité, minimisent le besoin d'autres réunions et se tiennent idéalement à la même heure et au même endroit.
- Le Sprint est le battement de cœur de Scrum, où les idées deviennent de la valeur : durée fixe d'un mois ou moins, nouveau Sprint démarrant immédiatement après le précédent ; tout le travail vers le Product Goal se passe dans les Sprints.
- Pendant le Sprint : aucun changement qui mettrait en danger le Sprint Goal, la qualité ne diminue pas, le Product Backlog est affiné au besoin, et le périmètre peut être clarifié et renégocié avec le Product Owner à mesure que l'on apprend.
- Les Sprints garantissent inspection et adaptation au moins chaque mois calendaire ; un horizon trop long invalide le Sprint Goal et accroît complexité et risque, tandis que des Sprints plus courts multiplient les cycles d'apprentissage.
- Burn-downs, burn-ups et flux cumulés sont utiles mais ne remplacent pas l'empirisme : en environnement complexe, seul ce qui s'est déjà produit peut fonder les décisions tournées vers l'avenir.
- Seul le Product Owner a l'autorité d'annuler un Sprint, et uniquement si le Sprint Goal devient obsolète.
- La Sprint Planning, œuvre collaborative de toute la Scrum Team, répond à trois questions : pourquoi (le Sprint Goal, finalisé avant la fin de la Planning), quoi (les éléments sélectionnés par les Developers avec le Product Owner), comment (le plan, à la seule discrétion des Developers).
- Sprint Goal + éléments sélectionnés + plan = le Sprint Backlog ; la Planning est limitée à huit heures maximum pour un Sprint d'un mois, généralement moins pour des Sprints plus courts.