Atelier buy a feature : une autre manière de prioriser les stories

Objectif : prioriser et choisir les stories

J'ai trouvé cet atelier particulièrement utile dans le cadre de scrum dans une situation avec plusieurs clients, ayant chacun leurs priorités.

Prioriser les stories avec des billets de monopoly : atelier buy a feature

Prioriser les stories avec des billets de monopoly : atelier buy a feature

La backlog de l'équipe était jusqu'alors priorisée en réunissant les 3 personnes concernées et en leur demandant de classer chaque story ou projet du plus important au moins important. Cette technique très simple est déjà très efficace : elle permet de faire des choix forts, et force les interlocuteurs à sortir du traditionnel "must-have" & "nice-to-have".

Cependant, j'avais l'impression que :

  • la discussion n'était pas particulièrement vivante,
  • cette réunion n'était pas suffisamment orientée autour du rapport gain/coût de chaque story,
  • le premier participant qui parlait avait souvent l'ascendant.

J'ai donc voulu expérimenter une autre manière d'organiser ces réunions de priorisation, et l'atelier buy a feature a été plutôt convainquant sur ces trois points.

Préparer les stories

Pour que l'atelier se déroule au mieux, il a fallu au préalable préparer et partager les stories. Pour chacune, nous avons imprimé une feuille A5 avec ces informations :

  • L'intitulé de la story (ce qui doit être fait)
  • La raison pour laquelle on nous a demandé cette feature
  • L'impact attendu
  • Le prix de la feature

J'insiste sur deux éléments nouveaux dans cet atelier : l'impact attendu et le prix de la feature.

Faire ressortir la vraie raison

Par impact, j'essaye de faire ressortir la vraie raison qui pousse à réaliser une feature. Le pourquoi du pourquoi (du pourquoi). Pour quelle raison en tant que product owner, cette story apportera in fine de la valeur au produit ? Et sous quelle forme ?

Voici des exemples de stories, pour bien montrer la différence :

  • Intitulé : Pouvoir afficher les images des produits en grande résolution.
    • Raison : Se faire un idée plus précise des produits à acheter.
    • Impact : Amélioration du taux de conversion.
  • Intitulé : Refactoriser les appels à la base de données.
    • Raison : Pénible à maintenir et à faire évoluer.
    • Impact : Gain de capacité de l'équipe de développement, sur les évolutions & maintenance futures.

Dans l'idéal, ce doit être aux demandeurs, clients, représentants des clients d'exprimer cet "impact" le plus précisément possible. Car il sert à la fois à prioriser mais aussi parfois à arbitrer la manière d'implémenter une story.

Le prix des stories

Dans un atelier qui s'appelle buy-a-feature, on se doute qu'à un moment on va parler d'argent. Voici comment nous avons déterminé le prix des stories:

  1. Utiliser des tailles de tee-shirt pour estimer les stories avec l'équipe.
  2. Avec l'expérience passée, convertir les tailles de tee-shirt en points "moyens"
  3. Transformer les points en dollars, pour que les prix puissent se régler avec des billets de monopoly

Dans notre cas, nous avons identifié les tailles de tee-shirt : XS, S, M, L, XL et XXL.

Les sprints précédents nous ont appris qu'en moyenne, les projets représentaient ce nombre de points :

  • XS: 3pts
  • S: 13pts
  • M: 34pts
  • L: 49pts
  • XL: 69pts
  • XXL: 133pts

