Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Quand ma liste au père Noël devient un product backlog

Quand ma liste au père Noël devient un product backlog
2014-02-052014-09-19management de projetfr
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.
Publié le 5 Février 2014 par Aurélien Morvant dans management de projet
quand ma liste au Père Noël devient un product backlog

prologue : quand l’art de prioriser devient un jeu d’enfant

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 :

  • « tout est important »,
  • « je veux tout dans le logiciel »
  • « Tout est important et indispensable à la mise en production».

Aïe ! Cela peut entrainer 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

Quand ma liste au Père Noël devient un product backlog 1Pour 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

Quand ma liste au Père Noël devient un product backlog 2Il 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 :

  • la méthode MoSCoW - acronyme de « Must, Should, Could, Won’t »
  • 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é ?

Quand ma liste au Père Noël devient un product backlog 3Nous 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 cout 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.

Quand ma liste au Père Noël devient un product backlog

A la fin de cette priorisation nous obtenons tout de même une liste d’items :

  • qui ont été remis en cause de nombreuses fois, comme dans le monde réel
  • réellement prioritaires
  • qui seront « consommés » par l’utilisateur final.

épilogue

En conclusion, si un enfant de 4 ans a réussi à entrevoir les notions de priorisation et de vélocité, pourquoi ne pourrions-nous pas y arriver également ?

Vous reconnaissez vous dans ce petit PO ? Ou bien retrouvez-vous dans cette histoire des clients, des Product Owners, qui rencontrent les mêmes soucis ? De votre côté, quelles sont vos méthodes pour prioriser ?

Quant à savoir si le père Noël a suivi la priorisation et le volume d’items embarqués, ceci est une autre histoire.

Aurélien

Crédit photo : © alphaspirit - Fotolia.com

4 Commentaires

  • 1 Mai 2015
    2015-05-01
    par
    Joanna Khoury
    C'est un article vraiment interessant! Tout les clients on des difficultes a prioritiser je crois.
    Article sympa et instructif.
    Merci
  • 25 Février 2014
    2015-05-01
    par
    Fanny
    Merci pour l'article et l'analogie: j'ai bien ri..et j'ai tout compris! Je travaille dans les études de marché et mes clients aussi veulent que leur étude réponde à toutes leurs questions, bien que la durée du questionnaire ne puisse excéder 20 min. Le MoSCoW se fait selon l'importance de l'information pour la stratégie de l'entreprise, la velocité, c'est l'impact sur la durée du questionnaire.
  • 6 Février 2014
    2015-05-01
    par

    Bonjour Cédric,

    Effectivement, c'est plus qu'une analogie.

    Selon moi, "Faire agile c'est bien, être agile c'est mieux, vivtre agile c'est ..."

    Merci pour votre feedback

  • 6 Février 2014
    2015-05-01
    par
    Cédric Bollet
    Analogie très bien vue ;) super article, merci !

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage