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.