Bibliothèque · Discovery · Débutant
Buy a feature : faire arbitrer avec un budget
Un atelier où utilisateurs ou parties prenantes « achètent » des fonctionnalités avec une monnaie limitée : ils sont obligés de choisir.
Pour qui, pour quand
En résumé
Chaque fonctionnalité a un prix, lié à son coût réel ou simplement indicatif. Chaque participant reçoit un budget inférieur au total : il ne peut pas tout acheter et doit choisir. Il peut miser gros sur une seule fonctionnalité ou répartir son budget.
Le classement final compte, mais les discussions qui suivent comptent autant : pourquoi cette fonctionnalité a-t-elle récolté autant ? On garde les votes anonymes pour limiter l'influence des uns sur les autres.
Méthode étape par étape
dans l'ordre, sans en sauter
- 01Lister 10 à 15 fonctionnalités avec une description d'une ligne.
- 02Donner un prix à chacune, proportionnel à l'effort.
- 03Distribuer à chacun un budget (par ex. 2×500, 4×100, 1×50…) inférieur au total.
- 04Faire acheter, de préférence en vote anonyme.
- 05Débriefer : pourquoi ces achats, qu'est-ce qui n'a pas été acheté ?
- 06Établir le classement et le partager.
Questions à me poser
avant de te lancer
- →Le budget est-il assez serré pour forcer des renoncements ?
- →Les prix reflètent-ils l'effort réel, ou vont-ils fausser le jeu ?
- →Qu'ai-je appris dans le débrief que le classement ne dit pas ?
Ce qui coûte cher
les pièges déjà vus sur ce sujet
Dans ma bible
Techniques de priorisation et US · p. 275-276
Chargement du passage…
Mes notes
ce que tu retiens, ton contexte
Situations couvertes
- · Je dois préparer un atelier
- · Je n'arrive pas à faire converger les parties prenantes
- · Je dois prioriser un backlog
Provenance
Ma bible PM · Techniques de priorisation et US, p. 275-276
ajoutée le 2026-09-18
Mots-clés
À lire juste après
ce que cette fiche appelle
Ce qui renvoie ici
des fiches qui citent celle-ci - c'est là que tes REX réapparaissent