Le product Backlog (= PBL) : mais qu’est ce que c’est que ça ? 

Chaque Product Owner pourrait donner sa propre définition du product backlog mais la mienne est la suivante :

le product backlog est une liste ordonnées des futures fonctionnalités que je souhaite un jour voir en production pour mon produit. Appelons ces futures fonctionnalités des “items”.

Par définition un PBL ne contient que des items qui ne sont pas encore développés.

Les différents items qui composent un product backlog représentent au choix : 

• des nouvelles fonctionnalités,
• des améliorations de fonctionnalités déjà existantes,
• des tâches techniques*.

*et oui, il est tout à fait possible de voir également dans un PBL des items correspondant à des tâches techniques comme par exemple : “refonte de la charte graphique de l’appli mobile” ou alors “migration du backend toto vers la version 1.67” par exemple.

La règle communément admise étant tout de même de se confectionner un PBL avec des items de taille similaire (au moins fonctionnellement parlant car on découvre parfois des surprises sur la taille des items après leurs macros-chiffrages par l’équipe de développement, mais j’y viens plus tard).

Il existe pas mal d’outils pour faire de la gestion de backlog, personnellement j’ai travaillé avec la doublette magique Jira/Confluence et AzureDevOps (ex TFS) mais je suis sûr que vous trouverez votre bonheur parmi toutes les solutions du marché. 

En tant que PO sur quoi qui puis-je m’appuyer pour m’aider à créer mon PBL ?

Généralement si vous êtes Product Owner c’est que quelqu’un vous a demandé de l’être (directement ou non mais vous n’êtes pas arrivé là par hasard). 

Cette personne est généralement appelée le métier, le sponsor (ou la MOA ou le stakeholder et j’en passe et des meilleurs) de votre produit. 

Devinez quoi ? C’est lui qui va vous donner les items de votre backlog.

La première chose à dire concernant les items constituant un PBL va vous sembler évidente mais il est parfois bon d’enfoncer des portes ouvertes (comme on dit pas chez moi 😂) : un PBL ne doit contenir que des éléments qui ont de la valeur pour votre produit.

Les tâches techniques, les POCs et autres spikes peuvent également être ajoutés à un PBL car bien qu’ils n’apportent pas de valeur directement à l’utilisateur, ils vont participer à améliorer la qualité du produit et à réduire les risques d’incident sur le long terme.

J’aborde dans d’autres articles du blog, mes techniques de recueil de besoin. 

Sachez que pour constituer votre PBL vous allez avoir besoin de réaliser un certain nombre d’ateliers avec le métier afin de récupérer : 

• la “roadmap” du produit avec les dates clés et les jalons à respecter,
• éventuellement un pré-découpage en version déjà effectué par un PM,
• les fonctionnalités de base de votre produit (les “must-have”) sans quoi rien ne sera possible (ex : une brique d’authentification),
• les fonctionnalités que l’on veut développer absolument mais qui ne peuvent pas venir sans les fondations (les “should-have”) par exemple “envoyer une notification push pour chaque but marqué par mon équipe favorite”, 
• les fonctionnalités que l’on aimerait avoir à moyen terme (les “nice-to-have”) par exemple “pouvoir personnaliser le texte de mes notifications pour rester discret au travail”.

Muscler sont PBL avec le métier

Des ateliers au cours desquels on construit son product backlog, ne doit pas être un jeu de questions/réponses entre un PO et un PM.

Au contraire le Product Owner est là pour comprendre où veut aller le PM, le challenger sur le maximum de choses pour qu’ensemble ils sachent où le produit ira.

Le Product Manager doit être à l’écoute de son Product Owner pour que celui-ci puisse prendre possession du produit et s’investir à 100% dans sa création.

Il est inutile dans ce genre d’atelier d’aborder des sujets qui viendront à être développer dans trop longtemps : le besoin aura le temps d’évoluer 10 fois et le fait d’aborder maintenant un sujet trop flou n’aura aucune utilité concrète mise à part celle de faire traîner une réunion 20 minutes supplémentaires.

Mes deux principaux conseils lors d’ateliers de constitution d’un PBL pour un Product Owner sont les suivants :

• Timeboxer l’exercice : 1h30 maximum (à répéter jusqu’à avoir une roadmap sur 6 mois par exemple)

• S’efforcer de “penser version” c’est à dire regrouper au maximum au cours de l‘atelier les items devant fonctionner ensemble en une version cohérente

En définitive, une fois que vous avez mené vos X ateliers avec le métier et que vous avez compris et déterminé avec le PM la valeur de chaque fonctionnalité, vous devez être en mesure de pouvoir présenter un premier draft de votre PBL tel que ci-dessous :

