.svg)
.svg)
Top 5 des bonnes pratiques pour la construction & gestion d’un Backlog
Qu'est ce qu'un backlog ?
Un backlog est un répertoire de fonctionnalités priorisées que l’on souhaite mettre en place pour un produit.
Il est l’outil principal de travail d’une équipe Scrum, et plus spécifiquement du Product Owner.
C’est une liste qui est évolutive et enrichie par de potentiels nouveaux besoins, nouvelles mises à jour ou imprévus que l’on peut retrouver au sein de n’importe quel projet.
Bien que ce soit un outil très connu dans le milieu de l’agilité, il reste parfois mal utilisé. Cet article vous propose donc les 5 étapes indispensables pour bien construire et gérer votre backlog.
1 - Définir les fonctionnalités à réaliser dans le backlog
En premier lieu, il faut indiquer les différents besoins du produit.
Lors de la rédaction d’un backlog, vous devez déterminer ce que contient votre produit, dans les grandes lignes mais également de manière plus détaillée afin que les caractéristiques du produit puissent ensuite être prises en charge par l’équipe de développement.
Pour cela, 2 catégories principales sont définies lors de l’initialisation de votre backlog :
- Une Epic c’est une catégorie qui peut être découpée en plusieurs tâches à réaliser. C’est un objectif d’action pour l’utilisateur. Ça peut représenter une fonctionnalité, une thématique, mais ce n’est pas toujours le cas. Une Epic comprend plusieurs user stories.
- Une User Story est une description simple d’un besoin utilisateur. Elle contient suffisamment de détails pour être réalisée par l’équipe de développement en un seul sprint. Si ce n’est pas le cas, elle doit être redécoupée et précisée.
Une fois que vos Epics & user stories de base sont rédigées et détaillées, une grosse étape est faite dans la construction de votre backlog.
2 - Avoir un workflow établi
Ensuite, il faut spécifier quand est ce que vous estimez qu’une user story est prête pour être prise en charge par l’équipe de développement.
Pour cela, vous devez définir en équipe votre Definition of Ready. C’est un peu la check list que l’user story va devoir respecter pour être considérée comme prête.
Par exemple on va pouvoir y retrouver le plus souvent :
- Comprise de tous
- Estimée
- Priorisée
- Contient des critères d’acceptance
- Maquette associée
- Règles métiers complètes
- Apporte de la valeur
- Réalisable en un sprint maximum
On peut y mettre tous les critères que l’on souhaite. Cette définition est propre à chaque équipe.
De plus, vous devez également rédiger en équipe votre Definition of Done. Elle peut aussi être vue comme une check list mais dans ce cas c’est ce que l’user story va devoir respecter pour être considérée comme terminée, et donc prête pour la mise en production.
Par exemple, on va pouvoir y retrouver :
- a été testée par l’équipe de réalisation avec les résultats attendus
- des tests de non régression ont été réalisés
- a été testée par au moins un membre extérieur à l’équipe de développement
- a été démontrée lors de la cérémonie associée
- la maquette a été respectée
- l’ensemble de la définition de l’user story a été prise en charge (et non qu’une partie)
- la documentation a été mise à jour
Tout comme la Definition of Ready, la Definition of Done peut comprendre tous les critères que l’on souhaite et est propre à chaque équipe.
Une fois les règles établies et claires au sein de l’équipe, il faut penser à mettre à jour son backlog.
N.B : ces deux définitions sont construites par l’équipe et peuvent tout à fait être actualisées si au fil du temps elles ne leur correspondent plus. Elles sont de leur propriété.
3 - Mettre à jour les éléments du backlog
Une autre étape indispensable pour un bon fonctionnement du backlog est sa mise à jour.
Ce n’est pas un outil figé dans le marbre, bien au contraire. Il doit être évolutif et mis à jour de manière constante.
Cela passe principalement par :
- La priorisation
L’ensemble des user stories considérées comme “Ready” doivent être priorisées au sein du backlog.
Le haut du backlog regroupe tous les éléments priorisés dans l’ordre et plus on descend dans le backlog, moins les éléments sont prêts et ordonnés.
Il faut toujours penser à mettre à jour les éléments dès qu’il y a une nouvelle hiérarchisation d’effectuée ou un changement de priorité.
- L’affinage
Lorsque l’on a un besoin, on va formuler une user story qui parfois sera trop grosse pour pouvoir être réalisée en un seul sprint. Elle devra donc être affinée et découpée en plusieurs user stories pour pouvoir respecter ce critère.
L’affinage peut être nécessaire aussi lorsqu’une user story n’est pas claire ou comprise par tous. Dès lors, le product Owner devra trouver les informations nécessaires pour la détailler et qu’elle puisse être “prête” pour la réalisation.
- L’ajout/modification/suppression
Comme un backlog est évolutif, forcément au fur et à mesure de la réalisation de nouveaux éléments seront ajoutés (nouvelles user stories, epics), les tâches déjà présentes seront quant à elles enrichies, ou encore modifiées au fur et à mesure.
Il peut arriver, dans certains cas, qu’une information devienne obsolète et dans ce cas elle doit être supprimée.
4 - Bien différencier les éléments du backlog
Au sein d’un backlog, nous avons bien les epics et user stories qui sont les éléments principaux.
En revanche, on peut en retrouver d’autres qu’il faut différencier comme :
- Les bugs
Une fois le développement produit en cours, des bugs vont être identifiés. Afin de pouvoir les traiter et les suivre, un ticket spécifique sera créé, détaillé, estimé, priorisé (comme une user story)
- Les études
Certains éléments pourront être quant à eux des études pour savoir si une fonctionnalité est réalisable par exemple. Dans ce cas ce ticket devra respecter les mêmes exigences qu’une user story et qu’un bug sauf que ce sera un élément spécifique “étude”.
- La dette technique
Enfin, élément souvent mis de côté malgré sa grande importance, la dette technique. Elle est relative à la qualité du code et son maintien. C’est souvent le résultat de ce qui n’a pas été bien réalisé auparavant ou qui n’a pas pu être réalisé.
Pour la rembourser, il faut parfois faire des tickets dédiés ayant pour but d’améliorer, petit à petit, le code en place. Cela donnera un produit plus adaptable mais surtout limitera les frais de maintenance.
5 - Suivre les avancées de l'équipe
Enfin, une fois le backlog bien rempli et tenu, il va aussi nous servir au suivi de réalisation de l’équipe.
Tout d’abord, il donne automatiquement de la visibilité à l’ensemble de l’équipe de l’avancée des tickets (en cours, en recette, terminé etc…).
Mais il permet également d’anticiper au mieux les sprints à venir.
Pour cela on va retrouver comme éléments les plus connus :
- La vélocité
C’est le nombre de story points que l’équipe peut prendre en charge pour un sprint (et terminer).
Grâce à la moyenne, qu’on pourra affiner au fur et à mesure des sprints, cela va nous servir pour anticiper les sprints à venir avec le nombre de story points et d’user stories qui y sont attachés. Cela facilitera le suivi de l’avancée et donnera de la visibilité.
- Le burndown chart
C’est une courbe facilement réalisable permettant de voir le travail restant à faire pour remplir l’objectif de sprint. La courbe est décroissante car on part du total de story points souhaité avec comme objectif d’arriver la fin du sprint.
- A l’horizontal, on retrouve les jours de sprints
- A la verticale, on retrouve le nombre de story points terminés
Ainsi, on a un suivi de l’évolution du nombre de story points terminés au fur et à mesure que le sprint avance.
- Le burnup chart
C’est exactement le même principe que le burndown chart mais avec la logique inverse.
C’est-à-dire, la courbe est croissante car on part de zéro avec comme objectif d’atteindre le nombre total de story points.
Les axes horizontaux et verticaux restent les mêmes.
Conclusion
Pour matérialiser votre backlog et le suivre, je ne peux que chaudement vous recommander d’utiliser JIRA qui est, pour moi, le meilleur sur le marché.
Il vous aidera à la catégorisation de vos éléments (Epics et user stories), leur répartition (user stories, bugs, études, dette technique), et leur priorisation en un coup d’œil.
Vous pourrez aussi ajouter, modifier, supprimer des éléments à votre guise.
Enfin, toute la partie suivi avec la vélocité, le burndown et le burnup chart est générée de manière automatique !
Et encore pleins d’autres fonctionnalités très pratiques 😉
J’espère que grâce à cet article vous pourrez désormais y voir plus clair avec votre backlog en réalisant une construction efficace et un suivi transparent.
