Sprint Planning

  • Concept
  • Intermédiaire
  • Transversal
  • Toujours utilisé

En bref

Réunion d'équipe qui ouvre un sprint Scrum : elle sélectionne les tâches à réaliser et fixe l'objectif du sprint à venir.

Définition complète

Le Sprint Planning (planification de sprint) est une réunion d’équipe qui ouvre chaque nouveau sprint dans la méthode Scrum (un cadre de travail agile organisé en cycles courts appelés sprints, généralement de une à quatre semaines). L’équipe y sélectionne les éléments du backlog (la liste des tâches et fonctionnalités à réaliser, classées par priorité) qu’elle s’engage à livrer, estime la charge de travail nécessaire et définit un objectif clair pour le sprint, appelé sprint goal.

Par exemple, une équipe de développement dispose d’une capacité de 60 points (une unité qui mesure l’effort estimé) pour un sprint de deux semaines. Lors du Sprint Planning, elle choisit dans le backlog les user stories (des besoins utilisateurs décrits sous forme de phrases courtes) qui totalisent environ 60 points, ni plus ni moins, pour rester réaliste.

Attention : un Sprint Planning n’est pas une simple répartition de tâches décidée par le chef de projet ; c’est l’équipe elle-même qui s’engage sur ce qu’elle peut réellement produire, ce qui change la dynamique de responsabilité.

À quoi ça sert

Le Sprint Planning sert à donner à l’équipe une feuille de route claire et réaliste pour les prochaines semaines de travail, plutôt que d’avancer sans direction précise. Il évite les sprints surchargés, où l’équipe s’engage sur plus de travail qu’elle ne peut en livrer, et les sprints trop légers, où le temps disponible n’est pas exploité.

Cette réunion permet aussi de clarifier les attentes entre le product owner (la personne qui représente les besoins du client ou de l’utilisateur final) et l’équipe technique : chacun sait précisément ce qui sera livré à la fin du sprint et pourquoi.

Enfin, elle sert de point de référence pour mesurer, en fin de sprint, si l’équipe a tenu son engagement, ce qui alimente les cycles d’amélioration continue propres à l’agilité.

Cas d'usage typiques

– Démarrer un sprint : quelles user stories l’équipe peut-elle réellement livrer avec sa capacité actuelle ?
– Clarifier un objectif flou : transformer une liste de tâches dispersées en un sprint goal unique et compréhensible.
– Arbitrer les priorités : quand deux fonctionnalités sont urgentes, laquelle entre réellement dans le sprint ?
– Estimer la charge de travail : associer un nombre de points ou de jours à chaque tâche du backlog.
– Aligner product owner et équipe technique sur ce qui sera livré et dans quel délai.
– Anticiper les dépendances : repérer les tâches qui bloquent d’autres tâches avant de démarrer.

Ce que tu sauras faire

Savoir organiser un Sprint Planning efficace : sélectionner les bonnes priorités du backlog, estimer une charge de travail réaliste et formuler un objectif de sprint clair et partagé par toute l'équipe.

Mises en situation

Situation 1 : une équipe qui s’engage sur trop de travail

Contexte : une petite agence web a l’habitude de remplir son sprint jusqu’au bord, sans marge, pour rentabiliser chaque journée.

Application : lors du Sprint Planning, l’équipe compare la charge sélectionnée à sa vélocité moyenne (le volume de travail réellement livré lors des sprints précédents) et réduit le périmètre de 20 %.

Résultat attendu : le sprint suivant est livré entièrement, sans tâches reportées, ce qui redonne confiance au client et à l’équipe elle-même.

Situation 2 : un objectif de sprint absent

Contexte : une équipe informatique interne enchaîne les sprints comme une simple liste de tickets à cocher, sans vision d’ensemble.

Application : le Scrum Master (l’animateur de la méthode Scrum) impose la formulation d’un sprint goal en une phrase avant toute sélection de tâches.

Résultat attendu : l’équipe retrouve du sens dans son travail et peut expliquer en une phrase, à sa direction, ce qu’elle va livrer dans deux semaines.

Situation 3 : un product owner absent du Sprint Planning

Contexte : dans une PME qui développe une application interne, le product owner saute régulièrement la réunion, jugée trop technique.

