Sprint backlog

Qu'est-ce qu'un sprint backlog ?

Un sprint backlog, c'est ce que l'équipe s'engage à livrer sur une courte période et comment elle compte s'y prendre. Il répond à une question simple mais essentielle dans un projet mené avec Scrum : sur quoi l'équipe se concentre-t-elle dans les prochaines semaines ?

Définition du sprint backlog

Le sprint backlog est une liste hiérarchisée des tâches et user stories. L'équipe les sélectionne dans le product backlog lors des sprint planning. Contrairement au product backlog, large et sans limite de temps, le sprint backlog se limite à ce que l'équipe s'engage à livrer sur une période précise.

Pourquoi utiliser un sprint backlog : avantages et bénéfices

Un sprint backlog bien construit apporte des bénéfices concrets à l'équipe de développement, au-delà d'e l'une simple bonne organisation :

1. Des estimations plus fiables

En tant que plan d'action détaillé, il aide l'équipe à fixer des délais réalistes pour chaque livrable. Il écarte les échéances qui mettent l'équipe sous pression sans raison.

2. Une équipe plus productive

Des objectifs atteignables réduisent le stress et permettent à l'équipe de rester concentrée. Cela se traduit directement par une meilleure productivité sur la durée du sprint.

3. De meilleures prévisions pour les sprints suivants

En observant sa capacité réelle à terminer les tâches d'un sprint, l'équipe affine ses futures estimations de charge de travail.

4. Une responsabilisation plus forte

L'équipe participe directement à la sélection des tâches et s'engage collectivement sur ce qu'elle peut réaliser. Chacun se sent davantage responsable du résultat final, plutôt que simple exécutant d'un planning décidé par sa hiérarchie.

Le 16e rapport State of Agile de Digital.ai valide d'ailleurs ces bénéfices. Les organisations évoquent une meilleure gestion des priorités changeantes (64 %) et une hausse de la productivité d'équipe (47 %).

Différence entre sprint backlog et product backlog

Le product backlog représente l'ensemble de ce que l'équipe pourrait développer sur le produit dans son ensemble. Le sprint backlog ne contient qu'un sous-ensemble sélectionné de ce product backlog. Les éléments que l'équipe choisit de traiter pendant le sprint en cours.

Ainsi, la relation entre les deux reste à sens unique : le sprint backlog puise ses éléments dans le product backlog. Le product backlog donne la vision d'ensemble et l'avancement global du produit, tandis que le sprint backlog répond à une question plus immédiate : qu'est-ce que l'équipe va livrer dans les prochaines semaines.

Qui gère le sprint backlog ?

Le Product Owner (ou le Product Manager) dirige généralement la réunion de sprint planning et pilote la sélection des éléments à traiter. Cependant, l'équipe décide ensemble le contenu du sprint backlog.

Une fois le sprint lancé, il sert principalement aux développeurs. Ils l'utilisent au quotidien pour suivre leur avancement et organiser leur travail. Ce sont eux qui le tiennent à jour.

Ce que contient un sprint backlog

Selon le Scrum Guide, le sprint backlog se compose de trois éléments :

• L'objectif du sprint (ou Sprint Goal) : c'est le "pourquoi". Un énoncé unique qui donne une direction claire à toute l'équipe pendant la période. Il reste fixe pendant tout le sprint, même si le détail exact du travail nécessaire pour l'atteindre peut évoluer.
• Les éléments sélectionnés : c'est le "quoi". Les user stories ou tâches issues du product backlog que l'équipe choisit de traiter pour atteindre cet objectif.
• Le plan d'action : c'est le "comment". La décomposition concrète de ces éléments en tâches réalisables, suffisamment détaillée pour que l'équipe puisse suivre sa progression au jour le jour.

Les éléments qu'on retrouve dans le sprint backlog

User story

La user story reste l'unité de base du sprint backlog. Elle décrit une fonctionnalité du point de vue de la personne qui l'utilisera, sans jargon technique. Chaque membre de l'équipe doit pouvoir comprendre pourquoi cet élément figure dans le sprint et quel bénéfice il apporte à l'utilisateur final.

Tâches et sous-tâches

Chaque user story se découpe ensuite en tâches concrètes, et une tâche complexe peut elle-même se diviser en plusieurs sous-tâches. Une bonne pratique consiste à nommer chaque tâche par un verbe d'action et lui associer :

• une description claire
• une priorité
• une personne responsable
• un livrable attendu
• une échéance

Exemple de tâche et sous-tâches :

Une user story du type "en tant que gestionnaire, je veux recevoir une alerte quand un stock passe sous un seuil critique" pourrait se découper en plusieurs tâches, par exemple :

• Implémenter la détection du franchissement de seuil
  • Description : détecter automatiquement quand le stock d'un produit passe sous le seuil défini
  • Priorité : Haute
  • Responsable : un développeur backend
  • Livrable : script de détection fonctionnel
  • Échéance : milieu de semaine 1 du sprint
• Déclencher l'envoi de la notification
  • Description : envoyer un email au gestionnaire quand le stock d'un produit passe sous le seuil défini
  • Priorité : Haute
  • Responsable : développeur backend
  • Livrable : Notification fonctionnelle testée sur l'environnement de préproduction
  • Échéance : fin de semaine 1 du sprint
• Tester le comportement avec différents seuils configurés
  • Description : vérifier que l'alerte se déclenche correctement
  • Priorité : Moyenne
  • Responsable : testeur ou développeur
  • Livrable : rapport de test validé
  • Échéance : milieu de semaine 2 du sprint
• Etc.

Bloqueurs techniques

