Qu’est-ce qu’un sprint backlog et comment l’utiliser ?

Thibault Baheux

25 novembre 2022 - minutes de lecture

Vous êtes convaincu par les promesses de la gestion de projet agile, mais les termes en anglais tels que le sprint backlog vous rebute.

Je vous comprends... Pour maîtriser Scrum, il y a du jargon à connaître sur le bout des doigts. 

Le guide Scrum étant volontairement light, et laissant la place à l'interprétation, on peut vite se sentir perdu à la lecture de tous ces termes différents.

Dans cet article, je vous explique tout ce que vous avez besoin de savoir sur la notion de sprint backlog, qui est une notion importante en Scrum et en gestion de projet agile.

Qu'est-ce qu'un sprint backlog ?

Le sprint backlog est un artefact Scrum définit lors du sprint planning, qui représente l'ensemble des éléments à réaliser durant le sprint ainsi que le plan d'action pour atteindre l'objectif de sprint et livrer l'incrément à la fin du sprint.

Pour cela, l'équipe de développement prend des éléments du Product Backlog pour les insérer dans le Sprint Backlog pour tenter de répondre à un objectif de sprint.

Le sprint backlog est définit lors de la sprint planning et se termine lors de la sprint review, à la fin d'un sprint. La durée de vie d'un sprint backlog n'est donc que d'un seul sprint.

Le sprint backlog doit être transparent et dynamique :

  • Transparent
    Le sprint backlog est transparent. Le contenu du sprint et son avancement doit être consultable par toute personne, membre de l'équipe Scrum ou non. Le management visuel est donc fortement privilégié.
  • Dynamique
    Le sprint backlog est dynamique  et peut évoluer en cours de sprint. C'est plus une prévision de ce qu'on souhaite réaliser durant le sprint et de l'incrément qu'on aimerait avoir à la fin, qu'un engagement fixe.

Sprint backlog vs Sprint

Un sprint est une itération courte de 1 à 4 semaines donnant lieu à un incrément. Ce mode de travail en cycles courts est au coeur de l'agilité. Le sprint backlog constitue la somme des éléments à traiter durant le sprint ainsi que le plan d'action pour y arriver.

Ces deux notions sont intrinsèquement liées : il ne peut y avoir de sprint sans sprint backlog, et inversement.

Pour aller + loin : J'explique dans cet article en détails ce qu'est un sprint agile, et tout ce qu'il y a à savoir autour de cette notion primordiale.

Sprint backlog vs Sprint planning

Le sprint backlog constitue la somme des éléments à traiter durant le sprint ainsi que le plan d'action pour y arriver. Il est définit lors d'un évènement Scrum qui marque le début d'un sprint, nommé sprint planning.

La cérémonie du sprint planning permet ainsi de définir l'objectif du sprint, le travail à réaliser durant le sprint (les fameuses user stories), ainsi que le plan d'action à suivre pour atteindre l'objectif de sprint.

Pour aller + loin : Découvrez dans cet article la cérémonie Scrum du Sprint planning, et ce que cela implique.

Sprint backlog vs Product backlog

Le product backlog est une liste des fonctionnalités à développer afin de réaliser le produit. Il est tenu, organisé et priorisé par le Product Owner.

Le sprint backlog est un backlog spécifique à un sprint, qui contient une portion des éléments du product backlog. Ces éléments seront ensuite réalisés lors des prochaines semaines pendant le sprint en cours.

Backlog de sprint vs Objectif de sprint

L'objectif du sprint est fixé en début de sprint lors du sprint planning, et ne bouge plus. L'équipe de développement ajoute des éléments à développer au sprint backlog lors du sprint planning puis en cours de sprint afin de tenir cet objectif.

Il est important de ne pas confondre ces deux notions, certes liées mais bien différentes.

Le Scrum Guide est d'ailleurs très clair sur le sujet de l'objectif de sprint :

L'objectif du sprint est fixe, les changements qui le remettent en cause ne sont pas permis.

Le périmètre du sprint (le sprint backlog) peut être clarifié et renégocié entre le product owner et l'équipe de développement selon ce que l'équipe Scrum apprend.

