Do you have trouble fitting “all” of the necessary work into an iteration? Your managers might want to push you to do more. Or, the product owner thinks you can do more. Or, the team wants to do more (see Beating a Team’s Goal.)
Agile approaches are not about doing more. Agile approaches encourage us to do the least we need to do, to the best of our abilities, to get feedback, so we can do it again. (See Agile Transformation: Practice Change, Part 2 for an example.)
“More” isn’t the goal. “Effective outcomes” or something valuable to the customer or the team is the goal.
It might be time to think about the outcomes you want and to see how little you can do. I’m calling those minimum outcomes.
Why outcome and not output? Because outputs are work. Outcomes offer value in some way to the team or the customer. Seb Rose in his talk at Agile 2019, said value was something that:
- Increased knowledge, or
- Decreased risk, or
- Generated useful feedback.
Notice that this value can be for the customer, the product owner, the team, and anyone else involved in the product.
Minimum Outcomes
I’ve been using a bunch of “minimum” words to describe what I mean. Here they all are, gathered in one place:
- Minimum Viable Experiment (MVE): The smallest thing we can to learn.
- Minimum Viable Product (MVP): The smallest thing we can do to validate a business hypothesis.
- Minimum Marketable Feature (MMF): Something of value to us: gain revenue or acquire a customer or capitalize the expense. Maybe all three.
Note: All of these are Running Tested Features. If they don’t run, if they’re not tested, and if they’re not a feature, they can’t be an MVE, MVP, or an MMF.
In my experience, we use MVEs and MVPs to learn and validate so we can create an MMF.
The MVP is not the entire product. In my view, it’s not even most of the product. It’s the smallest sliver I can deliver to validate a business hypothesis: Will the customer click, or buy, or take some action we want the customer to take?
Minimum to Satisfy a Customer: Minimum Indispensable Feature Set
Some set of MMFs will satisfy a customer. And, depending on your product, you can release now with only a few MMFs.
What about if we need a lot more than one MMF to show value to a customer? I see this a lot in custom work. In that case, Pawel Brodzinski’s term of Minimum Indispensable Feature Set works. The product does not have to have all the feature sets it will have eventually. The product might not even have a working skeleton across the entire product.
Here’s an example. Say you want to create a cell phone for the bottom of the market. What does that phone absolutely need to do? Make and receive phone calls. Maybe we restrict that further and say within the network or within the country. Does the phone need to send and receive texts? I think so. You might not. That’s why the customer/product owner/product value team needs to decide on who the product is for, and what the minimum is.
The MIFS for this inexpensive phone is the limited ability to make and receive phone calls. I would argue for sending and receiving texts as part of that MIFS. Nothing else is part of the MIFS.
We could have more features. Maybe we should. But the MIFS is the phone calling and, maybe, texting.
Minimum for Replacement: Minimum Adoptable Feature Set
What about when you replace a product with a new product? Or, if you port a product? That’s when you need the MAFS: Minimum Adoptable Feature Set.
Years ago, one of my clients moved from a client-server to a cloud-based product. They didn’t want to duplicate the bloat from the client-server. They created their MIFS, the minimum the customers could use. It wasn’t enough for about half the customers. (Notice it was enough for half of the customers!)
The client continued to add MMFs, one at a time until more than 90% of the customers were happy. Then, the product value team did a very smart thing—they visited the customers who wanted “more.” They discovered an entirely new potential product. That product would attract a different customer base.
Outcomes Matter
Each of these minimums offers a particular outcome for the team, the customer, and/or the business as a whole. If you focus your stories on providing more outcomes, maybe you don’t have to push more into an iteration. (The next post is about that problem.)
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Consider Product Options with Minimum Outcomes Opinions expressed by Java Code Geeks contributors are their own. |
