Auteurs : Clément Pinteur, Amine JBILOU

Dans le cadre de la conception d’un produit, le Product Owner est souvent amené à entreprendre un exercice de priorisation des fonctionnalités avec ses parties prenantes. C’est un exercice qui peut s’avérer difficile surtout en début de projet lorsque les parties prenantes voient de la valeur dans toutes les idées de nouvelles fonctionnalités. 

L’un des outils les plus efficaces pour les aider à prendre conscience de l’importance de la notion de priorisation dans la vie d’un produit, est un atelier appelé Buy a feature (achètes une fonctionnalité, en français), avec un crédo : « Choisir c’est renoncer ». 

Suite à la mise en œuvre de cet atelier lors de la phase de sprint 0 du projet Know Your Risk (MESARI) chez CACD2, nous avons souhaité faire ce retour d’expérience pour partager les clefs de réussite et les pièges à éviter. 

Plusieurs variantes du Buy a feature peuvent être utilisées en fonction du contexte. Nous vous présenterons ici notre expérience de cet atelier. 

 

Pré-requis 

Afin de mener à bien cet atelier, il est impératif d’avoir d’ores et déjà les premières fonctionnalités en votre possession. Si vous avez réalisé un atelier d’Impact Mapping, c’est le moment de réutiliser les fonctionnalités que vous aviez identifié. 

Afin de simplifier la priorisation, une première estimation de la complexité peut être envisagée en amont, sans qu’il soit nécessaire d’être très fin à ce stade (par exemple utiliser les tailles de t-shirt : S – M – L) 

Logistique  

Si possible, invitez un nombre raisonnable de participants afin de faciliter les échanges. Si vous avez trop de monde, vous pouvez toujours scinder les groupes en fonction des acteurs identifiés sur le produit (sur notre projet, 3 groupes de 4 personnes). 

En fonction du nombre de participants et fonctionnalités à traiter, prévoyez 2 à 3 heures d’atelier.  

Prévoyez l’impression de faux billets (pas de copie de véritables euros bien sûr 😉, vous trouverez ci-dessous un lien vers un template de planches à billets), essayez d’avoir des coupures variées, allant d’un petit à un gros montant (ex : 1 à 500).  

Pour notre exercice nous avions choisi la répartition suivante pour un total de 2 000€ : 

  • 2 billets de 500 
  • 2 billets de 200 
  • 3 billets de 100 
  • 5 billets de 50 
  • 2 billets de 20 
  • 10 billets de 1 

Déroulé

Premier round d’enchères :

  • Tous les billets doivent disparaitre
  • Une personne peut mettre tous ces billets sur une fonctionnalité…
  • … tant que toutes les fonctionnalités ont un prix à la fin de l’atelier

Ces 3 règles poussent naturellement les acteurs à se parler, à échanger leurs objectifs, leurs problématiques mais surtout à comprendre celle des autres (ex : acteur Marketing vs acteur Juridique)

Deuxième tour d’enchères :

A la fin du premier round, les mises placées sur les fonctionnalités correspondent au prix d’achat.

Par exemple, si 1 000€ ont été placés sur la fonctionnalité A, et 1€ sur la B, il faudra dépenser 1 000€ pour acheter la A et 1€ pour acheter la B.

Si l’achat de fonctionnalités n’avait pas vraiment d’enjeux sur le premier round car les personnes peuvent théoriquement tout acheter, ils auront besoin ici de l’aide du reste des personnes présentes.

Désormais :

  • Les parties prenantes se voient retirer la moitié de leur capital de départ
  • Ils doivent acheter les fonctionnalités présentes en respectant le prix fixé au round précédent

A la fin de cet exercice, vous aurez non seulement une liste de fonctionnalités, mais en plus priorisée par les parties prenantes les plus engagées sur la réussite du produit.

Pour notre exercice nous avions choisi la répartition suivante pour un total de 1010 :

  • 1 billets de 500
  • 1 billets de 200
  • 1 billets de 100
  • 2 billets de 50
  • 5 billets de 20
  • 10 billets de 1

Enfin, et afin de garantir la réussite de cet exercice, il ne faut pas omettre de faire attention à certains aspects.

Ainsi, lorsqu’on a fait l’exercice, un groupe n’a pas pensé au deuxième tour et a fixé des prix très élevés sur les fonctionnalités. A la fin ils n’ont pu acheter que peu de fonctionnalités par rapport aux autres.

Par ailleurs, un nombre de participants important peut augmenter la complexité de l’exercice. Soyez sûr que les personnes invitées disposent vraiment d’une marge de manœuvre pour décider de garder une fonctionnalité ou pas (par exemple votre Product manager ou encore le Sponsor du produit).

Aussi, il faut bien noter que ce type d’atelier donne des grandes orientations, et certainement pas une priorisation précise. Cette dernière se fait au fur et à mesure lors des sessions de Backlog Grooming

Encore une fois, ce modèle n’est pas forcément applicable à tous les contextes, n’hésitez pas à l’adapter. Il peut être par exemple intéressant de faire une répartition proportionnelle au niveau de décision des acteurs (par exemple plus de poids pour le Sponsor ou la PM que pour les autres) afin d’éviter une validation supplémentaire à la sortie de l’atelier.

 

Comme énoncé en début d’article, le crédo « Choisir c’est renoncer » reste le maître mot de ce type d’exercice. Il a aussi pour bénéfice de mettre les parties prenantes face à leurs responsabilités, notamment en termes d’orientation des choix budgétaires et de priorisation des fonctionnalités.