The Agile BA: In Search of the Elusive MMF
Many agile teams are familiar with the requirement artifact called the User Story. I often teach agile requirements in organizations and my favorite analogy for the user story is a lightweight use case on a 3×5 card. I tell everyone it’s not a ‘good’ analogy, but it does work for envisioning. Another way to look at a user story is that it defines an “executable chunk” of functionality that can be completed within a team’s sprint interval. So that bounds the story in size and complexity. It also dictates that it needs to be demonstrable in the sprints’ review; supporting a done-done state.
Often in agile teams, singular stories don’t have sufficient mass or impact to effectively be VALUE-ated by the team or customer. I frame things in terms of themes of stories, which is a common way of bundling stories together that have value and meaning as a collection. Not only does it help in developing sets of meaningful functionality, but if you prioritize at the thematic or collection level, it greatly simplifies your prioritization. It also has more meaning from the customers’ perspective; since they tend to think in terms of features or workflows and not the more granular stories[1].
A variation on this theme (pun intended) is the Minimal Marketable Feature/Product or MMF/MMP. This concept originated in the Kanban and Lean communities. Eric Ries also explore it quite a bit in his Lean Startup [2] book. Essentially, it’s the same as a theme, but it brings to bear the notion of deliverability, marketability, and overall customer usage.
Quite often an MMF/P is larger than a theme. It could be equivalent to a Larger-scale Epic Story and require many sprints and/or teams to complete. However, once completed, the team will usually physically deliver the MMF/P to the customer; for example, pushing it into a production environment.
MMF Driving Synchronization and Clarity
Recently, I’ve been coaching teams that are struggling with their focus. There’s an anti-pattern that affects many teams where they start sprinting before they understand the business case and intent for their release(s). Sure, they’re delivering a continuous flow of stories. But they don’t necessarily understand the minimal set of functionality that their customers are looking for so the usability and cohesive value can be missing.
Not having this clearly articulated up-front becomes a fundamental problem for them. Quite often their customers have an expectation of delivery that are quite different from what the team is sprinting towards delivering. Consequently, there’s no collaborative clarity around what the MMF or MMP is between the team and the stakeholder.
One nice way to connect the two back together is to establish a view towards each releases’ MMF. Part of defining the MMF is the round-trip discussions that occur as the teams estimate and/or size up the stories and features within the MMF. The customer reevaluates whether they truly need that functionality given the investment of time. This collaboration dove-tails quite nicely into release planning, which I’ll be discussing in more detail in future articles, as the team narrows into fitting the MMF into a specific release window.
I’ve even seen multiple sorts of MMF’s developed for release planning; for example, a UX MMF that tries to capture usability and interaction flows vs. the cost of implementing them. Or, similarly, an Architecture / Refactoring MMF that tries to guide these sorts of trade-offs within a single or series of planned software releases.
MMF or MMP Simplicity
When a team is defining their minimal marketable feature or product, I want it to fit on a single sheet of paper. I’m looking for the elevator pitch or ‘essence’ of the product to be described.
I often ask for what needs to be in the product to be defined, but also what doesn’t need to be in the product. Occasionally, I use a “What’s IN versus What’s OUT” chart to get the point across. It defines the must haves and the must not haves for the MMF (or MMP). It turns out the crucial part of the chart is the gray area in between these two dimensions and the discussions that surround understanding the minimal set of functionality.
Often features will move back and forth. Features will get broken down and some aspects move from one column or the other or they are removed entirely. These are usually quite dynamic and potentially heated discussions as the teams are pushing back on what’s feasible and the stakeholders are demanding more. The common denominator in the discussions is priority and value; trying to keep everyone focused on what’s truly important to solve the customers challenges.
So, no Gold Plating or Wishful Thinking allowed!
Let me give you an example to help illustrate this concept. If we were doing a simple collaborative white-boarding tool for agile teams, the following example in Figure 1 might be a reasonable MMP definition to start discussions across your team.
Visually as we added something to the left, we’d need to either de-scope something or move it off to the (white) or (gray area) for further discussion. They are an implied BALANCE within the chart; that is the work detailed within the MMF is feasible for the team to deliver. And you might ask—who determines where it’s feasible? Why, the team themselves!
Caution: There is Minimum. Then there is Viable
There’s a wonderful Harvard Business Review blog article where David Aycan discusses additional nuances associated with the notion of an MMF. He makes the point that quite often today, in our fervor to hit the ‘minimum’, we over-simplify features and products and lose customer and business viability.
I haven’t seen this pattern that much myself; I usually see the reverse, or teams incessantly trying to build “too much”. But, he connects it to Eric Ries’s Lean Startup work and I have been around enough people who are passionate about those ideas that I can see it happening. Regardless, I’d recommend you read his post.
I think the key is for us to focus on minimal and viable as much as possible when we’re framing reactions to our customers’ needs.
Finally, a Trip to MoSCoW
I first encountered the MoSCoW method for prioritization within the DSDM agile methodology . DSDM lies within the agile family of methods, but is nearly unused in North America. It is much more popular in Europe and leveraged mostly for traditional, larger-scale projects. It has some interesting dynamics that are similar to RUP-style methods.
MoSCoW prioritization is a technique for breaking requirements, or stories & features, down into four specific categories for consideration, discussion, and execution. They are:
- Must Haves – will not release without these features and capabilities being present
- Should Haves – high priority features
- Could Haves – moderate priority, fit if time allows, but deferrable
- And Won’t Haves – features negotiated out of this release for now
When prioritizing your backlog, it helps to place these four ‘buckets’ on a wall or table and to visually discuss and move stories around from one to the other.
Many groups come up with some sort of ratio that helps with this. For example, out of 100 stories, perhaps only 10-20% should effectively be Must Haves and 20-30% might be valid Should Haves. This gives you some general guidance on how to compose stories into an MMF or, more often, an MMP definition.
You might want to try Moscow as a facilitative technique when you’re prioritizing. My experience is that it helps to drive discussion and encourages the team to wrestle with truly “must haves” versus everything else.
Wrapping Up
There is never enough time nor sufficient team capacity to do everything. Yet, today’s leaders always seem to be pushing teams beyond their abilities; creating unhealthy tension and the possibility of team’s disastrously committing to more than they are capable of delivering.
Instead, the notions of Minimal and Marketable help teams and stakeholders define a clear set of value-based functionality that can be negotiated before committing to a release plan. Another attractive aspect is that they form a ‘baseline’ understanding that can be adjusted based on the teams challenges and changing business needs.
Whether you are part of an agile project or not, consider leveraging MMF’s as part of your project chartering and commitment processes to focus in on the minimal set of customer expectations that still provide high value.
Thanks for listening,
Bob.
Note: parts of this article are inspired by Bob’s forthcoming 2’nd Edition to Scrum Product Ownership: Balancing Value from the Inside Out, which will be available on Amazon in early March 2013.
Don’t forget to leave your comments below.
[1] A common anti-pattern is for teams to break stories down into too finely grained units. For example, only having 1-2-3 point stories. The intent is to have fine visibility, but the effect is to get lost in the ‘weeds’ and lose the big picture of the sprint and release.
[2] Eric Ries, Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses