Publié par
Il y a 3 années · 8 minutes · Agile

Les différents usages de Buy a Feature

Buy a Feature est l’un des ateliers phares du corpus des Innovation Games®. Le principe de cet atelier est simple et très engageant, il s’agit de proposer aux participants d’acheter des fonctionnalités en disposant d’un montant d’argent limité.

Pour rappel, les Innovation Games® sont des formats d’ateliers de travail avec une forme prescriptive, souvent ludique, et qui laissent une large place aux échanges de fond sur un produit ou un service. Pour simplifier, on peut dire que ce sont des formats de brainstorming semi-directifs. Initialement destinés au domaine du marketing et de l’exploration de marchés, ces ateliers sont également utilisés dans des cadres bien différents. On en retrouve, par exemple, pour faciliter des rétrospectives agiles de sprints, pour des cadrages de projets ou encore dans la réflexion de transformations organisationnelles.

Je vous propose dans ce billet de revenir à l’utilité première des Innovation Games®, la collecte de la voix des utilisateurs, avec un focus sur l’atelier Buy a Feature.

Buy a Feature

L’atelier fait partie des moins ouverts en termes de créativité puisqu’il nécessite de fournir une liste de fonctionnalités à acheter avec un prix prédéfini. On laisse donc peu de place à l’imagination des participants, le moteur de l’atelier va se jouer sur la dynamique de négociation entre participants, car aucun ne dispose de suffisamment d’argent pour acheter les fonctionnalités qu’il souhaite.

L’atelier se révèle un bon format pour un Product Owner ou un Product Manager qui souhaitent recueillir de façon rapide des éléments structurants de la part des utilisateurs ou des parties prenantes, afin de prendre une décision de priorité. La portée de cette décision peut être de différentes natures : cherche-t-on à réduire un périmètre pour un budget contraint, ou bien à choisir une option de fonctionnalité, ou encore envisager le futur du produit. Avant d’organiser un tel atelier, il s’agira donc pour l’organisateur de bien définir la question à laquelle il souhaite une réponse, cela conditionnera la préparation pour bien matérialiser les différentes options et ne pas obtenir de résultats difficilement interprétables.

Voici quelques exemples de cas d’utilisation tirés de notre expérience, et les questions auxquelles nous souhaitions des réponses.

Les participants priorisent votre backlog !

L’utilisation de cet atelier lors d’un cadrage projet permettra de définir les priorités de développement des fonctionnalités. L’exécution de cet atelier avec des parties prenantes (utilisateurs, sponsors, donneur d’ordre) permettra de capter la notion de business value sans avoir à la fixer de manière arbitraire ou en utilisant des formules complexes. C’est une bonne façon d’obtenir une première priorisation de son backlog. Attention à ne pas fournir des user stories trop fines, préférez des epics ou des features. Chez cette grande banque d’investissement, nous avons terminé le cadrage d’un projet de développement d’une nouvelle application par un atelier Buy a Feature avec des représentants des utilisateurs.

Les participants achètent les prochaines features !

Toujours sur une portée court terme, mais sur la base d’un produit existant, même dans un état peu avancé, il est possible d’utiliser cet atelier pour choisir les prochaines fonctionnalités à développer. Chez cet éditeur de logiciel par exemple, nous avons utilisé un atelier Buy a Feature après avoir réalisé un produit minimum viable en quelques sprints, afin de prioriser les fonctionnalités que nous allions développer pour la version beta. Cela nous a permis de résoudre des divergences d’opinions sur les fonctionnalités à placer en priorité. Nous avons invité les potentiels premiers utilisateurs de l’application et, après leur avoir fait tester un version minimale du produit, nous leur avons proposé d’acheter ce qu’ils souhaitaient avoir dans une version beta qui sortirait 2 mois plus tard.

Les participants achètent la roadmap !

Ici, l’utilisation ne porte plus sur du développement court terme mais sur l’évolution du produit à plus long terme. L’exercice est intéressant pour confronter sa vision à celle de ses utilisateurs, sans toutefois leur laisser une trop grande marge d’imagination. Chez cet autre éditeur de logiciel nous avons organisé un Buy a Feature avec des Professional Services venus des quatre coins du monde. Les Professional Services travaillent quotidiennement avec les utilisateurs finaux des produits et sont donc des conseillers idéaux pour obtenir un feedback sur l’intérêt de la roadmap.

Après avoir présenté les principales features prévues pour les 6 à 12 mois suivants, sans aucune notion d’ordre, les participants se sont répartis sur plusieurs tables et ont pu laisser aller leurs talents de négociation. Chacune des tables avaient les mêmes features et les mêmes montant d’argent. Nous souhaitions comparer les résultats d’une table à l’autre. Nous avons pimenté l’exercice en créant des groupes mélangeant des experts des deux principales lignes de produits. Les experts de l’une et l’autre ligne de produit ont donc du trouver des terrains d’entente pour acheter les features. Cela a conduit chacun à sortir de la simple réflexion d’évolution d’un produit et de positionner les débats sur la stratégie plus globale de l’organisation. Exactement le niveau de réflexion que l’on souhaite pour la constitution d’une roadmap.

