Un backlog produit n’est pas qu’une simple liste de tâches.
Il permet de diviser les tâches complexes en plusieurs parties, puis de les déléguer aux différents membres de l’équipe.
Si vous avez raté l’article “C’est quoi un backlog ?” cliquez ici pour plus de détails ;-)
Véritable outil central d'une gestion de projet Agile, ce n'est pas une mince affaire que de le construire et de le faire vivre.
Retrouvez ici 3 grands principes qui permettent de maitriser son sujet.
Avant tout chose, en tant que PO / PM, basez-vous sur la feuille de route produit puis les critères. Ils sont le fondement de chaque product backlog.
Tout commence par une cartographie fonctionnelle plus ou moins détaillée appelée story mapping ou customer journey map. Ce document représente le parcours de vos utilisateurs et liste l’ensemble des fonctionnalités que votre produit proposera.
Quand on regarde la Carte, en lisant les activités (postits verts) de gauche à droite, on est capable de raconter l’histoire de l’utilisateur qui va utiliser notre produit ou fonctionnalité (Flot de narration).
On peut aller dans plus de détails en lisant les user stories (post-its en jaune). Plus on descend dans la carte, et plus il y’a de détail sur l’activité.
En haut des activités, on retrouve les types des utilisateurs (postits-en bleu) ou rôles. On peut bien évidemment retrouver des rôles système, ou encore avoir deux rôles impliqués dans une même activité.
À gauche, on retrouve les résultats (outcomes) qui représenteront nos objectifs de livraisons (release).
Un point très important à souligner ici est que la priorisation se fait plutôt sur les résultats et non sur les fonctionnalités. Dans une entreprise Agile, l’objectif n’est pas de livrer le plus de fonctionnalités. Bien au contraire, le but est de livrer le minimum possible de fonctionnalités pour atteindre le résultat. Un "Bon" product owner priorise plutôt les résultats et non les fonctionnalités.
A cette étape, les éléments peuvent inclure aussi bien des éléments essentiels que des idées plus abstraites.
L’idée est de classer les tâches en fonction de leur valeur utilisateur, ou de leur urgence (entendre time to mkt).
Généralement, les tâches ayant le plus d'impact sur vos clients se voient attribuer la priorité la plus élevée. Souvent, les équipes utilisent la encore des témoignages d'utilisateurs pour comprendre quelles fonctionnalités seront les plus visibles et les plus utiles pour les clients.
Les équipes peuvent également choisir d'attribuer une priorité en fonction du besoin métier, de la complexité ou de la difficulté de mise en œuvre liée aux interdépendances entre les équipes de travail au sein d’une même entreprise.
Pour vous aider dans cette lourde tâche de priorisation, référez vous à notre article 3 méthodes de priorisation pour être plus efficace dans son product management. RICE, MoSCoW, KANO, Impact / Effort, ... plusieurs matrices vous aideront dans cet exercice
Gardez à l’esprit que les éléments prioritaires sont ceux qui sont les plus utiles aux clients et répondent à leurs attentes en conservant l’idée de progression et de satisfaction grandissante au fil des Sprints. L’objectif est bien d'obtenir une visualisation du parcours utilisateurs et de mettre en regard des activités ou fonctionnalités en regard de taches (US) à développer :
Un backlog réalisé dans les règles de l’art est un backlog estimé, et le plus précisément possible. Une bonne estimation permettra aux Product Owners d'optimiser son efficacité et son impact. C'est pourquoi elle est si importante.
Le but est de calibrer les efforts que requiert une tâche, donc le temps que va prendre son développement.
Cette estimation se fait avec les équipes techniques qui en portent la responsabilité. Pour les développeurs, c'est l'un des aspects les plus difficiles, si ce n'est le plus difficile, de leur travail. Il faut prendre en compte une kyrielle de facteurs qui permettent aux Product Owners de prendre des décisions et de prioriser les éléments.
Les estimations de complexité sont réalisées pendant la cérémonie appelée Poker Planning. Après présentation du détail des US par le PO, une valeur (entendre complexité) est donnée à chaque US et elle doit être partagée par l’ensemble de la teamDev.
Après l’ensemble de ces étapes, le PO dispose d’un backlog dit DEEP.
Détaillé, Estimé, normalement Évolutif, et Priorisé
Le PO peut utiliser pleinement son backlog et donner de la visibilité à l'ensemble des parties prenantes de la charge de travail engagée sur un sprint, le poids d’une fonctionnalité MVP ou dans sa globalité, ou d’une release, …
Le PO peut par conséquent s’engager sur un planning de réalisation réaliste et généralement une date de mise en prod respectée.
Les équipes Agile consacrent leur temps à la création de produit et font des ajustements selon l’avancement du projet. Rien n’est gravé dans le marbre, les priorisations peuvent évoluées, les DOD aussi, il doit donc être mis à jour régulièrement.
Dans la gestion de votre backlog et la planification de vos sprints, seules les User Stories prêtes sont éligibles au développement. N’ayez pas peur du syndrome du backlog vide, sélectionnez uniquement les User Stories prêtes pour votre sprint backlog permettra d’assurer la livraison et la qualité de vos développements.
Et si vous manquez d’éléments fonctionnels prêts, rappelez-vous qu’il existe également les Technical Stories, POC, Bugs, réduction de la dettes techniques (refacto) et sujets d’amélioration continue !
La communication entre les membres de l’équipe est une partie cruciale de la hiérarchisation du backlog produit. Pour réussir à faire le tri et à terminer les tâches dans un délai raisonnable, vous devez collaborer avec votre équipe et suivre la méthode Scrum.
👉 Un backlog à construire, une formation à suivre pour vous et vos équipes ? Prenez contact ci-dessous.
Abonne toi à notre newsletter pour recevoir l’essentiel de l’actualité Design toutes les deux semaines dans ta boîte mail !