“We Scrum and we plan to deliver our MVP next year”
Are you serious? — Episode 58
Harry is a Product Owner. He has the perfect picture of the product in his head. So together with his team he broke this picture into little pieces and added it to the Product Backlog. Every Sprint Review Harry explains exactly what the team has been doing and the Development Team demos what they built – on their development environments. Harry aims to release the MVP once all items are “Done”, first to pre-production, then to production. He estimates that this will take 16 Sprints, so about 8 months.
Looks familiar? That’s not good. This way of approaching the new product ignores all the reasons to do Scrum: it ignores true empiricism.
What is a MVP (Minimum Viable Product)?
I like this definition at Wikipedia:
“A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.” — Wikipedia
Harry would argue that all the features that he defined are required for the early customers. That may be true. But there is a high risk that Harry’s assumptions are wrong and huge amounts of money would then be burned for nothing.
Is Harry’s release really planned to provide early feedback or is it intended to make a smashing impression? Well, Harry has a perfect picture of the product in his head and calls it the MVP. It’s not a MVP.
What is Scum bringing?
Scrum is all about empiricism: transparency — inspection — adaptation. I wish to emphasise the Sprint Review in this light: the Scrum Team and the stakeholders inspect the Increment and adapt the Product Backlog if required.
Scrum helps you to reduce risks. It exists to find out whether your ideas hold water — the fastest way possible.
Product Owner Harry doesn’t really use the opportunity to inspect the Increment. The stakeholders get a demo of the functionality – on the development environment. They will not have the chance to experiment with the functionality themselves – for months to come. Sure, their feedback on the demo is welcome and is being used to adapt the Sprint Backlog. But it could be so much better!
Nothing beats feedback from actual users in a real-life environment. Those users are bound to come with observations that force you to adapt the product. Or maybe even abandon investments in the product! It’s vital to have this feedback as early as possible. You don’t want to bet on the wrong horse.
Suggestions
A good way to open up discussions is by not talking about requirements but about hypotheses: “I believe that by doing x we will solve y”. Then it’s running experiments: finding out whether a hypothesis is valid or not. You need to have a quick answer to your hypothesis to decide if you need to continue, pivot or abandon the idea. This way you focus on what counts.
What often holds a company back to do this is the risk to scare away potential users with something that isn’t perfect. One way to resolve this is to make potential future users part of the journey. How cool is it to be one of the people that help shape a potentially great new product? These people would accept imperfections because they know that you are experimenting, together with them.
Conclusion
A MVP has enough features to satisfy early customers and receive feedback for future product development. This is not the same as having a first version of a product with all the features to blow your customer’s socks off.
Aiming to build a MVP taking multiple Sprints is fine, but don’t forget to inspect the Increments in order to adapt the Sprint Backlog. The most transparent way to inspect the Increment is by giving (a set of) future users the opportunity to work with very early versions. These users provide awesome feedback and will most probably become great advocates of the product. And who doesn’t want that?
Thanks for reading. Feel free to bang that clap button. You can give up to 50 👏’s. Give it a try if you enjoy this article!
My twitter profile is https://twitter.com/WJAgeling
Thanks to Daniel Westermayr, Maarten Dalmijn, John Clopton and Marty de Jonge and Roel Trienekens for the review comments.
