All agile development methodologies share one thing in common, they break big features into smaller features and sort them based on business value. Sounds easy enough right? Well yes and no. Behind this simplicity is the complexity of how and where those splits are made. In my experience, the key to successful splits or dissections lies in knowing along which lines to make incisions and knowing when it’s time to stop cutting. MMF (Minimum Marketable Feature) helps us in both departments. Let’s break it down into its component parts.
Minimum
If a split would result in a story so small that it couldn’t be marketed to your customers, then the split shouldn’t be made. To help with this decision I always ask whether this feature would justify its own bullet point in an imaginary customer email summarising the features of a new release, if the answer is no, then don’t split it.
MMF only prescribes the desired size of a feature at the time we start work on it. Usually each MMF is the descendant of a series of larger features. Features that we’ve broken apart in order to give more detail as they ascended the backlog, indicating their growing importance. For example a feature called “geotag photo” is a descendant of “photo sharing”, which in turn was a descendant of “iPhone client”, which again was a descendant of the original feature called “mobile support”. The feature “mobile support”, “iPhone Client” or “photo sharing” may no longer be in the backlog, but dozens of their decedents are. This is the evolution of a feature, where by the addition of greater detail is organic.
Marketable
Ask yourself whether the feature is marketable. If the answer is no, then you should probably give it the chop as it creates no additional value for your customers. Steve Jobs and other visionaries have the ability to know their customers needs before they know it themselves, but for the rest of us mere mortals, creating features that don’t create recognised customer value should at the very least trigger red flags, flashing lights and loud sirens.
Feature
A feature is demonstrable behaviour of the product. For example, a feature called ‘shopping cart’ or ’3.5mm headphone jack’ are acceptable whilst ‘design database schema’ or ‘injection molding research’ are not. Although ‘database schema design’ or ‘injection molding research’ might be valid and necessary activities, they are not features in their own right, they are things that may need to be done in order to implement a feature, there’s a difference.
MMF Smells
- The MMF is too small to inform your customers about
- The MMF has no demonstrable value for your customers
- The MMF appears outside of the top third of your backlog
- The MMF can be understood by domain experts but not your average customer
- The name of the MMF is an action rather than a thing
- The MMF you’ve started work on could be split into two MMF’s
MMF Triggers
- Edit Feature: When you find yourself wanting to edit an existing feature, ask whether it would be best split into other features or MMF’s
- Split Feature: When splitting a feature look at its position in your backlog and ask yourself whether it’s too early to be giving this feature extra thought and attention
- Begin Work: When beginning work on an MMF ask yourself if you could break it down further
Thanks for your insightful article. Especially the evolution of a feature on the backlog is something, not too many understand and expect to happen.
The important thing with the evolution is that your planning gets better and better the smaller your features become. Something like “mobile support” cannot be estimated but something like “geotag photo” easily can.
I even keep two backlogs: One for the rough product ideas and one for implementable (and estimatable) features.
Thanks for the comment Matthias. Two backlogs is a cool idea, we used to keep two backlogs exactly as you do, I found it works great if the product owner can keep it under control. Unfortunately one of our product owners is a little too creative and started using the second one like a storage tank for his brainstorming sessions, it rapidly grew to over a hundred stories. At that point we pulled the plug and went back to one.
He still keeps his second backlog, but it’s not displayed on the office backlog boards anymore, as it scares the team
[New Post] Introduction to Minimum Marketable Features (MMF) – http://www.upstarthq.com/2010/04/introdu…
There is no scientific method for determining the shirt size of a given MMF. It’s a simple process of assigning a “gut feel” based on the description of the MMF.
Does anyone have a simple method for this?
Hi Keven,
That’s a great question and something that I’ve played around with a fair bit in the past. In the end what I found worked best for our teams was making the sizes relative, we did this by taking a story that was very well understood and of average size and calling it a ‘medium’, we then said a large is double the size of a medium and a small is half the size of a medium and an XL is double the size of a large etc.
The team could then easily estimate the size of a task by comparing it to the well understood task. We also had the rule that if in doubt, always round up to the next size. So if they weren’t sure if it was a medium or a large, then it always becomes a large.
Cheers,
Chris
Like a small businessperson, you don’t have any greater leverage than the truth.
The gambling generally known as business looks with austere disfavor upon the company referred to as gambling.