Achetez votre roadmap en moins de 2h avec “Buy a feature”

Achetez votre roadmap en moins de 2h avec “Buy a feature”

Au cours d’une mission, nous avons été confrontés à une question que l’on connaît tous, comment prioriser ? C’est un atelier Buy a Feature qui nous a permis de trouver une solution.

Contexte

Lors de la construction d’un produit, il est difficile de s’accorder sur une roadmap de développement. On a généralement une liste de fonctionnalités toutes très importantes mais aucun moyen facile de les prioriser. C’est en tout cas un problème que j’ai rencontré chez un client.

Voici le contexte de la mission :

  • Construction d’un produit numérique B2C de consultation de commande e-commerce
  • Plus de 10 stakeholders sur le projet, avec chacun des intérêts distincts
  • Le MVP a déjà été identifié suite à un story map. Ce MVP ne concernant qu’un nombre réduit de commandes ; il nous fallait augmenter les cas fonctionnels gérés par l’application ainsi qu’y inclure de nouvelles fonctionnalités.
  • Suite à ce MVP nous devions identifier une roadmap de trois mois.

Objectif : Définir une priorité satisfaisant tous les stakeholders, incluant de nouvelles features et élargissant le nombre de clients concernés.

Après plusieurs propositions de roadmap rejetées, nous avons donc fait un atelier Buy a Feature réunissant toutes les parties prenantes afin d’obtenir une priorisation validée par tous.

Préparation de l’atelier

Attention, pour que cet atelier soit bien compris et percutant, il faut une bonne préparation !

Les différentes étapes de préparation de l’atelier sont les suivantes :

  • Constituer la liste des features
    • Personnes concernées : PO + équipe

Au cours d’un brainstorming, nous avons identifié un maximum de features pouvant intéresser les stakeholders. Nous avons ensuite trié et priorisé ces features en enlevant celles jugées moins pertinentes ou celles trop complexes pour être traitées en début de projet. A la fin de ce tri nous avions environ 25 fonctionnalités (ce qui est pour moi un maximum).

N.B. : Avoir la liste d’un maximum de features éventuelles n’a pas pour but de remplir la roadmap de l’année, mais d’anticiper les questions des participants pendant l’atelier si leur sujet a été écarté.

  • KPI sur ces features (actuel/objectif)
    • Personnes concernées : PO

L’idée derrière ces KPIs est de fournir aux participants de quoi comparer les features les unes aux autres. Nous avons donc sorti un maximum de données comme le nombre de clients concernés par une feature ou une estimation du taux de clics.

N.B. : Vous pouvez aussi évaluer la valeur business de chaque fonctionnalité pour pouvoir les comparer.

  • Estimation du prix des features
    • Personnes concernées : PO + équipe

Une des phases essentielles dans la préparation de cet atelier est l’estimation du coût de chaque fonctionnalité. Pour l’obtenir vous pouvez faire une session d’extreme quotation ; un planning poker risque d’être trop chronophage.

N.B. : Je conseille plutôt l’extreme quotation car nous ne cherchons pas ici à obtenir le coût exact mais une estimation relative des features.

Après avoir classé les features par complexité, avec l’équipe nous avons fait une première estimation du prix en suivant la suite de fibonacci (en K€) ; les features les moins complexes valaient 1000 € puis 2000 € et ainsi de suite… Puis nous avons itéré sur ce premier jet afin d’harmoniser les prix et de limiter le nombre de fonctionnalités “peu coûteuses”.

  • Budget
    • Personnes concernées : PO

Une fois les prix fixés, il reste à évaluer le budget qui sera distribué entre les participants. Pour cela nous avons calculé le coût total des features (dans notre cas 500 000€) et nous avons pris une fraction de cela comme budget (120 000€, soit légèrement moins d’un quart). La fraction choisie dépend de la durée de la roadmap voulue.

N.B. : Nous avions listé des features pour environ 1 an, et devions déterminer une roadmap pour le premier trimestre, d’où le quart.

Déroulement de l’atelier

  • Participants

Pour l’atelier nous avions convié les représentants des différentes parties prenantes du projet. Nous avons ensuite réparti équitablement le budget entre eux et nous leur avons présenté le déroulement de l’atelier.

N.B. : Gardez un nombre de participants pas trop élevé. Nous étions une un peu plus d’une dizaine dans notre cas et c’est à mon avis la limite.

  • Présentation de l’atelier : 10 min

Lors de la présentation il est important que chaque participant comprenne l’objectif de l’atelier, le déroulement ainsi que ce à quoi ils vont être confrontés (négociations)

  • Achats : 30 à 60 min selon le nombres de fonctionnalités et le nombre de participants

Les participants regardent de plus près chaque feature puis identifient celles qui les intéressent. Ils vont ensuite se rapprocher des participants ayant les mêmes objectifs qu’eux. Dès qu’une feature est achetée, il faut bien le communiquer aux autres participants.

N.B. : Il est intéressant de donner un budget à l’équipe afin qu’elle puisse aussi participer à sa roadmap. Dans notre cas, l’équipe n’essayait pas d’acheter des features mais elle aidait à l’achat de ce qui lui paraissait pertinent.

  • Priorisation : 10 à 20 min selon le nombre de fonctionnalités

Une fois les achats terminés, nous avons établi une priorité de développement entre les différentes features choisies. Même si tous les sujets identifiés seront développés, il est important de définir cet ordre afin d’éviter des retours de stakeholders s’impatientant de ne pas voir arriver leur sujet.

Pour ce faire, nous avons d’abord demandé l’avis de l’équipe car certains sujets peuvent être moins coûteux s’ils sont traités en dernier et inversement. La priorité ainsi définie a été partagée avec tous les participants.

Observations

Outre le partage de la priorité, nous avons pu observer plusieurs autres choses au cours de cet atelier :

  • Questions sur les prix :

Dès le début de l’atelier, il nous a été demandé s’il était possible de négocier les prix. Il est donc important de définir les prix avec l’équipe afin de pouvoir expliquer quelle est la complexité d’un sujet.

  • Limiter les demandes de dernière minute :

Partager la roadmap et la priorité avec tous les participants, nous permet de limiter le nombre de “demandes urgentes de dernière minute”.

  • Participation de l’équipe

Faire en sorte que l’équipe soit présente lors de l’atelier a été très bien perçu par l’équipe elle-même ainsi que par les participants. L’équipe s’est sentie plus impliquée dans la construction du produit et ses explications ont permis aux participants de mieux comprendre les différences de complexité entre les sujets.

Il est vrai que les utilisateurs du produit sont idéalement les participants de cet atelier mais dans des entreprises de taille importante il est souvent difficile de les interroger en direct. De plus, on est souvent confronté aux enjeux business ou aux obligations de l’entreprise ; dérouler cet atelier avec des personnes de l’entreprise devient alors pertinent.

En bref, je conseille cet atelier à tout PO qui a des problèmes à obtenir une priorisation ou de définition d’une roadmap ; qui cherche à fédérer les différentes parties prenantes d’un projet ou juste à sensibiliser les acteurs extérieurs à l’équipe au coût d’une fonctionnalité.

Laisser un commentaire

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