We needed to find the Minimum Useful Feature Set (MUFS).
The practice and principles I describe below helped us discover the MUFS and has since been used in a few more projects and has been a great introduction to Lean for many.
What is a Minimum Useful Feature Set?
A MUFS is the smallest amount of work that provides the most new market value. If that definition seems vague and subjective it's because it is; and defining the most valuable work for any business to endeavor upon is not easy - people struggle at it everyday. One thing that is clear about a MUFS is that the value from a MUFS is not necessarily cash flow coming in from customers. Many times a MUFS value can be realized from such things as internal learning from a prototype, the ability to do some usability testing on a subsection of what will eventually be delivered, or simply realizing that a critical user story has not been satisfied. Thus a MUFS does not necessarily mean "something that can be deployed to customers."
Sounds complicated - where did you get this stuff?
It's an application of Lean, the Minimum Useful Feature Set term comes from Implementing Lean Software Development from Mary and Tom Poppendieck. The MUFS is a result of eliminating waste - specifically waste from what I'll call Kitchen Sink Marketing - when software tries to satisfy everyone in a market all at once by including every possible feature instead of satisfying the most valued part of the remaining market successfully in increments.
So how do I figure out the MUFS when there are so many potential features?
To discover the MUFS you can use a technique that you probably are already familiar with, but apply it a bit differently. The Planning Game has been used by many development teams to estimate the development effort of a User Story after Features are chosen by a business. Later in this article I'll present how to use the Planning Game in a new way, with a different group of people at an earlier stage in the project in order to eliminate waste and identify the MUFS. However, before we get to how this works let's talk about why it works.
Latest Responsible Moment Decision Making
James Shore has a great post Beyond Story Cards that explains the Latest Responsible Moment Decision Making well. I'll be using a lot of his material here, so let it be known that he deserves credit for this section.
'Latest responsible moment' is a core agile idea. The term comes from Lean Software Development. The idea is that you want to put off decisions as long as you can: to the latest responsible moment. But it's the latest responsible moment, not the 'last possible' moment. That wouldn't be responsible. - James Shore
Lean Manufacturing uses a principle called Just In Time. Like most things in Lean, the fundamental purpose of Just In Time is to eliminate waste. Instead of each station on an assembly line running at full capacity and pushing inventory out of the station and into a pile, a storage facility, or somewhere else that station only runs fast enough for the next station to pull what is needed just in time to do it's work to meet the pull of the following station etc. This avoids materials being consumed without any realized value. When materials are pushed out of a station and into a pile or storage area they have incurred the cost of being created, the cost of being transitioned to the storage and will incur the cost of being found again for consumption and the cost of being transitioned back to wherever they are needed - if they don't expire, and if they are needed, which sometimes is not the case. In software we don't have a constrained amount of raw materials going in and tangible goods coming out of an assembly line. Instead we have a limited amount of decision power going in and software being delivered at the end.
To make sure that we are not creating decision waste we should make decisions only when they are needed - at the latest responsible moment - when you have the most information, that information is the most accurate and making the decision is the most valuable thing that can be done.Thus with Latest Responsible Moment Decision Making decisions are pulled into existence because they are demanded by something that needs to consume that decision immediately. This is opposite of what we often experience in software where decisions are made and pushed into later phases of development with the belief that those decisions will be needed. Those pushed decisions may not be valuable at all and would end up in the waste section of the image above by not contributing to the delivery of the software. Even if the pushed decisions end up being needed and inside the focus-time cone above they still incur the waste of decision inventory storage and retrieval from somewhere such as your email inbox or a spec document.
How to define a Vision with the Planning Game
This is how we found the Minimum Useful Feature Set by using the principle of Latest Responsible Moment Decision Making.
Prepare you materials
- Set up the meeting, invite the Customer/Customer representative and a representative from each group that will be affected by the project. Some examples include the project manager, the marketing representative, the solution architect, a customer service lead, a tester, and one person from each system that will probably be impacted. Somewhere around a 70/30 business/technical mix of people seems to work well. In total a group of around 10 to 15 people is good.
- Get A lot of 3 x5 index cards
- Find some tape
- Get some markers
- Find a white board or paper
- In your meeting room draw the Latest Responsible Moment Decision Making diagram
- In you meeting room draw the following X-Y chart (to be explained later)
Define a few roles
- The visionary - this is the customer or customer representative. The person paying for the project that knows what they want. This person is responsible for making sure that decisions are made within the Focus-Time cone above as indicated by the green vertical line. For fun you can refer to this person as the Focus Waste Engineer.
- The facilitator - the person who knows the Planning Game, can teach it to others and can politely settle disputes. This person is in charge of making sure that the group is making timely decisions as indicated by the orange horizontal line above. For fun you can refer to this person as the Time Waste Engineer.
- The scribe - no matter how successful the facilitator is at minimizing decision waste, people will discuss tangential things that may be valuable. The scribe records them, mostly to comfort group members that the important stuff they say isn't just gone forever.
Explain Latest Responsible Moment Decision Making
Supplement the description above with some information that Lean was established by Toyota over half a century ago and that it has been used successfully by companies around the world for many years to gain a competitive advantage in their market.
Create Feature Cards
Feature cards are nothing more than Story cards, but for features, or a Theme of stories if you prefer. I just use a different name so that if/when you get to the normal Story Cards or Story points part of your project people don't get confused.
- A feature card is a 3x5 index card with the name of the feature on the front and behaviors of the feature on the back
- It's a 3x5 because there's no room to record decision waste by making too many or too detailed decisions
- Feature Cards are placeholders for future conversations
- Feature Cards are not the spec, the spec comes later (if at all)
- Don't worry about spelling, punctuation etc
- If a behavior doesn't fit on one line it's probably more than one behavior in disguise
Play Planning Poker
This is much like your basic planning poker. However instead of playing poker for development effort you are instead going to play poker twice, once for Value and once for Ease of Deployment. Value in this case is defined by the amount of good a feature will contribute to achieving the Vision. Ease of Deployment is estimated instead of cost of development for a couple of reasons. The first is simply for information display purposes - we want the good stuff in the upper right since that's how most people expect to read the graph. Also, cost of development is often viewed as just the Dev and QA efforts and doesn't include other costs such as sales staff training, customer service impacts, marketing efforts, etc. - and all of that stuff is real cost so it should be included. Thus, estimate the 'ease of deployment' instead of the 'cost of development' to remove that ambiguous 'development' word from being a stumbling block.
As you play planning poker you'll need to record both the Value and Ease Of Deployment values as noted by the "V=80" and "D=30" on this example Feature Card
Discover the Minimum Useful Feature Set
Once you have created all your Feature Cards and played Planning Poker for Value and Ease of Deployment you tape up each feature at the appropriate place on to the Value-Ease of Deployment graph shown above.
At this point you'll have a very easy to understand visual representation of the relative ROI ratio of each feature.
Now starting at the bottom left of the graph read a feature and ask if the feature should be included in the MUFS. You may have to remind the group at this time that just because a feature is not in the MUFS it doesn't mean it won't be delivered, it just means it won't be planned for the first development cycle and that cycle may or may not end in a customer release. I don't have any defined voting or other process for doing this step in identifying the MUFS. I've found so far that one isn't needed and that general discussion is valuable and "close enough consensus" will be achieved. By starting in the bottom left with the features that are hard to deploy with low value the decisions are easy and the group will get comfortable with this process and establish a rhythm. When the group indicates that feature isn't part of the MUFS remove it from the chart and tape it up somewhere else for display. Leaving it up on the side is a gentle reminder to people that the feature isn't lost forever, it could still be delivered later. As you start moving from the bottom-left to the top-right picking off features the discussion will get more involved and the weighing of pros and cons will become more lively. This is an indicator that you are close to identifying the green MUFS arch shown in the Value-Ease of Deployment image above. After you've crossed that arch and get very close to the top right you'll find that the decisions are again easy and not much discussion is needed.
When you are done with all the Feature Cards the MUFS is the collection of features left taped to the value-ease of deployment chart - you'll need to mark each card as part of the MUFS so that you'll know when they come off the board. The smaller the arch is - the higher the ROI ratio is for the MUFS.
Posts
