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 Minimum Marketable Feature 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? 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.

Technorati Tags: Lean-Agile

tag with del.icio.us