Minimum Credible Release (MCR) and Minimum Viable Product (MVP)
A Minimum Credible Release, or MCR, is simply the minimal set of user stories that need to be implemented in order for the product increment to be worth releasing.
I don’t know exactly when Minimum Credible Release became an established practice, but I do know that we were using Minimum Credible Release as a concept back in the early 2000’s on the Microsoft patterns & practices team. It’s how we defined the minimum scope for our project releases.
The value of the Minimum Credible Release is that it provides a baseline for the team to focus on so they can ship. It’s a metaphorical “finish line.” This is especially important when the team gets into the thick of things, and you start to face scope creep.
The Minimum Credible Release is also a powerful tool when it comes to communicating to stakeholders what to expect. If you want people to invest, they need to know what to expect in terms of the minimum bar that they will get for their investment.
The Minimum Credible Release is also the hallmark of great user experience in action. It takes great judgment to define a compelling minimal release.
A sample is worth a thousand words, so here is a visual way to think about this.
Let’s say you had a pile of prioritized user stories, like this:
You would establish a cut line for your minimum release:
Note that this is an over-simplified example to keep the focus on the idea of a list of user stories with a cut line.
And the art part is in where and how you draw the line for the release.
While you would think this is such a simple, obvious, and high-value practice, not everybody does it.
All too often there are projects that run for a period of time without a defined Minimum Credible Release. They often turn into never-ending projects or somebody’s bitter disappointment. If you get agreement with users about what the Minimum Credible Release will be, you have a much better chance of making your users happy. This goes for stakeholders, too.
There is another concept that, while related, I don’t think it’s the same thing.
It’s Minimum Viable Product, or MVP.
Here is what Eric Ries, author of The Lean Startup, says about the Minimum Viable Product:
“The idea of minimum viable product is useful because you can basically say: our vision is to build a product that solves this core problem for customers and we think that for the people who are early adopters for this kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.
So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.”
And, here is what Josh Kaufman, author of The Personal MBA, has to say about the Minimum Viable Product:
“The Lean Startup provides many strategies for validating the worth of a business idea. One core strategy is to develop a minimum viable product – the smallest offer you can create that someone will actually buy, then offer it to real customers. If they buy, you’re in good shape. If your original idea doesn’t work, you simply ‘pivot’ and try another idea.”
So if you want happier users, better products, reduced risk, and more reliable releases, look to Minimum Credible Releases and Minimum Viable Products.
You Might Also Like
Continuous Value Delivery the Agile Way
How Can Enterprise Architects Drive Business Value the Agile Way?
How To Use Personas and Scenarios to Drive Adoption and Realize Value
Comments
- Anonymous
September 03, 2014
The comment has been removed - Anonymous
September 04, 2014
@ Dragan -- Using the term can help build a shared vocabulary, and by having a shared vocabulary you create shared understanding. In my experience, creating the shared understanding makes systems and people way more efficient and way more collaborative and way more effective.