More Insights on Epics Vs Minimum Business Increments

July 6, 2008 — Posted by Al Shalloway

Note re this update: Due to Eric Ries' Lean-Startup (a great book), many in the Lean world are now using Minimum Viable Product (MVP) to designate the smallest thing of value that can be realized.  We prefer using Minimum Business Increments (MBIs) for a variety of reasons, but for the purpose of this blog we don't need to differentiate between them. 

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, having read Mike Cohn's books, had based their sprints on building epics.

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 apparent. However, it was clear that using an MBI 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 MBIs 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 MBIs are used in Agile, go ahead and read this blog). MBI's (and MVP's predecessor for that matter) comes from Software By Numbers by Denne, Cleland-Huang and is called the minimum marketable feature (MMF):

"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 MBI, 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 MBI. But using an MBI 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, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
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
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban