Get certified - Transform your world of work today


Mitigate Risk with a Minimum Viable Product Approach

16 December 2015

Olufemi Sonuga

I had a conversation the other day with a senior ScrumMaster based in Europe. He had failed to see why I had persuaded my teams in the past to adopt a minimum viable product (MVP) approach to Agile. My reply was simply, "Risk management."

He didn't understand why risk management, so I described a likely scenario: What would happen if he multitasks, and as he's getting getting closer to the end of the sprint, for some bizarre reason the environment crashes or something else detrimental happens? He indicated that he had not experienced such a situation before and that he is a pro at multitasking (alarms went off!). I have been in IT since 1995 and cannot count the number of times that an environment has gone down inexplicably.

I have good reason for applying the MVP approach. Suppose you have a couple of PBIs (product backlog items) in the sprint, and you get the team to collaborate and work on one PBI at a time (also known as swarming). With all hands on deck, the work will soon be done during the sprint. And during this time, a few things are likely to happen:
  1. The team will have one or a few PBIs to show during the show-and-tell exercise.
  2. The amount of uncompleted PBIs will be reduced. (It is not as if the uncompleted ones will automatically be prioritized to the top of the product owner's list come next sprint planning exercise.)
  3. If something dire should happen, there is something to show to the stakeholders during the review, thus making them happy.
If you decide to multitask all the way through the sprint (I am not saying that this is not plausible), it can work, but there is still the risk of something dire happening. Maybe the environment goes down, and you haven't finished one PBI. What happens then? It's almost guaranteed that the stakeholders will not be happy.

I told the ScrumMaster that I will always be an advocate of MVP -- until I see something better come along. As the Spanish proverb says, "A wise man changes his mind, a fool never will."

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (2 ratings)


Robert Day, CSM, 12/22/2015 11:07:56 AM
I'm a little dubious over anyone who claims never to have had systems go down for wholly unexpected reasons, or their work interrupted by wholly external factors. One job I had a few years ago was fortunate in that a terrorist bomb outside the office failed to go off - if it had, having something to show off in the Sprint review meeting would have been the least of our problems, as the server room was on the side of the building nearest the bomb. (No-one would have been on-site at the time, but it could have been three months until we were up and running again. As a result of this close call, we heavily revised our disaster recovery plans. But Sprint objectives would have been well and truly wrecked.)

So well done for giving us all an object lesson in always having a Plan B!

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up