There are a variety of terms in use for chunks of functionality that are worth releasing and the requirements that describe them. Desirable characteristics for these features include being minimum, releasable, and valuable. At the moment I am using the phrase Minimum Releasable Feature (MRF) so I thought I’d explain why and some of the alternatives.
Epic
Following the lead of the XP guys the Agile community has adopted the term Epic for a large, often ill-defined, user story. Large as in too large to develop in a single timebox/sprint/iteration. An Epic might not be minimum, releasable or valuable. It is just a term for big requirement.
Minimum Marketable Feature (MMF)
Most Kanban people talk about a Minimum Marketable Feature (MMF) and use these as the most important chunk of requirements. To quote Net Objectives: Glossary a MMF is:
The smallest set of functionality that must be realized in order for the customer to perceive value. A “MMF” is characterized by the three attributes: minimum, marketable, and feature. A feature is something that is perceived, of itself, as value by the user. “Marketable” means that it provides significant value to the customer; value may include revenue generation, cost savings, competitive differentiation, brand-name projection, or enhanced customer loyalty. A release is a collection of MMFs that can be delivered together within the time frame.
The concept of an MMF is actually older than Kanban. Denne and Cleland-Huang (2003) in “Software by Numbers” defined an MMF as:
A chunk of functionality that delivers a subset of the customer’s requirements, and that is capable of returning value to the customer when released as an independent entity
Unlike Net Objectives: Glossary I think a MMF is actually characterised by four attributes, not three: it is a feature that is minimum, releasable, and valuable. This is in contrast to Epics or lower level User Stories or features in general. The term MMF is emphasising “minimum” and “valuable” over “releasable”.
Minimum Marketable Release (MMR)
Ironically David Anderson, creator of Kanban for Software Engineering, doesn’t like MMF. He believes the Lean / Kanban community are not adhering to the Denne and Cleland-Huang definition so shouldn’t use the term. David prefers a Minimum Marketable Release (MMR) (Anderson, 2010, p. 152):
A set of features that are coherent as a set to the customer and useful enough to justify the costs of delivery
(David advises using MMRs to trigger releases but using lower level work items, e.g. User Stories, to flow through the system. This is to reduce variability and increase predictability.)
The “minimum”, “releasable” and “valuable” aspects of an MMR are all represented in the name, Minimum Marketable Release. However this does somewhat neglect the fact we’re talking about a feature (i.e. functionality reflecting a requirement). I guess that is ok, as in David’s definition a release includes several features.
Minimum Useful Feature Set
The Poppendiecks (2007) call their high level requirement a Minimum Useful Feature Set. They emphasise the “minimum” and “valuable” aspects and the “releasable” aspect is implicit.
Minimum Releasable Feature (MRF)
In my latest lean-agile programme I’ve opted to call this level of requirement a Minimum Releasable Feature (MRF). I’m essentially emphasising the “minimum” and “releasable” bits over the “valuable” bit. This is because the product managers I am working with are better at spotting value than at identifying chunks of functionality to release incrementally. I continually ask them “What is the minimum that we can release?” Of course the MRF also has to be valuable but this is assessed during prioritisation. Unlike one of David Anderson’s MMRs my MRF isn’t necessarily a complete release, i.e. a release will include one or more MRFs. This means some decisions about packaging releases can be deferred … and deferring decisions as late as possible is a goal of lean.
References
Anderson, D.J. (2010). Kanban: Successful Evolutionary Change for Your Techology Business. WA: Sequim.
Denne, M. and Cleland-Huang, J. (2003). Software by Numbers: Low-risk high-return development. Prentice Hall
Poppendieck, M, and Poppendieck, T. (2007). Implementing Lean Software Development: From concept to cash. Addison-Wesley.
Very informative article.
Well researched and good to the point, I was struggling to find the differences. Thanks Steven for putting it together so concisely.
Seems to me your MMF is operating at the same level as the “Elementary Business Process” which is also the sweet spot of a use case.
I’m not sure I agree. An EBP might have different definitions but one I’ve seen is “A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state”. This is exactly the definition I use for a user focussed User Story (there are other types of User Story). The MMF is a collection of those.