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 Scrum 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.
DĂ©couvrez dans cet article Comment ĂȘtre certifiĂ© Product Owner (PSPO I)..
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 Scrum.
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.
Product Backlog : Exemple
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 !