Prologue : quand l’art de prioriser devient un jeu d’enfant pour un product owner

Si vous êtes perturbé par le terme Product Backlog, voyez-le comme la liste des fonctionnalités qui constitueront le logiciel ou l’application que vous souhaitez mettre à disposition de vos utilisateurs.

• Il est fréquent pour une équipe agile de croiser le chemin de clients qui rencontrent des difficultés pour prioriser. Cela se traduit par des répliques récurrentes :
• « Si je l’ai mis, c’est que je le veux »
• « Je veux tout dans le logiciel »
• « Tout est important et indispensable à la mise en production »

Aïe ! Cela peut entraîner des tensions entre équipe et client (ou Product Owner (PO) en démarche agile) dès le départ. Cette situation est fréquente au contact des équipes agiles.

Chapitre I : sortons du contexte du travail et décollons pour prendre du recul, et quel recul

Pour illustrer mon propos, rendons nous aux antipodes de notre quotidien professionnel, mais pas si loin de nous que cela. Prenons l’exemple d’Eliott, PO de 4 ans, qui envisage la venue du Père Noël avec beaucoup d’intérêt. Ce client a la malchance d’être également mon fils, et je l’aide donc à être agile

Comme tous les clients, Eliott a créé un Product Backlog, liste des items – ici des jouets – qu’il souhaite avoir dans son produit final – ici sa chambre.

Tout comme tout bon PO qui se respecte, « tout est important ». Et c’est vrai. Au sein d’un logiciel, il est important de mettre en œuvre des fonctionnalités qui seront utilisées. Ici également le but est de challenger l’enfant sur le fait que les jouets ne finiront pas au placard.

Chapitre II : MoSCoW et Story Mapping, des outils facilitant la priorisation du product backlog

Il devient donc essentiel de prioriser. Tout ne sera pas réalisable et livrable, tout comme dans le monde réel.

Pour prioriser facilement, en tant qu’agiliste, j’affectionne :

• l’outil MoSCoW – acronyme de « Must, Should, Could, Won’t/Wish »
• associée à une Story Map qui, en début de projet, permet de prendre le recul nécessaire, sur un mur idéalement et ainsi de
• visualiser de manière multidimensionnelle son logiciel, autrement que dans un fichier sous Excel par exemple.

Ici mon PO ne parlant pas anglais et ne sachant pas lire, adaptons-nous et proposons lui une approche plus linéaire. Dans ce cas, nous classons du plus important au moins plus important – le terme « plus » n’est pas de trop, cela reste important pour tout PO.

Une fois priorisé, qu’observons-nous ? 80% des items sont dans le domaine du « DOIT être dans mon produit final ». Une efficacité de priorisation relativement faible : tout est taggué important.

Par quoi allons-nous commencer notre liste au père Noël si tout au final est important ? Comme dans le monde réel !

En effet, dans un cadre professionnel, je proposerai en complément à mon PO :

• d’identifier la valeur ajoutée apportée par chacun des items
• par la suite d’identifier SA priorisation.

Comment ?

• Sur la base d’un calcul de ROI.
• Mais également en l’aidant à se poser la question« Sur quoi est basée la valeur ajoutée ? » Des €uros rapportés ? de la qualité induite ? de la satisfaction, une ergonomie ?

Compliqué pour un enfant de 4 ans ne sachant compter que jusqu’à 10.

Chapitre III : vélocité, vous avez dit vélocité ?

Nous sommes donc directement passés à envisager que la taille de la hotte du Père Noël n’est pas extensible. Dans le monde agile, cela s’appelle la vélocité. Pour cela, nous avons identifié sur chacun des jouets du Product Backlog une notion de complexité de réalisation – ici totalement corrélée au coût d’achat. Par la suite, nous expliquons à notre PO de fils que la capacité de production du Père Noël n’est que de 20 étoiles (unité totalement arbitraire) au total. Le narrateur magnanime que je suis vous épargne une longue phase de préparation de hotte. Dans le monde réel, nous appellerions cela une itération agile.