Le sprint backlog correspond quant à lui à un engagement pour réussir à atteindre l'objectif préalablement fixé.

Au fur et à mesure de l'apprentissage de l'équipe, elle peut décider d'ajouter des éléments au sprint backlog ou au contraire supprimer les éléments obsolètes, sans que cela remette en cause ni l'objectif, ni le sprint en lui-même.

Qui est responsable du sprint backlog ?

L'équipe de développement est responsable à 100% du sprint backlog, de sa mise à jour, et du reporting d'avancement du sprint backlog.

L'équipe de développement décide en fonction de l'objectif à atteindre des éléments du product backlog à intégrer au sprint backlog.

Elle est également responsable de la mise à jour de ce sprint backlog, soit en ajoutant les éléments nécessaires pour atteindre l'objectif de sprint, soit en supprimant les éléments obsolètes qui n'ont plus lieu d'être.

Enfin, l'équipe de développement est également responsable à 100% du reporting concernant le sprint backlog. Ce n'est ni au product owner ni au scrum master de réaliser cette action, mais bien à l'équipe de développement.

Et le scrum master dans tout ça ?

Contrairement à ce qu'on voit fleurir un peu partout sur le net, il n'a pas son mot à dire sur le contenu du sprint backlog. Il peut cependant conseiller et coacher l'équipe sur les bonnes pratiques liées à Scrum.

Quand créer un backlog de sprint ?

Un sprint backlog est créé lors de la sprint planning par l'équipe de développement, et dure jusqu'à la sprint review. La régularité de ces évènements Scrum dépend de la durée de vos sprints : entre 1 à 4 semaines.

Le sprint planning est un évènement qui a lieu au début de chaque sprint, et qui permet de planifier le sprint en cours.

C'est l'occasion pour l'équipe de développement de tirer des éléments du product backlog afin de les intégrer au sprint backlog. Elle réfléchit également au plan d'action à mettre en œuvre afin d'atteindre l'objectif de sprint.

Le sprint review est un évènement qui a lieu à la fin de chaque sprint. C'est l'occasion pour l'équipe de montrer le travail accompli aux parties prenantes du projet et de recueillir du feedback.

Quels éléments inclure dans un backlog de sprint ?

L'équipe de développement peut décider d'inclure n'importe quel élément (user story) du product backlog dans le sprint backlog, à une condition :

  • Que cet élément permette d'atteindre l'objectif de sprint défini avec le Product Owner.

L'équipe est ensuite libre durant le sprint d'ajouter autant d'éléments que nécessaire dans le sprint backlog afin d'atteindre l'objectif de sprint.

Si l'objectif de sprint est en danger, l'équipe de développement doit impérativement interpeler le product owner sur le sujet.

Peut-on faire évoluer le sprint backlog une fois le sprint démarré ?

Le sprint backlog est un élément dynamique, qui peut et doit évoluer en cours de sprint. L'équipe de développement est libre d'ajouter ou de supprimer des éléments dans le sprint backlog afin d'atteindre l'objectif de sprint.

Le Scrum Guide est clair sur le sujet : c'est sans équivoque.

Ll'équipe de développement modifie le backlog de sprint tout au long du sprint.

Le sprint backlog émerge durant le sprint.

A mesure que du nouveau travail est nécessaire, l'équipe de développement l'ajoute au backlog de sprint.

Bien que l'équipe de développement peut modifier le sprint backlog comme elle le souhaite, j'aimerais insister sur un point qui me semble important.

Non, on ne devrait jamais modifier un sprint en cours parce que le client souhaite une fonctionnalité en urgence. Les modifications doivent toujours être faite pour l’atteinte de l’objectif du sprint Ou pour une urgence réelle (comme un bug qui rend une fonctionnalité indisponible).

Si ces modifications mettent en danger l'objectif du sprint, l'équipe de développement doit impérativement interpeler le product owner sur le sujet.

Est-ce qu'on peut annuler un sprint backlog ?

