If the notion of MMF is still not widespread, it’s very useful in organizing an agile project backlog. Knowing how to work with MMF is an asset in the capacity to manage the scope and variability of it.
I’ll let you see a full article on the MMF definition I wrote earlier on this blog.
Article: MMF (Minimum Marketable Feature)?
How to work with MMF?
When we define a feature such as the image below, it’s split into several different user-stories.
This division can precisely be worked with this notion of MMF:
- what must we deliver and what will be deliverable tomorrow?
- what really differentiates us from other market actors?
- what will bring significant income?
These 3 questions will allow to make a division of the functionality in MDR (Must-Differenciate-Revenue). A division that must not in any way forget the need of the customer; but don’t forget to have a strong marketing concept in the development.
Example of simple MMFto understand
Here is an example of a feature on an ecommerce website: “Payment”.
For this feature, we could have the following user-stories:
- As a customer, I wish to pay in credit card
- As a customer, I wish to pay by check
- As a customer, I wish to pay in 3 times to pay my purchase
If we take the definition of MDR, we could easily identify this on our user-stories:
- As a customer, I wish to pay in blue card (Must-Revenue)
- As a customer, I wish to be able to pay by check (Nothing)
- As a customer, I wish to pay in 3 installments to pay for my purchase (Revenue)
None of these 3 user-stories are differentiating but payment in credit card is essential for an ecommerce site. On the other hand, we could imagine a differentiating feature (D of MDR) but not necessarily essential as the one mentioned below:
- As a customer, I want to be able to pay in bitcoin.
So, here is the MMF imaginable of our ecommerce site:
- As a customer, I wish to pay in blue card => essential for an ecommerce site today.
- As a customer, I wish to pay in bitcoin => maybe a strong asset to differentiate themselves from the competition.
The MMF of our “Payment” functionality will be composed of an indispensable part and a differentiating part.
Our MMF will be our MVP
We had already seen the concept of MVP on this blog. The MVP (Minimum Viable Product) will be the minimum product (or service) that will test a hypothesis; any functionality not required to test this service will not be a part of the MVP.
I propose to you to see this complete article on the subject to master all the subtleties of the MVP (even MVP of the same product).
Article: What’s the MVP (Minimum Viable Product)?
The set of MMFs for each feature will make it possible to build the MVP of the product. A good definition of the MMF of each feature will allow to review the MVP of the product in case of proven delay.
In our example, in case of delay, the team will be able to choose not to put “payment in bitcoin” in MVP and accept the risk of being less differentiating; this will not prevent us to try to release this innovative payment very quickly.
Conclusion
I advise you to work your backlogs by using on this notion of MMF in order to have a real ability to properly manage the variability of the scope and the consequences of the choices to be made.
Take advantage of the MDR (Must-Differenciate-Revenue) to properly determine the MMF of each of your features.
1 Trackback / Pingback