Si la notion de MMF est encore peu répandue, elle est pourtant très utile dans l’organisation d’un backlog de projet agile. Savoir travailler avec les MMF est un atout dans la capacité de gérer le scope et la variabilité de celui-ci.
Je vous laisse voir un article complet sur la définition du MMF que j’avais écrit précédemment sur ce blog.
Article : Qu’est-ce que le MMF par rapport au MVP et est-ce agile ?
Comment travailler avec des MMF ?
Quand on définit une fonctionnalité comme par exemple sur l’image ci-dessous, elle est découpée en plusieurs user-stories différentes.
Ce découpage peut justement être travaillé avec cette notion de MMF :
- que doit-on impérativement livrer et qu’est-ce qui serait livrable demain ?
- qu’est-ce qui nous différencie réellement des autres acteurs du marché ?
- qu’est-ce qui rapportera des revenus non négligeables ?
Ces 3 questions vont permettre de faire un découpage de la fonctionnalité en MDR (Must-Differenciate-Revenue). Un découpage qui ne doit en aucun cas oublier le besoin du client mais qui permet également d’avoir une notion marketing forte au sein du développement.
Exemple MMF simple pour comprendre
Voici un exemple de fonctionnalité sur un site ecommerce : « Paiement ».
Pour cette fonctionnalité, nous pourrions avoir les user-stories suivantes :
- En tant que client, je souhaite pouvoir payer en carte bleue
- En tant que client, je souhaite pouvoir payer en chèque
- En tant que client, je souhaite pouvoir payer en 3 fois afin de payer mon achat au fur et à mesure
Si on prend la définition du MDR, on pourrait facilement identifier ceci sur nos user-stories :
- En tant que client, je souhaite pouvoir payer en carte bleue (Must-Revenue)
- En tant que client, je souhaite pouvoir payer en chèque (Rien)
- En tant que client, je souhaite pouvoir payer en 3 fois afin de payer mon achat au fur et à mesure (Revenue)
Aucune de ces 3 user-stories sont différenciantes mais le paiement en carte bleue est indispensable pour un site ecommerce. Par contre nous pourrions du coup imaginer une fonctionnalité différenciante (D de MDR) mais pas forcément indispensable comme celle cité ci-dessous :
- En tant que client, je souhaite pouvoir payer en bitcoin.
Du coup, voici le MMF imaginable de notre site ecommerce :
- En tant que client, je souhaite pouvoir payer en carte bleue => indispensable pour un site ecommerce aujourd’hui.
- En tant que client, je souhaite pouvoir payer en bitcoin => peut-être un atout fort pour se différencier par rapport à la concurrence.
Le MMF de notre fonctionnalité « Paiement » sera alors composé d’une partie indispensable et d’une partie différenciante.
Nos MMF constitueront notre MVP
Nous avions déjà vu le concept du MVP sur ce blog. Le MVP (Minimum Viable Product) sera le produit minimum (voire le service) qui permettra de tester une hypothèse ; toute fonctionnalité non indispensable pour tester ce service ne fera pas parti du MVP.
Je vous propose d’aller voir cet article complet sur le sujet pour maitriser toutes les subtilités du MVP (voire des MVP d’un même produit).
Article : Qu’est-ce le MVP (Minimum Viable Product) ?
L’ensemble des MMF de chaque fonctionnalité permettra de constituer le MVP du produit. Une bonne définition du MMF de chaque fonctionnalité permettra de revoir le MVP du produit en cas de retard avéré.
Dans notre exemple, en cas de retard, l’équipe pourra faire le choix de ne plus mettre « le paiement en bitcoin » en MVP et d’accepter le risque d’être moins différenciant ; cela n’empêchera pas d’essayer de sortir très rapidement ce paiement novateur.
Conclusion
Je vous conseille de travailler vos backlogs en jouant sur cette notion de MMF afin d’avoir une véritable capacité de bien gérer la variabilité du scope et des conséquences des choix à prendre.
Profitez du MDR (Must-Differenciate-Revenue) pour bien déterminer le MMF de chacune de vos fonctionnalités.
3 Rétroliens / Pings