Il est important de noter que dans cette forme, l’ordre dans lequel les participants achètent les features est une information extrêmement importante, alors que l’ordre importait moins dans les cas précédents d’une réflexion court terme. Il s’agira donc de le noter pendant le déroulement de l’exercice et ne pas se contenter du simple résultat. Cette utilisation de l’atelier répond typiquement à la question: ma roadmap est-elle pertinente ? L’ordre est-il cohérent ?

Les participants arbitrent la stratégie produit !

Pour finir, voici un dernier usage que j’ai expérimenté de manière plus accidentelle qu’intentionnelle mais qui se révèle a posteriori très utile. La portée de l’utilisation n’est ni sur du court terme, ni sur du long terme mais sur un mélange des deux. Chez ce troisième éditeur de logiciel nous préparions un Buy a Feature destiné à des consultants produits. Nous étions plutôt dans le deuxième cas de figure évoqué plus haut mais nous avions placé dans les features à acheter des éléments qui nécessitaient du travail sur du moyen terme. Lors d’une répétition de l’atelier avec le Marketing et le CTO, nous avons rapidement identifié un problème: les fonctionnalités qui nécessitaient plus de travail étaient mises au même niveau que celles qui pouvaient être livrées rapidement. Nous risquions de transmettre une mauvaise information sur la capacité à livrer.

Même si le résultat de l’atelier n’est pas une promesse de planification, il doit être réaliste. Nous avons cependant conservé un mélange de fonctionnalités court terme et long terme car la répétition a fait apparaître une question latente que personne ne voulait se poser : faut-il investir sur des features long terme, quitte à appauvrir la roadmap à court terme, ou bien investir sur des features court terme, quitte à rater les défis à long terme. Au final les consultants ont choisi quatre fonctionnalités court-termes et une fonctionnalité long terme, ce qui nous a permis d’alimenter notre réflexion sur la roadmap et de mieux cerner leurs attentes à long terme.

Quelques enseignements

Pour conclure cet article, voici un ensemble d’enseignements que j’ai accumulés lors de ces expériences et dont vous pouvez vous servir :

  • Une bonne préparation du matériel est indispensable pour que l’atelier soit immersif : imprimez vos features sur des cartes plastifiées, prenez des billets de Monopoly ou fabriquer vos propres billets avec un design approprié. Si vous vous contentez d’écrire des montants d’argent sur des morceaux de papier vous allez manquer l’adhésion des personnes. Je ne suis pas fan de l’utilisation des jetons de poker mais vous pouvez essayer cette alternative.
  • En terme de participants vous devez disposer d’un groupe suffisamment étoffé (+ de 4 personnes) et varié en terme de profils ou d’organisations, évitez les positions hiérarchiques entre participants.
  • Sélectionner une liste de 15 à 20 fonctionnalités sur lesquelles vous souhaitez une réponse. Au delà de 20 features, l’exercice peut se révéler fastidieux, je l’ai seulement fait pour le cas de la roadmap avec une trentaine de fonctionnalités, d’une part car nous mélangions les features de 2 lignes produit, d’autre part car l’échelle de temps à couvrir était plus large.
  • Je trouve que la règle de calcul des montants d’argent présentée dans le livre ne crée pas assez de tensions dans le déroulement de l’exercice. Je préfère allouer un montant d’argent total égal à 30% de la somme des features, montant qu’il faudra ensuite diviser par le nombre de participants pour obtenir la somme allouée à chacun. Cela limite les possibilités d’achat et donne lieu à des débats plus riches.
  • Si vous en avez la possibilité, faites une séance de répétition avec des collègues connaissant le produit avant de vous lancer avec les vrais participants, cela vous permettra de jauger de la pertinence des prix, de la cohérence des features proposées, de la clarté des descriptions, et de vous sentir plus serein lors du déroulement de l’atelier réel.
  • Prenez soin de noter les arguments qui sont utilisés lors des échanges, ils ont une importance aussi grande que le résultat final, et vous permet d’approfondir lors d’une analyse à froid ou d’une restitution.
Gilles Mantel

J’ai 13 ans d’expérience professionelle. Je suis impliqué sur des projets itératifs et offshore depuis 2001 et j’y ai occupé tour à tour les postes d’ingénieur qualité, responsable des tests, analyste fonctionnel, et directeur de projet.

Je forme et j’accompagne les clients de Xebia dans l’adoption de méthodes agiles (SCRUM, XP) et de pratiques d’ingénierie pilotées par les tests (TDR, ATDD). J’ai développé mon expertise au travers d’interventions dans des domaines métiers aussi variés que l’industrie, l’e-commerce, l’édition logiciel, le luxe, le public, les télécoms, ou les banques d’investissement.

J’intervient régulièrement dans les conférences traitant de l’agilité et des tests depuis 2008.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *