More Insights on Epics Vs Minimum Marketable Features

July 6, 2008 — Posted by Al Shalloway

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.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, SAFe
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile