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[i].

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 [ii]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.

Figure 1, Example of What’s IN vs. What’s OUT chart

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 is 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!

Wrapping Up

We’ll wrap up this post in part-2 next. What I hope you start seeing is the power of the following in your agile backlogs and planning:

• Minimal
• Marketable
• Just enough
• Just in time
• truly compounding, iterative delivery
• and did I say Minimal?

Stay agile my friends,

Bob.