What is so valuable about a Minimum Viable Product?

Quick Thoughts

29 July 2013 • Written by Bruce Keightley

How difficult is it to pare back requirements to establish the true Minimum Viable Product? Bruce Keightley speaks from experience...

From my first job as a Scrum Master, I’ve been using an Excel spreadsheet to record, track and display sprint data. With each new implementation, my trusty spreadsheet has been modified, enlarged, enhanced, poked and prodded until it has become the brittle behemoth it is today – full of smart ideas and loaded with unintended features.

My plan was always to turn it into a web app once the steady stream of client changes reduced to a trickle. I figured it would be a good project to learn about web design and I could do it in my spare time. Now I’m not sure where the road leads to – the road that’s paved with good intentions – but I sense that it is all downhill, and the surface is slippery. It very quickly became apparent that I didn’t have the time or the expertise for this project and so I hatched a different plan.

I became Product Owner and handed over the work to Peter Bayne, our Technical Lead. I produced the complete product backlog and Peter and I had our first grooming session. That’s when the fun started. Peter pointed out that if we wanted to deliver our tool sometime this century, I needed to do some serious culling. And so the process of identifying the Minimum Viable Product got underway. There was much wailing and gnashing of teeth, not to mention navel gazing, soul searching and… well, you get the picture. Together, we came up with the minimum set of features we felt our clients would find useful and Peter started work.

His efforts went on display at our launch last month and we now have a select group of clients who have started using the tool and are providing us with the quick feedback we need. It will be interesting to see how much of the remaining backlog makes it into the tool as a result of this feedback. Our aim is to make the tool freely available to all our clients as soon as we can. Watch this space!

What I’ve learned from this process is how difficult it is to pare back requirements to establish a true Minimum Viable Product. When you have identified a feature and written the user stories that describe it, you form an emotional attachment and that can make it very difficult to ‘let go’. Simply asking “Can we go live without this feature?” is not enough because it is all too easy to answer “no”. Instead you might ask “Is there a manual work around we could use until we are able to implement this feature?

So what is so valuable about a Minimum Viable Product? By focusing on the minimum requirements needed to produce value, we have a much higher likelihood of successfully implementing our project. We can deliver value more quickly and gain valuable feedback about the best thing to do next. In the process, we deliver more of what our clients find useful and valuable and reduce the potential for wasted effort.

In future then, when you don’t have enough time to implement everything in your backlog, think Minimum Viable Product. And as you start to slash and burn, remember, it doesn’t have to be complete or perfect, it simply has to be enough.

Search the Assurity website (Hit ESC to cancel)