Note re this update: Many in the Lean world are now using Minimum Viable Product (MVP), Minimum Viable Feature (MVF) or Minimum Marketable Release (MMR) instead of MMF. Mostly this reflects the fact that IT companies typically do not market their services. Additionally, marketing issues alone do not cover all of the aspects needed to determine if something is viable (e.g., release considerations often play a part). However, you can consider the intent of MVP, MVF, MMR and MMF to be the same. I'l use MMF in this article merely because it is still the widespread term.
In my earlier blog I commented about the role and value of context. I recently came back from a trip where I was conducting an assessment of a 50-75 person development organization. They were doing Scrum reasonably well and had based their sprints on building epics, having read Mike Cohn's books. This made sense since epics typically defined releasable value.
Unfortunately, the epics they worked on often included items that weren't needed for release. Release planning was typically done by taking the next most important epic off the product backlog and working on it. Epics, however, don't define their scope particularly well. In watching this team, I became convinced one of their challenges was that they were releasing larger amounts of software than needed each release. Because they were so much more effective than they had been this error hadn't been quite apparent. However, it was clear that using a MMF would have enabled them to better define the scope of the Epic they were working on. In other words, instead of starting with just large features (Epics) starting with MMFs would have given better clarity on what to build. For those who haven't read my prior blog, Rethinking the Practices of Scrum - or What Would Chris Alexander Say? (note: if you want to learn more about how MMFs are used in Agile, go ahead and read this blog). I'll redefine it here (note MMF comes from Software By Numbers by Denne, Cleland-Huang):
"As the name implies, an MMF is characterized by the three attributes: minimum, marketable, and feature.
Probably the most significant characteristic of an MMF is the fact that it represents a distinct and deliverable feature of the system. Webster's dictionary describes a feature as "the structure, form, or appearance" of an entity, or as its "prominent characteristic." A feature is therefore something that is observable to the user. For example, in an online travel agency application, a flight planner and an online tour organizer might be seen as distinct features. In contrast, a class library would not be considered a feature because it provides no clear-cut and deliverable functionality to the user. Similarly, an underlying architectural layer that provides the infrastructure for an application would likewise not be a feature, because it only provides value when delivered within the context of the entire application.
An MMF also must provide significant value to the customer. We use the term "marketable" to describe this concept. However, value can be measured in many ways, such as revenue generation, cost savings, competitive differentiation, brand-name projection, and enhanced customer loyalty. Even this list is by no means exclusive, as true value can only be defined within the context of the proposed project and measured by the organization developing the software."
Epics as described by most Scrum practitioners are not MMFs, but rather, large stories. By starting with an MMF, one starts with the big picture. But more importantly, there is a set scope that is defined as well. Of course, the team can chose to extend the scope of the MMF. But using an MMF instead of an Epic to start with makes it more likely that the team will stick to the most critical functionality.