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.
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.
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.
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.
- 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
- 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