L’équipe StockPro a un backlog ordonné et estimé. Comment passe-t-on de cette liste à « voici ce qu’on construit ces deux prochaines semaines » ? Par le Sprint Planning, l’événement qui ouvre chaque Sprint. Mal mené, il se résume à empiler des tâches jusqu’à remplir l’agenda — et le Sprint explose en vol. Bien mené, il produit un cap clair et un plan que toute l’équipe comprend et s’approprie. À la fin de ce tutoriel, vous saurez préparer la séance, formuler un objectif de Sprint, sélectionner la juste quantité de travail et bâtir un Sprint Backlog exploitable.

Ce que vous allez apprendre

Le but et la durée du Sprint Planning selon le Guide Scrum 2020.
Construire un objectif de Sprint (Sprint Goal) qui donne du sens au Sprint.
Sélectionner les éléments réalisables en tenant compte de la capacité et de la Definition of Done.
Décomposer le travail en un Sprint Backlog actionnable.

Ce que vous allez construire

Vous repartirez avec le premier Sprint Backlog de StockPro : un objectif de Sprint en une phrase, la liste des éléments retenus, et leur décomposition en tâches concrètes — le plan que les Developers suivront et adapteront chaque jour.

Prérequis

Un backlog affiné et estimé — voir Estimer en équipe : story points et planning poker.
Toute l’équipe Scrum présente : Product Owner, Scrum Master et Developers.
Une première idée de la capacité de l’équipe pour le Sprint (jours réellement disponibles).
Niveau : débutant à intermédiaire. Durée estimée : la séance elle-même dure quelques heures ; comptez 30 minutes de lecture.

Étape 1 — Comprendre le but et le cadre temporel

Le Guide Scrum 2020 le dit clairement : le Sprint Planning initie le Sprint en exposant le travail à réaliser, et le plan qui en résulte est créé par le travail collaboratif de toute l’équipe Scrum. Ce n’est pas le Product Owner qui distribue, ni le Scrum Master qui décide : c’est une co-construction.

Côté durée, l’événement est encadré (timeboxé) à huit heures maximum pour un Sprint d’un mois, et proportionnellement moins pour des Sprints plus courts. Pour un Sprint de deux semaines — courant et recommandé pour débuter — visez donc autour de quatre heures. Cette limite n’est pas une contrainte arbitraire : elle force l’équipe à décider plutôt qu’à tourner en rond.

Le Product Owner prépare la séance : il s’assure que les participants peuvent discuter des éléments les plus importants du backlog et de la façon dont ils servent le Product Goal. Un Sprint Planning sans préparation, c’est une séance qui déborde ; la préparation est le premier levier d’efficacité.

✅ Point d’étape. Avant la séance, le haut du backlog est ordonné, estimé, et chacun sait quel Product Goal on poursuit. Si ces conditions ne sont pas réunies, faites une courte séance d’affinage d’abord.

Étape 2 — Sujet 1 : pourquoi ce Sprint a-t-il de la valeur ?

Le Guide Scrum structure le Sprint Planning autour de trois sujets. Le premier répond à « pourquoi ce Sprint est-il précieux ? ». Le Product Owner propose comment le produit pourrait gagner en valeur, puis toute l’équipe collabore pour définir un objectif de Sprint (Sprint Goal) qui communique en quoi le Sprint a de la valeur pour les parties prenantes. Cet objectif doit être finalisé avant la fin du Sprint Planning.

L’objectif de Sprint n’est pas la liste des stories : c’est leur sens commun, énoncé en une phrase. Pour le premier Sprint de StockPro :

Objectif de Sprint :
"Un vendeur peut enregistrer une vente et voir
 le stock se mettre a jour, de bout en bout."

Cet énoncé est puissant parce qu’il donne une boussole. Si, en cours de Sprint, une story se révèle plus dure que prévu, l’équipe peut négocier le détail avec le Product Owner sans trahir l’objectif : tant qu’à la fin « un vendeur peut enregistrer une vente et voir le stock bouger », le Sprint est réussi. L’objectif offre de la souplesse sur le « comment » exact.

Étape 3 — Sujet 2 : que peut-on terminer ce Sprint ?

Le deuxième sujet est « que peut-on faire ce Sprint ? ». Les Developers, en discussion avec le Product Owner, sélectionnent des éléments du Product Backlog pour le Sprint courant. Ils peuvent les affiner au passage, ce qui augmente la confiance. Point capital : ce sont les Developers qui décident combien ils prennent, pas le Product Owner qui pousse.

