Product backlog vs Sprint backlog : quelles différences ?

Et vous,vous êtes plutôt sprint backlog ou product backlog ? Les deux, mon capitaine !

Bien que ces deux notions sont liées, elles ont aussi des différences frappantes, et ne sont pas utilisées au même moment dans le cadre des projets agiles.

Dans cet article, on va revenir rapidement sur les définitions de ces deux notions, puis les comparer en détails afin de comprendre quand et comment les utiliser.

Définitions rapides

Qu'est-ce qu'un product backlog ?

Le product backlog est une liste du travail à réaliser afin de délivrer un produit et d'atteindre le product goal. Cette liste d'éléments est hiérarchisée selon les priorités et la valeur apportée, et est gérée au quotidien par le product owner.

Contrairement à un cahier des charges comme en cycle en V, le product backlog est évolutif. Il émerge au fur et à mesure du projet, en fonction de l'apprentissage de l'équipe et de la découverte des besoins et la validation des hypothèses.

Qu'est-ce qu'un sprint backlog ?

Le sprint backlog est une liste d'éléments qui doivent être réalisés durant le sprint en cours par l'équipe de développement. Ces éléments sont tirés du product backlog en fonction de leur priorisation afin d'être développé et d'atteindre l'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.

Différences entre product backlog et sprint backlog

Bien, maintenant que l'on a vu dans les grandes lignes ce qu'est un product backlog et ce qu'est un sprint backlog, analysons maintenant ensemble les différences qui existent entre ces deux artefacts Scrum :

Comment le product backlog et le sprint backlog sont liés entre eux ?

Pour faire simple, le product backlog est en amont du sprint backlog.

1. Le product owner identifie un besoin et ajoute un ou plusieurs items dans le product backlog.
   
2. Ces items sont détaillés par le product owner, puis ordonnés selon leur valeur.
   
3. Ils sont ensuite estimés lors du planning poker par l'équipe de développement.
   
4. L'équipe de développement décide alors des éléments à intégrer dans le sprint backlog, en fonction de l'objectif de sprint qui a été défini.
   
5. Ces éléments sont alors développés afin de donner un ou plusieurs incréments en fin de sprint.
   
6. Et la boucle recommence.
   

La definition of ready, pour des user stories bien définies

La definition of ready, ou définition de prêt, est une notion controversée mais néanmoins utile, qui permet de définir les règles et bonnes pratiques dans la rédaction des éléments constituant le product backlog.

Elle n'est pas officiellement décrite dans le guide Scrum, bien qu'elle soit promu par divers grands noms de l'agilité. Elle n'est donc pas obligatoire, mais il s'agit à mon sens d'une bonne pratique à mettre en œuvre.

Elle permet ainsi de s'assurer que ces items sont suffisamment détaillés et compréhensibles par l'équipe et les parties prenantes avant de partir en développement (d'être intégrés au sprint backlog).

La definition of done, pour des incréments de qualité

La definition of done, ou définition de fini, décrit ce qu'est un travail terminé à 100%, en y incluant tous les tests et vérifications qu'il est nécessaire d'effectuer.

Tous les éléments contenus dans le sprint backlog devront respecter cette définition pour être considéré terminé à 100% et donner lieu à un incrément.

Elle permet ainsi de s'assurer de la qualité du travail fourni, de la valeur apportée au client, et permet également de limiter la dette technique (meilleure qualité = moins de bugs à corriger).

Comment gérer le product backlog efficacement ?

 Voici 6 bonnes pratiques à suivre afin de construire et de gérer un product backlog efficient.

1. Établir l'objectif du produit.
   L'objectif à atteindre avec le produit à réaliser est déterminé en amont du projet.
2. Identifier les besoins des parties prenantes.
   Le product owner travaille en partenariat avec les parties prenantes pour identifier ce dont ils ont réellement besoin.
   
3. Hiérarchiser les éléments du backlog entre eux.
   Les éléments du product backlog sont ordonnancés et priorisés selon ce qui a le plus de valeur maintenant.
   
4. Détailler les éléments prioritaires.
   Les items ayant le plus de valeur sont affinés et détaillés, puis pris par l'équipe de développement dans le sprint en cours.
   
5. Vérifier la qualité des items et ajouter des critères d'acceptation.
   Le product owner s'assure que l'équipe a toutes les informations nécessaires afin de tester son travail et de s'assurer que ça répond bien à ce qui est attendu.
   
6. Actualiser le product backlog régulièrement.
   Un backlog est vivant et dynamique, il est normal qu'il évolue constamment.
   

Comment gérer le sprint backlog efficacement ?

Voici 6 bonnes pratiques à respecter coûte que coûte pour gérer efficacement votre sprint backlog, et atteindre votre objectif de sprint.

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’amélioration 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.
   
6. Tous les éléments du sprint backlog doivent respecter la definition of done.
   ça paraît évident, mais un travail est soit terminé à 100%, soit il ne l'est pas. Il n'y a pas de quasi terminé, terminé à 99% ou que sais-je encore.