Minimally Marketable Feature

The Project Lockhart team was stacked with high performers and chartered with a clear mission, to simplify, unify, and orchestrate firewall security policy, for Cisco security products, from the cloud. We had organized around core agile principles, choosing scrum, and were executing one week sprints with two teams. The team had embraced CI/CD, delivering sprint increments every week to production in the cloud. We had supportive and engaged leadership. We were ready to build.

The challenge we faced was as mundane as it was difficult to solve in practice. There was a lot of pressure on the team to execute and this coupled with inadequate backlog decomposition and refinement practices resulted in churn, inefficiency, and lack of alignment. Those familiar with this situation might have recognized the symptoms:

• Sprint refinement happening "just in time" with teams carving off just enough work for a sprint from a large work object at the start of a sprint.
• Frequent shifts at the top of the backlog, leaving engineering with a sense they were playing whack-a-mole with stories.
• Most work either in large open ended "buckets" or in small stories which resulted in an inability to project team progress forward, even with good team metrics.

Flexibility and varying work size is desirable in a backlog, but there are limits. It is just as ineffective to deeply refine a backlog as it is leave it grossly ambiguous. It is about striking the balance.

The initial work breakdown started with capturing the high-level program requirements in a spreadsheet. The team has selected Jira for managing the work, so naturally each line item in the spreadsheet ended up as an Epic in Jira. In this way, Epics were being used as containers for bunches of stories with little other structure and this approach has some shortcomings.

• Open Ended - A requirement as a "bucket" without clear outcomes can suffer from scope creep and with no clear way to limit it. For example, "As a user I want the product to have a good User Experience so I can work with the product easily".
• Lack of Alignment - Ambiguity in the requirement statement is open to interpretation. This can result in ineffective and contentious debate during refinement meetings.
• Difficult to Prioritize - Everything was important and there was little insight into how big the (unbounded) Epics were. With pressure to "show progress", many epics were started but little was getting to done.

View fullsize

The MMF constitutes the value achieved at the inflection point between realization and incremental value.

One might observe that the use of MVPs (Minimally Viable Product) could help rectify the problem. We had attempted to introduce the concept however we quickly discovered the team had many interpretations of exactly what an MVP was, ranging from demo code to full blown product. We needed a new concept, one that could be developed to meet the needs of our team and without attachment to preconceived notions. In response, I introduced the Minimally Marketable Feature (MMF).

We defined a Minimally Marketable Feature as something that enabled a single end-to-end use case (minimal scope) and delivered value to at least one customer (marketable value). This simple viewpoint worked to curb against large unbounded work as well as "wouldn't it be cool if..." ideas that really did not provide marketable value to a customer. If someone was not willing to buy it, it wasn't an MMF. 

The team was operating with good agility and were wary overarching process. An approach like this could be interpreted as another attempt at a Product Requirements Document (PRD), typically large documents that may take months to develop. So, simplicity was key. We limited the MMF write-up to a wiki page, ideally no longer than a single piece of printed paper, taking a cue from the A4 concept. It contained the following attributes:

• Name - The Name of the MMF
• Business Goal (the value) - Single statement identifying the business problem and why it should be addressed
• Size (the cost) - Rough SWAG (in story points for our team)
• Product Owner - The business/technology owner of the MMF
• Champion or Customer - Executive or Customer to partner with the PO
• Scope Guidance - Use case focused on the outcome with KPIs indicating how it might be measured. Explicitly not a set of requirements or a specification.
• Assumptions - Including dependencies, scope limiting assertions, etc.
• Initial Breakdown - Fewer than 5 high-level stories that could be used to seed Jira

This simple document, containing both value as a use-case and cost in story points, gave the team a way to facilitate productive discussions about tradeoffs. We transitioned from debates over whether or not something was important (it always is) to discussions about whether or not the proposed block of work was aligned with the MMF goal and more or less important than the work above it. I witnessed the culmination of this behavior when, during a heated refinement session where we were trimming scope, the lead engineer was asked, "Are you ok with this from a technical perspective?" The response was, "I'm not happy about it, but I understand we need to shift our focus, this is good enough." Achieving "good enough" is what we were after.

A benefit of containing both value and cost measures allowed the product and engineering teams to share a common language. Often product is focused on value, "This will have a huge impact on the market..." and engineering on cost, "The work is about 150 story points...". Discussing both value and cost in the same context provided us a way to determine where that MMF inflection point really was and whether or not it was worth investing in. Without such a construct, product and engineering teams can often talk past one another because they are speaking different languages. There was benefit within the engineering teams as well. They aligned around what the "good enough" line was and as a result could have productive debate about what tradeoffs needed to be made. Following naturally from this, backlog prioritization became simpler and less contentious.

The net effect of this effort was an all-out attack on waste, significantly improving the efficiency with which we delivered value to market. There was the reduction of the churn at the top of the backlog (mura), resulting from lack of alignment and focus and leading to whack-a-mole story execution. In addition, better understanding of priority and scope across the full team meant that WIP limits were seen as collectively beneficial, rather than as arbitrary or unnecessary. This helped reduce the total work in progress (muri) leading to smoother flow.

Of course, this leaves muda, or waste in process, which will be the topic of another article. Thanks for reading and as always feel free to comment or contact me directly.