Savoir comment créer un product backlog n’est pas donné à tout le monde, car il est facile de s’y “perdre”.
Au fur et à mesure que le temps passe et que le produit évolue, ce qui était autrefois une simple liste d’articles prioritaires devient difficile à ordonner.
Travailler à partir d’une importante liste de fonctionnalités rend la navigation dans le Backlog produit compliquée.
Vous risquez de ne plus savoir quelle US est prioritaire ou laquelle doit être re-travaillée.
Aussi, à mesure que des éléments de priorité plus élevée sont réalisés, de nouvelles tâches sont ajoutées et les éléments les plus anciens s’accumulent tout en bas de la liste.
Si vous vous reconnaissez dans ce qui a été énoncé ci-dessus, lisez cet article pour comprendre comment créer un Backlog Agile.
Vous y trouverez également, un exemple concret de processus à adopter pour garder un Backlog produit compréhensible et ordonné.
Qu’est ce qu’un Product Backlog ?
Tout d’abord, faisons un rappel de l’importance du Backlog produit dans un fonctionnement Agile.
Un Backlog produit est en quelque sorte un inventaire des fonctionnalités, des défauts ou des tâches techniques qui doivent être réalisés et ajoutés au produit final.
Le guide Scrum définit le product backlog comme étant un artefact, en plus de deux autres, à savoir :
- Le sprint backlog
- L'incrément produit
Le backlog relève de l’entière responsabilité du Product Owner.
C’est à lui de s’en occuper, de l’alimenter et de le nettoyer pour le reste de l’équipe de développement et des parties prenantes.
Dans ce processus, le Product Owner s'appuie sur la vision stratégique du Product Manager, qui oriente le développement du produit pour qu'il réponde aux attentes du marché et aux objectifs commerciaux à long terme.
Cela crée ainsi une complémentarité entre la priorisation quotidienne du PO et la planification stratégique du PM.
C’est donc le PO qui est en charge de la création du Backlog Agile et de sa maintenance.
Depuis ce Backlog Agile, des User Stories (US) vont être choisies pour être intégrées dans un autre Backlog synthétique représentant les tâches à réaliser pour le prochain sprint.
On l’appelle le Backlog de sprint.
Au sein du backlog produit les US sont priorisées, découpées ou regroupées sous des Epics.
Lorsqu’un Product Owner travaille sur la roadmap, il a besoin d’un emplacement pour y dresser la liste de toutes les fonctionnalités à implémenter sur le produit.
L’objectif du backlog produit est donc de présenter cette liste de manière claire, ordonnée et priorisée.
La priorisation des tâches étant une des notions les plus importantes de Scrum et des méthodes Agiles, le product Backlog occupe une place centrale dans la stratégie de développement d’un produit.
Voyons à présent les astuces pour créer un Backlog produit et conserver une liste de fonctionnalités épurée malgré l’accumulation des problématiques et des nouvelles idées.
Comment créer un product backlog ?
Il est très facile, en tant que PO, de mettre de côté le rangement de son Backlog de produit pour se concentrer sur des urgences, la rédaction des US ou la préparation des rituels de fin de sprint.
Cependant, c'est une tâche à ne surtout pas négliger.
Le principal conseil que je peux vous donner est de garder un créneau hebdomadaire dans votre agenda pour retravailler votre Backlog.
Voici 5 astuces que je mets en place durant cette heure consacrée à mon Backlog :
1) Classer les US dans les bonnes Epics
Le quotidien du PO est de traduire les nouveaux besoins des utilisateurs, leurs feedbacks et les défauts du produit en US.
Sous l’affluence des idées, il aura tendance à les rédiger rapidement en notant juste le titre et une phrase de description dans l’objectif de revenir dessus plus tard.
Ce n’est pas une mauvaise chose, cependant cela entraine des Backlogs très désordonnés.
En effet, le PO peut vite se perdre entre les US qui sont “prêtes” à être développées et celles qui sont encore en rédaction.
Il risque de se retrouver avec de multiple US qui ne sont pas reliées à leurs Epics.
Et c’est important pour le suivi du travail en cours et l’analyse de ce qui reste à faire que chaque US soit bien liée à son Epic :
Modèle du Product Backlog
Définissez la valeur business créée et priorisez
2) Respecter la priorité des US
Dans un Backlog produit, les US sont classées par niveau de priorité.
Si dans une réunion de brainstorming, une équipe note une vingtaine d’idées de fonctionnalités, toutes les idées ne peuvent pas être exécutées.
Il faut alors prioriser ces idées les unes par rapport aux autres afin de déterminer un plan d’action à court, moyen et long terme.
Sur ces 20 idées, 2 ont été estimées plus prioritaires que les autres.
Cependant, ces idées sont des épics qui doivent être découpées en US et tâches techniques et ensuite listées dans le Backlog.
Quant à toutes les autres épics, vous les conservez, mais vous ne pouvez pas toutes les intégrer dans votre Backlog produit.
Cela ne ferait que le surcharger et les épics estimées prioritaires seront perdues dans la masse.
Mais alors que fait-on de toutes les autres idées ?
3) Créer une liste distincte des Epics et US moins urgentes
Pour limiter votre Backlog de produit, on peut créer une liste distincte contenant des épics moins urgentes.
Ainsi, votre Backlog reste stratégique et claire.
Il va regrouper seulement les US avec un niveau de priorité élevé.
Les PO qui placent toutes les demandes, idées et tâches, dans le même backlog n’ont plus aucun endroit fiable auquel se référer pour identifier les urgences.
Cela rend l’analyse du backlog produit plus difficile. Le risque de manquer une information est aussi plus important.
Créez donc d’autres listes pour capturer les idées liées au produit.
Vous pouvez utiliser un fichier drive, un autre tableau Trello ou créer un nouveau backlog sur Jira que vous placerez sous le backlog produit.
4) Ordonner les US
Ordonner les US les plus prioritaires pour représenter votre prochain sprint.
En effet, il est important d’organiser la partie supérieure du backlog en une liste qui met en scène le contenu de la prochaine itération.
De cette façon, lorsque vous préparez le prochain sprint, vous n’avez pas à naviguer dans tout le backlog.
Un simple regard suffit pour avoir une image claire de l’objectif du prochain sprint.
Grâce à cette stratégie, les éléments les plus importants de votre backlog sont mis en exergue : Les US de « haute priorité », ainsi que leur timing associé.
En conséquence, le temps de préparation de votre rituel du sprint planning n’en sera que raccourci!
5) Réorganiser le backlog régulièrement
N'hésitez pas à supprimer toutes les US ou tâches immobiles depuis 6 mois.
Le nettoyage du backlog permet de :
- Conserver sa qualité et son objectif ;
- Garantir que vous développez le bon produit de la bonne manière ;
- S’assurer que le backlog du produit est fonctionnel et qu’il y a suffisamment d’éléments prêts pour démarrer le prochain sprint.
Il est conseillé, au moins une fois par Sprint/itération, d'organiser un backlog refinement durant lequel il est possible de revoir les priorités, et de spécifier en détail les besoins à embarquer et préparer les prérequis nécessaires à leur développement.
Le Backlog Refinement se tient entre les rôles métiers et techniques de la Squad agile.
Exemple : L'organisation d'un backlog en pratique
Ce que j’ai décrit jusqu’à présent n’est pas seulement théorique.
Vous pouvez configurer votre propre workflow pour une bonne gestion du Backlog Agile.
En voici un exemple de ce processus :
En général, en tant que Product Owner, je me repose sur 4 différents supports :
- La roadmap : elle représente les Epics sur lesquelles l’équipe travaillera au cours des 2 à 3 prochains trimestres.
- Les Epics : elles regroupent des listes d’US découpées sur lesquelles l’équipe travaille au cours du trimestre en cours.
- Un support de management visuel (Scrumboard ou Kanban) : Il contient le workflow de développement et permet de visualiser les US dans les différentes étapes du développement.
- Un bac à sable : C’est ainsi que j’appelle la liste dédiée aux Epics moins urgentes. J’y conserve toutes les suggestions, demandes et idées que nous recevons.
Le processus est donc comme suit :
- En premier lieu, je pense à mettre à jour les roadmaps à mesure que les priorités changent.
- Ensuite, je vérifie dans le bac à sable s’il y a des idées à valider et éventuellement à inclure dans la roadmap.
- Si une Epic devient prioritaire, je la sors du bac à sable pour l’ajouter dans le backlog produit.
- Si son niveau de priorité change et demande à ce qu’elle soit ajoutée dans les deux prochains sprints, je vais la découper puis créer et ajouter les US associées.
- Je vais remonter les US que je souhaite développer dans la prochaine itération tout en haut du Backlog pour qu’elles soient visibles lors de mes préparations du Sprint Planning.
- Toute US ou Epic qui reste au même endroit pendant plus de 6 mois environ, est supprimée ou envoyée au bac à sable.
- Je continue à peaufiner ce processus au fil du temps.
Il s’est avéré être une solution solide sur laquelle je peux m’appuyer pour organiser un Backlog Agile.
Conclusion
Vous savez maintenant comment créer un product backlog.
En tant que Product Owner, la maintenance du backlog produit est une étape majeure dans la gestion et le développement d’un produit à forte valeur ajoutée.
En suivant un processus étapes par étapes, je peux vous garantir que plus personne n’aura peur d’aller y jeter un coup d’œil.
Si vous avez votre propre processus de rangement du backlog produit, n’hésitez pas à me l’expliquer en commentaire ou à me dire comment améliorer le mien !
Merci pour cet article !