Le Guide Scrum note que juger ce qu’on peut terminer est difficile, et donne trois appuis : plus les Developers connaissent leur performance passée (la vélocité), leur capacité à venir (congés, autres engagements) et leur Definition of Done, plus ils estiment juste. Pour StockPro : la vélocité prévisionnelle est d’environ 20 points, mais un Developer est absent deux jours ; l’équipe choisit donc prudemment des éléments totalisant 15 points, alignés sur l’objectif de Sprint.

✅ Point d’étape. La somme des éléments retenus doit tenir dans la capacité réelle du Sprint, pas dans le meilleur des cas. Mieux vaut finir tout ce qu’on a pris que de tout commencer sans rien terminer.

Étape 4 — Sujet 3 : comment le travail sera-t-il fait ?

Le troisième sujet est « comment le travail choisi sera-t-il réalisé ? ». Pour chaque élément sélectionné, les Developers planifient le travail nécessaire pour créer un incrément conforme à la Definition of Done. Le Guide Scrum suggère souvent de décomposer les éléments en tâches plus petites, d’un jour ou moins. Et il insiste : personne d’autre que les Developers ne leur dit comment transformer le backlog en incrément.

Concrètement, la story « enregistrer une vente simple » se décompose en tâches :

Story : Enregistrer une vente simple (5 points)
  - Concevoir l'ecran de saisie (front)
  - Creer l'API d'enregistrement (back)
  - Ecrire le test d'enregistrement
  - Brancher la decrement de stock
  - Verifier le recapitulatif avant validation

Cette décomposition n’a pas besoin d’être exhaustive ni figée : c’est un point de départ que l’équipe ajustera au Daily Scrum. L’ensemble — objectif de Sprint, éléments sélectionnés et plan de réalisation — forme le Sprint Backlog.

Étape 5 — Formaliser le Sprint Backlog

Le Sprint Backlog est l’artefact produit par cette séance. Le Guide Scrum le décrit comme la composition de trois choses : le pourquoi (l’objectif de Sprint), le quoi (les éléments sélectionnés) et le comment (le plan actionnable pour livrer l’incrément). Son engagement est l’objectif de Sprint. C’est un plan vivant, fait par et pour les Developers, suffisamment détaillé pour qu’au Daily Scrum on puisse mesurer l’avancement.

Affichez le Sprint Backlog là où l’équipe travaille : un tableau à colonnes (À faire / En cours / Fait) rend la progression visible. Ce tableau devient le cœur du pilotage quotidien, sujet du tutoriel suivant.

✅ Point d’étape final. En sortant du Sprint Planning, chacun doit pouvoir énoncer l’objectif de Sprint et voir, sur le tableau, les tâches du premier jour. Si l’objectif est flou ou le plan vide, la séance n’est pas terminée.

Calculer une capacité honnête

La « capacité à venir » reste une abstraction tant qu’on ne la chiffre pas. Une méthode simple suffit pour débuter. Comptez les jours-personnes réellement disponibles sur le Sprint, puis retranchez les indisponibilités connues. Pour le premier Sprint de StockPro, sur deux semaines (dix jours ouvrés) : trois Developers, soit trente jours-personnes théoriques. Retirez deux jours d’absence d’un Developer, une demi-journée par personne pour les événements Scrum, et une marge pour l’imprévu : il reste environ vingt-deux jours-personnes utiles.

Cette capacité dialogue avec la vélocité : si vingt points correspondaient d’ordinaire à une équipe au complet, une équipe amputée de deux jours vise logiquement plus bas. L’objectif n’est pas un calcul exact — il n’existe pas — mais un ordre de grandeur défendable qui empêche de promettre l’impossible. Au fil des Sprints, l’équipe affine son propre repère et se fie de moins en moins aux formules.

Pourquoi la Definition of Done conditionne la sélection

On ne peut pas honnêtement répondre à « que peut-on terminer ce Sprint ? » sans s’accorder d’abord sur ce que « terminé » veut dire. C’est le rôle de la Definition of Done, l’engagement attaché à l’incrément dans le Guide Scrum 2020 : une description formelle de l’état que doit atteindre le travail pour être considéré comme fait et faire réellement partie du produit.

Si votre Definition of Done exige que chaque story soit testée, relue et déployable, alors « coder vite fait » ne compte pas comme terminé : la sélection doit en tenir compte. Une équipe qui ignore sa Definition of Done surestime systématiquement ce qu’elle peut livrer, parce qu’elle compte du travail à moitié fait. Pour StockPro, une première Definition of Done raisonnable :