Il n'est pas possible d'annuler un sprint backlog en cours de sprint, et il n'y a pas d'intérêt. En effet, l'équipe de développement peut le modifier comme elle le souhaite durant le sprint, tant que ces modifications permettent d'atteindre l'objectif de sprint.

Cependant, si le sprint est annulé, le sprint backlog l'est également. L'équipe de développement décide alors avec le product owner quoi faire des éléments :

  • Faut-il les réintégrer dans le product backlog, afin de les traiter sur un sprint ultérieur ?
  • Faut-il les affiner et les retravailler ?
  • Ou faut-il les supprimer purement et simplement ?

La réponse diffèrera en fonction de la situation et du contexte.

Que se passe t-il si tous les éléments ne sont pas terminés à la fin du sprint ?

A la fin du sprint, si certains éléments du sprint backlog ne sont pas terminés, l'équipe de développement peut décider de les reporter sur les sprints suivants. La décision doit s'effectuer au cas par cas, et elle n'est en rien obligatoire.

L'équipe peut également décider de supprimer ces éléments du backlog, si elle juge qu'ils sont obsolètes.

Comment mesurer l'état d'avancement du sprint backlog ?

L'état d'avancement du sprint backlog est mesuré par l'équipe de développement généralement via deux outils : la burnup chart et la burndown chart.

  • La burnup chart.
    Elle permet d'analyser l'avancement du travail réalisé sur une période donnée par rapport à la globalité du travail prévu.
  • La burndown chart.
    Elle permet de visualiser le travail fini sur un sprint, en respectant la definition of done, et permet d'estimer l'avance ou le retard dont dispose l'équipe.
exemple burnup chart

Exemple de Burnup chart

exemple burndown chart

Exemple de Burndown chart

Quel outil pour gérer un sprint backlog ?

Pour une équipe en présentiel, il est recommandé d'utiliser un scrumboard sur un mur afin de représenter visuellement le sprint backlog. Pour une équipe à distance, il est recommandé d'utiliser un logiciel de management visuel tel que Trello, Jira ou équivalent.

La clé d'un bon outil pour gérer le sprint backlog est le management visuel. Cela permet à toute personne de voir d'un coup d'oeil quels sont les éléments intégrés au sprint backlog, et où en est l'équipe.

Le management visuel permet ainsi d'ajouter de la transparence au sprint backlog, qui est une notion chère à Scrum.

Bonnes pratiques pour créer un backlog de sprint

Vous l'avez compris, le contenu d'un backlog de sprint évolue fortement en fonction de l'objectif du sprint qui est fixé.

Il existe toutefois quelques bonnes pratiques à respecter afin de créer un backlog de sprint efficace :

  1. Tous les éléments n'ont pas à respecter la definition of ready.
    Bien que cette définition explique ce qu'est une user story de qualité, ce n'est pas un prérequis pour intégrer les éléments au sprint backlog. Ils peuvent être affinés ultérieurement en cours de sprint.
  2. Le plan n'a pas à être détaillé à 100%.
    C'est même recommandé de ne pas trop le détailler. Il peut évoluer en cours de route. Vous aurez tout le temps de l'approfondir lors des prochaines journées.
  3. Ne pas zapper la dette technique.
    Les bugs peuvent s'accumuler au fur et à mesure des sprints et des incréments. Il est recommandé de ne pas trop attendre pour les traiter. Incluez donc la résolution des bugs les plus impactants dans votre sprint backlog.
  4. Intégrer au moins 1 axe d'émalioration décidé en rétrospective.
    Cela vous assurera que l'amélioration continue est bien prise en compte par l'équipe.
  5. Privilégier le management visuel.
    Vous pouvez utiliser un outil numérique ou un scrum board physique afin d'apporter visibilité et transparence à votre sprint backlog. 

Thibault Baheux

Tour à tour chef de projet puis manager d'équipe depuis 2008, je suis aujourd'hui directeur de projet indépendant.

J'ai décidé via ce site de démocratiser la gestion de projets et de la rendre accessible à tous.

Mes certifications : Prince2 Foundation, CompTIA Project+ certified, PSM1, Lean Six Sigma Yellow Belt.


Articles Similaires


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}