La répartition peut surprendre (il n'y a pas vraiment de logique), mais c'est la manière d'estimer moyenne de notre équipe. On a donc utilisé ces tailles pour évaluer l'effort demandé par les stories.

Avec une grosse règle de trois à la louche, voici ce que ça a donné, une fois convertit en monnaie de monopoly :

  • XS: $100
  • S: $400
  • M: $1,000
  • L: $1,500
  • XL: $2,000
  • XXL: $4,000

Il a fallu trouver un éventail de prix que l'on peut payer avec 2 ou 3 coupures maximum. Dans notre cas, j'ai utilisé uniquement des billets de 100 et 500.

Billets faits main pour l'atelier buy a feature

Billets faits main pour l'atelier buy a feature

Pourquoi a-t-on utilisé des tailles de tee-shirt pour déterminer le coût de chaque feature ?

D'abord parce que nos estimations donnent déjà une bonne idée du coût réel. Certes, le chiffrage est forcément peu précis, mais ce n'est pas vraiment ça qui importe.

Deuxièmement, parce que l'atelier buy-a-feature vient en amont du sprint. Il y a possiblement beaucoup de stories qui sont étudiées, et énormément qui seront retoquées. Passer du temps à tout analyser, découper, chiffrer serait du temps gaspillé.

Déterminer et répartir le budget

La première fois que j'ai utilisé cet atelier, nous étions en pleine transition entre Scrum et Kanban (ou scrumban). D'un rythme de 3 semaines, nous passions à un flux continu de stories à implémenter.

J'avais donc prévu de proposer le budget représentant à peu près une semaine, ce qui est très contraignant mais ce qui correspond bien à l'idée de cet atelier. Si nous étions restés à 3 semaines, il aurait probablement fallu adapter l'atelier pour prévoir soit des "lots" plus réduits, soit une manière de prioriser ce qui aurait été finalement choisi.

Dans notre cas, 1 semaine représente environ 100 points soit un budget de $3,000. Autour de la table, nous avons 3 décideurs. Vous l'aurez donc deviné : chacun se retrouve en début d'atelier avec un budget de $1,000.

Avec des billets de $100 et $500, ça donne, pour chacun : 1 billet de $500 et 5 billets de $100.

Déroulement de l'atelier

L'atelier se déroule en trois étapes :

  1. Présentation des stories : pour que chacun se fasse une idée de l'ensemble des candidats
  2. Achat individuel:
    • Chacun répartit ses propres billets comme il l'entend
    • Interdiction de faire de la monnaie
    • Pas le droit de négocier
    • Si des stories sont achetées (somme des billets misés ≥ prix), elles sont sélectionnées d'office
  3. Discussion et répartition des billets restants:
    • Les participants disposent d'un pot commun et doivent se mettre d'accord sur la répartition
    • Quand des stories sont achetées (somme des billets misés ≥ prix), elles sont sélectionnées
  4. Priorisation: à faire si besoin en commun.

On se retrouve donc à la fin de cet atelier avec une liste de stories sélectionnées pour la prochaine itération.

Il peut être nécessaire de demander aux participants de se mettre d'accord sur une priorisation des stories parmi celles sélectionnées, plus particulièrement en SCRUM sur des cycles assez longs.

Accueil

Le ROTI de cet atelier a été assez bon : le format est assez court, efficace et ludique. Il présente la priorisation avec une métaphore très terre à terre qui a beaucoup plu.

Et vous, avez-vous déjà utilisé cet atelier pour prioriser des stories ? Quelle approche avez-vous utilisée ? Pouvez-vous conseiller des pratiques que vous avez expérimentées ?

Sources d'inspiration :

Commentaires

4 Comments sur « Atelier buy a feature : une autre manière de prioriser les stories »

  1. Tim dit :

    Utiliser la « pénurie » (budget limité) pour estimer la « business value » est effectivement une très bonne méthode. Le coup des billets de Monopoly c’est top!

    Est ce que vous aviez des stories « techniques », dont la valeur ajoutée est difficile a estimer? Dans ce cas j’imagine cette technique particulièrement efficace.

    Et est ce que tu te verrais utiliser ce genre de méthodes pour prioriser un plus gros backlog? Genre un backlog de 10+ sprints?

  2. Ghusse dit :

    Pour les stories techniques, nous avons décidé d’allouer d’office une partie du budget dessus, car elles avaient tendance à se faire tout le temps retoquer (décision assez récente de rétrospective).

    Les repousser sans cesse pesait sur l’équipe, qui payait le coût de la dette technique sans jamais pouvoir raccrocher les wagons.

    Pour les grosses backlogs, je dirais qu’il faut tenter de le faire par lots sinon ça peut devenir vite ingérable. Par exemple si tu as un budget total de 1000, tu découpes en 5 lots de 200 et tu recommences l’exercice 5 fois. Après, il faut tenter : essaye quelque chose et dis nous comment ça s’est passé !

  3. Tim dit :

    Est ce que le PO a vu le système s’autocorriger ou pas? Je l’ai vu dans un projet précédent où on avait le même problème, puis on a vraiment vu le « budget » de ton exemple stagner, puis reculer, et la le PO a vraiment compris qu’il avait trop tiré sur la corde.

    Mon projet actuel, un rewrite avec scope fixe et timeline fixe, ne s’y prête pas vraiment. Je coach les équipes vers plus d’autonomie, de qualité et de plaisir au boulot, mais coté produit j’ai très peu de levier. C’est d’ailleurs probablement de là que vient ma question, dans un cadre « plus agile » tu ne devrais pas avoir une backlog aussi monstrueux, donc ton approche devrait fonctionner.

  4. Ghusse dit :

    Le PO a bien conscience des problèmes sur certains projets qui ont dérivé, et n’a pas de problème pour qu’on alloue du temps à la gestion de la dette technique.

    En gros, il nous délègue la responsabilité de cette gestion. Il est d’accord avec le nombre de point qu’on lui alloue (qui correspond à la capacité de l’équipe moins la charge technique prévue).

    C’est difficile de demander à un PO qui a la vision métier de prioriser des stories très métier et des stories très techniques. Si on veut qu’il fasse le choix des stories techniques, il faut faire un travail de lobbying, d’explication etc qui prend du temps à tout le monde.

    Donc le raisonnement c’est plutôt : s’il y a besoin, faites-le.

Laisser un commentaire