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

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, préalablement défini avec le product owner.

Le backlog de sprint représente ainsi le travail à réaliser dans le sprint en cours. Il peut inclure des fonctionnalités, des user stories, des bugs à corriger, des améliorations à apporter, etc...

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.

On vient de le voir, le sprint backlog peut et doit évoluer en cours de sprint. En effet, il reflète le plan d'action de l'équipe Scrum pour atteindre l'objectif de sprint, plan d'action qui évolue et s'affine en cours de route.

Vous pouvez très bien enlever ou ajouter des items dans le sprint backlog, à tout moment pendant le sprint, mais à une condition très importante : les éléments ajoutés doivent être en relation avec l'objectif de sprint.

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 cœur de l'agilité. Le sprint backlog constitue la somme des éléments à traiter durant un sprint ainsi que le plan d'action pour y arriver et atteindre l'objectif de sprint.

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

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.

Sprint backlog vs Product backlog

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.

Le product backlog représente quant à lui la somme du travail à réaliser, priorisé par importance, pour développer le produit final. Les éléments du backlog de produit peuvent représenter le travail de plusieurs sprints futurs.

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 :

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.

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.

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.
  

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.