Note : La valeur d’un item est quelque chose d’arbitraire c’est à dire qu’à un instant t le PO et le PM se sont mis d’accord sur un certain poids mais il arrive qu’ils se trompent (et oui ça arrive). Dans ce cas là, les retours utilisateurs montreront que la fonctionnalité n’est pas ou peu utilisée et la business value de cet item sera mise à jour par le PO dans le PBL.

Attention, la valeur d’une fonctionnalité ne désigne pas sa priorité. Pour savoir comment prioriser les items de votre backlog la réponse se trouve dans le chapitre ci-dessous.

Comment prioriser les items de son Backlog ?

Il existe de nombreuses manières de prioriser les items de son backlog pour un Product Owner (MMF etc…)

Toutefois il faut bien garder en tête que le plus important dans le rôle d’un product Owner et la gestion de son product backlog réside dans le fait de savoir en permanence où en est son produit à l’instant t et où il va aller à à t+1.

D’ailleurs pourquoi demande-t-on à un PO de prioriser son backlog ?

A mon sens c’est avant tout pour qu’il sache en permanence où il en est et où il veut aller, comme un capitaine sur un bateau en quelque sorte.

Imaginez que vous croisiez votre N+3 à la cafét’ à midi, sauriez-vous lui répondre la date prévisionnelle de sortie de la feature “de notifications push tant attendue dont il a justement parlé avec le DG lors de sa partie de golf de dimanche” en moins de 10 secondes de réflexion ? 

Le bon PO, oui 🙂 car il connaît son backlog, il connaît les items en cours de développement (et éventuellement le retard accumulé), il connaît les items au programme du prochain sprint de son PBL, il connaît le temps de latence moyen entre un développement DONE est une mise en production et il peut donc répondre à +/- 2 semaine, une date réaliste hors imprévus.  

Et ça, le N+3 il kiffe.

Je donne ci-dessous ma technique de priorisation d’un PBL, elle est certainement perfectible, n’hésitez pas à commenter mon article pour me donner votre technique de priorisation de backlog #ameliorationcontinue ;). 

Imaginons que j’ai déjà une liste de X items constituant mon PBL, chaque item possède : 

• Une valeur (en agile on nomme ceci la business value) relative par rapport à ses voisins (voir chapitre précédent), 
• Une version cible
• Une taille similaire et convenable à mes yeux 

Maintenant comment je priorise tout ça ? 

L’exercice de priorisation en tant que tel est plutôt complexe, il n’existe pas de “formule magique” et rien ne vous garantie que ce qui a marché une seule vaudra pour la suivante.

Pour pouvoir bien prioriser les items de son PBL le PO a bien de connaître pour chaque item : 

• La business  value, 
• La complexité*,
• Le risque (est-ce que sans cet item mon produit est en risque ?) 

*Pour tout savoir sur la complexité d’un item du PBL, je vous invite à lire l’article suivant.

Une fois ces 3 informations en sa possession il est possible de déterminer la priorité d’une fonctionnalité en faisant le rapport de sa business value sur sa complexité.

Par exemple : 

Fonctionnalité d’authentification : BV=100 // Complexité = 30 jH // Risque : niveau le plus haut Poids de la priorisation = 3.33 (+ risque max)

Fonctionnalité de personnalisation d’une notif push : BV : 5 // Complexité = 3 jH // Risque: nul 

Poids de la priorisation = 1.66 (pas de risque)

Au regard de toutes ces informations et en gérant au mieux les dépendances, le product Owner est normalement maintenant capable de générer un PBL de ce type : 

insérer ici une maquette de PBL avec des items ordonnés par versions et priorisés.

La vie est parfois…cruelle

Un Product Owner pourra mettre toute l’énergie qu’il peut pour prioriser de la meilleure des manières son PBL il faut garder à l’esprit que dans “la vraie vie” une demande du top management passera toujours en top priorité. 

Bien souvent, un des rôles de PO sera donc de savoir jongler entre son product backlog et les demandes externes non-initialement “prévues”. Comme dans la vraie vie en quelques sorte 😉

Conclusion

Clé de voûte de la méthode Scrum, le Product Backlog qui est partagé avec l’ensemble des parties prenantes interagissant avec le produit, est l’outil principal du product Owner. 

En perpétuelle évolution, le PBL reflète la roadmap à l’instant t du produit en cours de construction. Il donne des indications sur les différentes fonctionnalités attendues dans chaque version ainsi que des précisions sur les dates espérées de livraisons.

Je conseille à chaque PO de faire de son PBL sa boussole lui permettant de toujours garder le cap vers le plus important : fabriquer des fonctionnalités pertinentes pour les utilisateurs.