Definition of Done (StockPro) :
- Le code est relu par un autre Developer.
- Un test automatique couvre le cas principal.
- La fonctionnalite tourne sur l'environnement de demo.
- Aucune regression connue sur les ventes et le stock.

Cette définition est commune à tous les éléments : elle ne se négocie pas story par story, contrairement aux critères d’acceptation. La fixer avant le Sprint Planning, c’est se donner une mesure honnête de la capacité — et éviter le grand classique du « c’est fini… enfin, presque ». Nous détaillerons comment la faire évoluer dans le tutoriel sur la clôture du Sprint.

Pièges fréquents

Symptôme	Cause probable	Correctif
Le Sprint déborde, rien n’est terminé	Trop d’éléments sélectionnés	Se baser sur la capacité réelle, pas le scénario idéal
Le Product Owner impose la charge	Sélection non décidée par les Developers	Rendre aux Developers la décision du « combien »
L’équipe ne sait pas pourquoi elle fait ce Sprint	Pas d’objectif de Sprint	Formuler un Sprint Goal en une phrase avant la fin de la séance
La séance dure une journée entière	Backlog non préparé en amont	Affiner avant ; respecter le cadre temporel
« Fait » veut dire des choses différentes selon les gens	Pas de Definition of Done partagée	Établir une Definition of Done avant de planifier

Récapitulatif

Le Sprint Planning ouvre le Sprint par un travail collectif encadré dans le temps — jusqu’à huit heures pour un mois, proportionnellement moins sinon. Il s’organise en trois sujets : le pourquoi (un objectif de Sprint qui donne du sens), le quoi (les éléments que les Developers s’engagent à terminer, calés sur la capacité et la Definition of Done) et le comment (la décomposition en tâches). Le résultat est le Sprint Backlog, dont l’engagement est l’objectif de Sprint. StockPro a maintenant un cap clair pour ses deux prochaines semaines.

Aide-mémoire

Élément	L’essentiel
Durée	≤ 8 h pour un Sprint d’un mois, moins pour plus court
Sujet 1 — Pourquoi	Définir l’objectif de Sprint (finalisé avant la fin)
Sujet 2 — Quoi	Les Developers sélectionnent selon capacité + Definition of Done
Sujet 3 — Comment	Décomposer en tâches d’un jour ou moins
Sprint Backlog	Pourquoi + Quoi + Comment ; engagement = objectif de Sprint

À vous de jouer

Le Product Owner veut absolument caser huit stories (32 points) dans un Sprint où l’équipe boucle d’habitude 20 points. Comment réagit l’équipe ?

Voir une solution

Ce sont les Developers qui évaluent la quantité réaliste à embarquer : la sélection se fait en discussion avec le Product Owner, mais la prévision de ce qu’ils peuvent terminer leur revient. Ils expliquent que 32 points dépassent leur capacité observée : prendre tout garantirait un Sprint inachevé. La bonne conversation est de revenir à l’objectif de Sprint : quelles stories sont indispensables pour l’atteindre ? On retient celles-là (autour de 20 points) et on laisse le reste en haut du backlog pour le Sprint suivant. Le Product Owner garde la priorité ; les Developers gardent la maîtrise de la charge.

Tutoriels frères

Daily Scrum et burndown : piloter le Sprint — faire vivre ce Sprint Backlog au quotidien.
Sprint Review et Rétrospective — clôturer le Sprint et s’améliorer.

Ressources

Vue d’ensemble : Scrum, le cadre Agile pour livrer un produit en équipe.
Source de référence : le Guide Scrum 2020 (Sprint Planning et artefact Sprint Backlog).

FAQ

Qui décide du contenu du Sprint ?
Les Developers sélectionnent les éléments, en discussion avec le Product Owner qui éclaire les priorités. La quantité prise est une décision des Developers : c’est leur engagement.

L’objectif de Sprint peut-il changer en cours de route ?
Le périmètre peut être renégocié avec le Product Owner à mesure qu’on apprend, mais l’objectif de Sprint, lui, reste stable : il est la promesse du Sprint. S’il devient obsolète, c’est un cas où le Sprint pourrait être annulé.

Faut-il tout décomposer en tâches dès la séance ?
Non. On décompose assez pour démarrer et mesurer l’avancement ; le plan s’enrichit jour après jour. Viser des tâches d’un jour ou moins est un repère, pas une obligation rigide.

Combien de temps pour un Sprint de deux semaines ?
Proportionnellement : environ quatre heures, puisque la limite est de huit heures pour un mois. L’important est de finir avec un objectif et un plan, pas d’épuiser le temps.