Sprint planning

Le sprint planning (ou planification de sprint) est la réunion qui ouvre chaque sprint dans le cadre Scrum. Toute l’équipe y participe : les développeurs, le Scrum Master et le Product Owner. Pour un sprint de deux semaines, elle dure en général deux à quatre heures. La question à laquelle elle répond tient en une ligne : que construit-on d’ici la fin du sprint, et pourquoi ?

C’est le moment où les priorités business rencontrent la réalité technique. Le Product Owner apporte le contexte : ce que les utilisateurs demandent et ce que l’entreprise vise. Les développeurs apportent leur connaissance du code et les risques qu’ils anticipent. Le Scrum Master facilite les échanges et tient le temps. La réunion produit le sprint backlog : un objectif, une liste d’éléments sélectionnés et un plan pour les livrer, en cohérence avec la roadmap produit.

À quoi sert le sprint planning

Sans sprint planning, une équipe travaille au fil de l’eau : chacun prend le ticket du haut de la pile, les priorités changent au gré des demandes, et personne ne sait dire ce qui sera livré à la fin du mois. Le sprint planning remplace ce flux continu par un contrat court et explicite : pendant deux semaines, le périmètre est stable et les parties prenantes savent ce qu’elles verront à la revue de sprint.

Pour un fondateur, c’est aussi le moment où les décisions produit se prennent réellement. Une roadmap est une intention. Le sprint planning engage du temps de développement sur des éléments précis, et ce qui n’y entre pas n’existera pas dans deux semaines.

Comment se déroule un sprint planning

Le Guide Scrum (version 2020) structure la réunion autour de trois questions, dans cet ordre. Beaucoup d’équipes les traitent à l’envers, en commençant par la liste des tickets, et c’est souvent là que le planning s’enlise.

Pourquoi ce sprint a-t-il de la valeur ? L’objectif du sprint

La première étape est de formuler l’objectif du sprint (sprint goal) : une phrase qui donne du sens au travail des deux prochaines semaines. « Permettre à un nouvel utilisateur de s’inscrire en moins d’une minute » est un bon objectif. Il est précis, vérifiable et lié à un résultat pour l’utilisateur. « Finir le backlog » ou « livrer trente points » n’en sont pas : ce sont des volumes, qui ne disent rien de la valeur créée.

L’objectif sert ensuite de boussole au quotidien. Quand un arbitrage se présente en cours de sprint, faut-il traiter ce bug maintenant ou attendre, la réponse se lit dans l’objectif. Il permet aussi de résumer le sprint en une phrase à un client ou à un investisseur, sans lui lire une liste de tickets.

Que peut-on livrer ? La sélection des éléments du backlog

Le Product Owner présente les éléments du haut du backlog : user stories, corrections de bugs, améliorations techniques. Pour chacun, l’équipe vérifie qu’elle comprend ce qui est attendu (les critères d’acceptation), repère les dépendances et estime l’effort. L’ordre de présentation découle d’un travail de priorisation des fonctionnalités fait en amont, pas d’une décision prise en séance.

L’estimation se fait souvent en points de complexité (story points), une mesure relative qui mélange difficulté technique, incertitude et volume de travail. Le planning poker, où chaque développeur annonce son estimation en même temps que les autres, évite qu’une voix dominante entraîne le groupe. Son vrai intérêt n’est pas le chiffre obtenu, mais la discussion qui suit quand deux estimations divergent : elle révèle presque toujours une différence de compréhension du besoin.

Comment va-t-on s’y prendre ? Le découpage en tâches

Une fois les éléments retenus, les développeurs les décomposent en tâches techniques concrètes. « L’utilisateur peut réinitialiser son mot de passe » devient « créer le point d’entrée API de réinitialisation », « envoyer l’e-mail avec le lien temporaire », « construire le formulaire de nouveau mot de passe ». Ce découpage n’a pas besoin d’être exhaustif le premier jour : le Guide Scrum précise que le plan se complète au fil du sprint. Il doit suffire pour démarrer et pour que l’avancement soit lisible aux daily meetings.

Engagement ou prévision ? Ce sur quoi l’équipe s’engage vraiment

Un malentendu courant : la liste des éléments sélectionnés serait une promesse ferme. Depuis 2011, le Guide Scrum parle de « prévision » (forecast) pour ces éléments. L’engagement de l’équipe porte sur l’objectif du sprint. Si une story s’avère plus lourde que prévu, l’équipe renégocie le périmètre avec le Product Owner sans toucher à l’objectif.

Cette nuance change la façon de planifier. La capacité de l’équipe se fonde sur la vélocité des sprints précédents, c’est-à-dire le nombre de points livrés en moyenne. Cette mesure se stabilise au bout de trois ou quatre sprints et sert aussi à projeter la roadmap : à vélocité constante, combien de sprints pour livrer telle version ? Elle reste un outil interne à l’équipe. Dès qu’elle sert à comparer des équipes ou à mettre la pression, les estimations gonflent et la mesure perd toute valeur.

Estimer en 2026 : story points, vélocité et IA

Le Guide Scrum n’impose ni story points ni vélocité. Ce sont des pratiques venues de l’Extreme Programming, et Ron Jeffries, à qui l’on attribue l’invention des story points, a écrit en 2019 qu’il regrettait l’usage qui en est fait. Une partie des équipes a d’ailleurs abandonné les points au profit d’un simple comptage d’éléments de taille comparable, ou d’une estimation en jours pour les projets au forfait.