Ce sont les obstacles que l'équipe rencontre pendant le développement, qu'il s'agisse d'un bug imprévu ou de dette technique à traiter avant de pouvoir avancer. Scrum désigne parfois ces bloqueurs sous le terme d'"obstacles".

Quand un bloqueur apparaît en cours de sprint, l'équipe ajoute généralement une tâche ou une sous-tâche dédiée pour le résoudre. Ce type d'imprévu peut parfois remettre en cause l'estimation initiale d'une tâche.

Il est en effet probable que l'équipe découvre, une fois le travail entamé, des problématiques auxquelles elle n'avait pas pensé lors de la planification. Lors de la réunion de rétrospective du sprint, l'équipe revient sur les écarts d'estimation pour comprendre ce qui a été mal anticipé et affiner ses futures estimations.

Répartition des responsabilités

La capacité réelle de l'équipe pèse directement sur ce qu'elle peut raisonnablement inclure dans le sprint. Lorsqu'une tâche entre dans le sprint backlog, elle a besoin d'un responsable clairement identifié, capable de la mener à terme. Cette attribution rend l'avancement du sprint traçable : chacun sait qui doit livrer quoi. L'équipe peut suivre si chaque tâche progresse comme prévu.

Suivi visuel de l'avancement

Deux outils visuels aident l'équipe à suivre sa progression pendant un sprint. Ils permettent de repérer en un coup d'œil si sa charge de travail est trop importante ou au contraire trop légère par rapport à sa capacité réelle.

Le burndown chart représente le travail restant par rapport au temps qu'il reste dans le sprint. Il permet de voir rapidement si l'équipe avance à un rythme cohérent avec l'objectif.

Exemple de burndown chart

Le burnup chart montre au contraire le travail déjà accompli, cumulé au fil du sprint. Il donne une vision complémentaire de la progression réelle.

Exemple de burnup chart

Le sprint se termine avec la sprint review (aussi nommée revue de sprint ou rétrospective de sprint), un moment où l'équipe présente l'incrément produit pendant cette période aux parties prenantes concernées.

Temps estimé et temps réel

Enfin, comparer le temps réellement passé sur une tâche avec son estimation initiale permet à l'équipe de garder une vision juste de sa progression. Cette comparaison régulière, reportée dans le burndown chart, aide à corriger le tir avant que l'écart entre prévision et réalité ne devienne trop important pour respecter les délais du sprint.

Comment créer un sprint backlog ?

Le sprint backlog se construit lors du sprint planning, la réunion qui marque le début de chaque nouveau sprint.

1. Fixer l'objectif du sprint

Comme un sprint se déroule sur une durée fixe, l'équipe a besoin d'un cap clair avant même de sélectionner les tâches. Cet objectif doit rester précis et atteignable dans le temps imparti : il évite à l'équipe de se disperser sur des sujets qui n'y contribuent pas directement.

2. Construire le backlog avec l'équipe de développement

Tout d'abord, le Product Manager (ou Product Owner) pré-sélectionne les users stories discutées lors du sprint planning. Pour cela, il s'appuie principalement sur deux critères :

• la priorité fixée sur le product backlog (les features et user stories jugées les plus importantes passent en premier)
• l'estimation en points attribuée à chaque user story par l'équipe elle-même (une mesure relative de la complexité ou de l'effort nécessaire, pas une durée en heures),

Ensuite, lors de la réunion de sprint planning, le Product Manager discute avec l'équipe de développement des éléments pré-sélectionnés. Un troisième critère permettra alors d'orienter les choix finaux pour le sprint à venir :

• la capacité réelle de l'équipe de développement sur la période à venir, calculée à partir de sa vélocité (le nombre de points qu'elle parvient à traiter en moyenne par sprint).

L'équipe de développement connaît mieux que quiconque sa charge de travail réelle et ses compétences techniques disponibles. S'appuyer sur cette expertise évite d'intégrer des tâches que l'équipe ne pourra pas honorer dans les délais.

L'équipe remplit ainsi le sprint jusqu'à atteindre sa vélocité maximale, sans la dépasser ni la sous-utiliser.

3. Organiser et hiérarchiser les tâches

Le point de départ reste les user stories : à partir de chacune, l'équipe identifie les tâches prioritaires, classe les autres selon leur importance, puis découpe l'ensemble en sous-tâches si nécessaire. Cette hiérarchisation les aide à savoir sur quoi se concentrer en premier, plutôt que de traiter les tâches dans un ordre arbitraire.

4. Suivre l'avancement et ajuster en continu

Pendant le sprint, un déséquilibre de charge de travail (trop ou pas assez) reste fréquent. Les mêlées quotidiennes permettent à chacun de savoir où en est le reste de l'équipe et de repérer rapidement les points de blocage. Ainsi, les membres peuvent s'entraider avant que le retard ne s'accumule.

Les outils pour gérer un sprint backlog

Le product backlog et le sprint backlog doivent vivre dans le même outil. En effet, les séparer sur deux outils différents obligerait l'équipe à dupliquer manuellement chaque élément d'un outil à l'autre. Le risque de désynchronisation devient alors réel.

• Jira pour un suivi agile poussé avec burndown chart intégré
• Notion pour une structuration flexible adaptée à une petite équipe
• Trello pour un suivi visuel simple en tableau
• ClickUp ou Monday.com pour combiner personnalisation, tâches et vues multiples

Questions fréquentes sur le sprint backlog

Le sprint backlog soulève souvent les mêmes interrogations, en particulier sur son fonctionnement au quotidien. Voici les réponses aux questions les plus courantes.