Sprint backlog

Le sprint backlog est l’ensemble des items qui ont été sélectionnés en début de sprint afin de les réaliser pendant le sprint.

Vous pouvez regarder la vidéo de la minute agile sur le sujet :

Définition du Sprint backlog

Comme je l’expliquais en introduction de cet article, le sprint backlog constitue l’ensemble des éléments qui ont été sélectionnés en démarrage de sprint (en sprint planning) avec pour but :

• de répondre à l’objectif du sprint
• d’incrémenter le produit de nouvelles choses :
  • de nouvelles fonctionnalités
  • des pré-requis
  • de nouvelles fonctions
  • des fixes
  • des améliorations
• le plan pour livrer les éléments sélectionnés (sous-tâches techniques, priorisation…)

En effet, certaines équipes oublient d’y insérer le plan pour livrer les différents items de celui-ci.

Les équipes de développement vont créer un nouveau sprint backlog à chaque sprint planning. En effet, le product owner n’est pas responsable ou propriétaire de celui-ci.

Le scope défini reste prévisionnel

Le sprint backlog reste une « prévision » et ne peut amener à des sanctions si en fin de sprint, son contenu n’est pas livré dans un environnement stable.

Si l’équipe de développement n’arrive pas à atteindre l’objectif du sprint, elle profitera de la sprint review pour en analyser les raisons.

Les particularités à connaitre

Sprint backlog toujours en amélioration continue

Chaque nouveau sprint backlog doit être amélioré par un des axes d’amélioration défini lors de la précédente sprint rétrospective. Cet artefact est l’un des éléments les plus importants de l’amélioration continue amené par scrum.

Le sprint backlog a un scope variable

Bien que le sprint backlog est défini en début de sprint, il continue d’évoluer tout au long du sprint. Les équipes peuvent ajouter des éléments, en modifier voire en supprimer selon leurs découvertes.

D’ailleurs, son plan peut également changer tout au long du sprint pour prendre en compte les dernières explorations de l’équipe de développement.

Voici quelques éléments possibles pouvant venir s’y greffer :

• nouvelle sous-tâche technique (d’un item)
• un spike pour faire des recherches
• des cas de tests oubliés (fonctionnels/techniques)
• …

La variation du contenu et de son plan doivent toujours prendre en considération l’objectif du sprint à atteindre.

Les estimations du travail restant

Le scrum guide rappelle l’importance de mettre à jour le travail restant sur chaque item quand l’équipe de développement a réalisé des travaux dessus (même non terminés).

Un artefact qui prône la transparence et le temps réel

Bien que le scrum ne précise pas la nature de la transparence à avoir, le sprint backlog doit être visible par tous. L’équipe de développement sera responsable de celui-ci et devra le maintenir en temps réel ; en effet, cette maintenance en temps-réel permettra d’avoir une meilleure transparence sur le travail de l’équipe.

L’équipe de développement devra au minimum une fois par jour (potentiellement à la daily sprint), calculer le travail restant à réaliser afin d’avoir une bonne vision du parcours restant pour atteindre l’objectif du sprint.

Les équipes scrum utilisent généralement le burndown chart pour effectuer ce travail.