Application : l’équipe démontre, chiffres à l’appui, que les sprints sans product owner présent contiennent deux fois plus de tâches mal comprises et reprises en cours de route.

Résultat attendu : le product owner participe désormais systématiquement, et le taux de tâches à refaire diminue nettement.

Application guidée : calculer une capacité de sprint réaliste

Contexte : une équipe de 5 personnes travaille sur un sprint de 10 jours ouvrés. Chaque personne consacre en moyenne 6 heures productives par jour au projet, le reste du temps étant pris par des réunions et imprévus.

Question : quelle est la capacité totale disponible pour ce sprint, en heures ?

Résultat attendu : 5 personnes x 10 jours x 6 heures = 300 heures. L’équipe doit sélectionner un volume de tâches dont l’estimation totale ne dépasse pas 300 heures, avec une marge de sécurité d’environ 10 %.

Application guidée : repérer un sprint mal planifié

Contexte : à la fin d’un sprint, l’équipe n’a livré que 60 % des tâches prévues, alors que sa vélocité moyenne des trois derniers sprints était de 90 %.

Question : quelles hypothèses faut-il vérifier pour comprendre cet écart avant le prochain Sprint Planning ?

Résultat attendu : vérifier si des absences imprévues ont réduit la capacité réelle, si des tâches ont été mal estimées au départ, ou si de nouvelles urgences se sont ajoutées en cours de sprint sans être retirées d’autre part.

Pour bien le retenir

L'analogie

Le Sprint Planning ressemble à la réunion de service d’un restaurant avant le coup de feu du soir. Le chef et la brigade regardent les réservations du jour, décident ensemble quels plats de la carte ils peuvent réellement préparer avec le personnel présent, et qui s’occupe de quoi. Personne ne promet de servir 200 couverts si la cuisine ne peut en assumer que 120 : mieux vaut annoncer un objectif tenable et le réussir, plutôt que de viser trop haut et décevoir tout le monde.

« Planifier un sprint, c'est promettre ce qu'on peut vraiment tenir, pas ce qu'on aimerait faire. »

Pièges à éviter

À ne pas confondre avec

Une erreur fréquente consiste à confondre le Sprint Planning avec une simple réunion de répartition des tâches par un manager : dans Scrum, c'est l'équipe elle-même qui s'engage, pas une personne qui distribue le travail depuis le haut.

Autre piège : croire qu'un sprint planning réussi garantit que tout sera livré. Un sprint peut légitimement évoluer si un imprévu majeur survient ; l'objectif est de réduire les surprises, pas de les éliminer totalement.

Enfin, certaines équipes sautent l'étape d'estimation de charge et se contentent d'empiler des tâches au feeling, ce qui rend les écarts de fin de sprint impossibles à expliquer.

Évolution historique

Apparition : Années 1990-2000, avec la formalisation de la méthode Scrum

Quels changements depuis l’arrivée de l’IA ?

Avant

Le Sprint Planning reposait entièrement sur la discussion humaine : l’équipe évaluait chaque tâche à la main, souvent avec des cartes à jouer (technique du planning poker) pour estimer la charge de travail collectivement.

Aujourd’hui

Certains outils de gestion agile intègrent désormais des suggestions automatiques d’estimation, basées sur l’historique des sprints précédents, ou des résumés générés automatiquement des tickets du backlog. Ces aides restent des points de départ : la décision finale sur ce que l’équipe s’engage à livrer reste une discussion humaine, car elle implique la confiance et l’engagement collectif, deux éléments qu’un algorithme ne peut pas décider à la place des personnes concernées.

Évolution historique

Années 1990 : Jeff Sutherland et Ken Schwaber formalisent la méthode Scrum, qui introduit la notion de sprint et de réunion de planification en début de cycle.

Années 2000 : le Manifeste Agile, publié en 2001, popularise ces pratiques bien au-delà du développement logiciel, dans de nombreuses équipes projet.

Années 2010 : le Sprint Planning se généralise dans les entreprises grâce à des outils numériques comme Jira ou Trello, qui facilitent le suivi du backlog et de la vélocité.

Années 2020 : le télétravail impose des Sprint Planning à distance, via des tableaux collaboratifs en ligne, et les premiers assistants d’estimation basés sur l’intelligence artificielle apparaissent dans certains outils.