Sprint backlog

sprint backlog
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.

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.

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 518 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]

2 Rétroliens / Pings

  1. Scrum : bien le comprendre - My Agile Partner Scrum
  2. Scrum exercice corrigé - My Agile Partner Scrum

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.