Les assistants de code par IA ajoutent une incertitude nouvelle. Une tâche qui prenait deux jours peut en prendre un demi, ou déborder parce que le code généré doit être repris. L’historique de vélocité d’avant ces outils devient un repère fragile. Les études sur la productivité des développeurs avec l’IA montrent même un écart marqué entre le temps gagné perçu et le temps réellement mesuré. En sprint planning, cela plaide pour des estimations prudentes et une vélocité relue sur les derniers sprints seulement.

La préparation : le backlog refinement

Un sprint planning efficace commence avant la réunion. Le Product Owner prépare le backlog en amont : les éléments prioritaires sont décrits et leurs critères d’acceptation posés. Ce travail, appelé backlog refinement (l’ancien terme « grooming » a disparu du Guide Scrum en 2013), fait la différence entre un planning de deux heures et un planning de quatre heures qui s’épuise en clarifications.

Le refinement se tient en général en milieu de sprint, sous forme d’une session d’une heure. L’équipe y relit les stories à venir, découpe ce qui est trop gros et pré-estime. Si, le jour du planning, l’équipe passe l’essentiel du temps à comprendre les tickets au lieu de décider, c’est ce travail qui a manqué.

Fonctionnalités, bugs et dette technique : composer le sprint

Un sprint bien composé ne contient pas que des fonctionnalités nouvelles. Les équipes qui tiennent leurs sprints réservent une part de leur capacité, souvent entre 10 et 20 %, pour les corrections et l’entretien de la dette technique. Un sprint planifié à 100 % dérape au premier incident, et il y a toujours un incident. Nous détaillons cette règle et la façon de chiffrer la dette dans un article dédié.

Cet arbitrage entre nouveauté et entretien est une décision de fondateur autant que de développeur : trop de nouveautés fragilisent le produit, trop d’entretien et plus rien ne semble avancer. Le sprint planning est le moment où cet équilibre est rendu explicite et chiffré.

Les erreurs qui plombent un sprint planning

La plus fréquente est le surengagement. Par optimisme ou sous pression, l’équipe prend plus qu’elle ne peut livrer. Le sprint se termine avec du travail à moitié fait, et la confiance s’érode des deux côtés : celle de l’équipe dans ses estimations, celle du client dans les livraisons. Mieux vaut prendre moins et tout livrer.

Vient ensuite l’absence du Product Owner, ou sa présence sans préparation. Sans la personne qui porte les priorités, le planning devient un exercice technique déconnecté du marché : l’équipe travaille sur ce qu’elle croit important.

Troisième erreur : le planning descendant, où un manager distribue les tâches. Ce n’est plus du Scrum mais de la gestion de projet classique sous un autre nom, et des tâches assignées d’en haut sont presque toujours sous-estimées, puis subies.

Enfin, l’ajout de travail en cours de sprint. « On glisse juste cette petite demande » est la phrase qui détruit la prévisibilité. Un bug bloquant en production ne peut pas attendre, mais chaque ajout doit rester l’exception et s’accompagner du retrait d’un élément de valeur comparable.

Le sprint planning dans le cycle Scrum

Le sprint planning n’est pas une réunion isolée. La rétrospective du sprint précédent l’alimente : si l’équipe a décidé d’une action d’amélioration, elle entre dans le plan du sprint suivant au même titre qu’une fonctionnalité. Les daily meetings suivent ensuite l’avancement par rapport à l’objectif fixé. La revue de sprint, en fin de cycle, montre ce qui a été livré aux parties prenantes et fait remonter leurs retours dans le backlog, qui nourrit le planning suivant. Chaque planning profite ainsi des leçons du précédent.

FAQ sprint planning

Combien de temps dure un sprint planning ?

Le Guide Scrum fixe un maximum de huit heures pour un sprint d’un mois, et la durée se réduit avec des sprints plus courts. Pour un sprint de deux semaines, deux à quatre heures suffisent si le backlog a été affiné en amont. Au-delà, le problème vient presque toujours d’un manque de refinement, pas de la réunion elle-même.

Quelle différence entre sprint planning et backlog refinement ?

Le refinement prépare : il clarifie, découpe et pré-estime les éléments du backlog, en continu ou lors d’une session dédiée en cours de sprint. Le sprint planning décide : il fixe l’objectif, sélectionne les éléments et établit le plan du sprint qui commence. Le premier est une activité continue, le second un événement à date fixe.

Le fondateur doit-il participer au sprint planning ?

Oui, s’il tient le rôle de Product Owner, et c’est le cas dans la plupart des startups en phase de lancement. Il n’a pas besoin de comprendre le code. Son rôle est d’expliquer pourquoi chaque élément compte, de répondre aux questions sur le besoin et de trancher quand il faut réduire le périmètre. Un fondateur qui délègue cette réunion découvre trop souvent à la revue de sprint que l’équipe a construit autre chose que ce qu’il attendait.

Comment Polara Studio conduit les sprint plannings

Chez Polara Studio, le sprint planning suit un format fixe : deux heures maximum, le lundi matin, avec toute l’équipe et le Product Owner, qui est le plus souvent le fondateur ou le responsable produit côté client.

La première demi-heure est consacrée à l’objectif du sprint et au contexte business : retours des utilisateurs, changements de priorités depuis la dernière revue. Le reste du temps sert à sélectionner et estimer les éléments du backlog, déjà affinés lors d’une session de refinement la semaine précédente. Nous planifions à environ 80 % de la capacité mesurée pour absorber les imprévus, et nous réservons une part de chaque sprint aux corrections et à la dette technique.

Ce que nous constatons : les premiers plannings d’un projet sont longs, parce que le vocabulaire commun entre le client et l’équipe se construit. À partir du troisième ou quatrième sprint, la vélocité se stabilise et la réunion tient dans l’heure et demie. Le sprint planning sert alors à décider, plus à découvrir les sujets.