In this video, we will discuss what is a minimum viable product? How to easily convert a product backlog into a story map? And, how to use that story map to identify our minimum viable product?
Hey friends. Welcome back to the channel. If you're new here.
My name is Vibhor. I am an Executive, Agile & Leadership Coach based in Toronto, Canada. And this is the eighth video in an ongoing series where I'm trying to simplify the process of planning an Agile product, starting with product vision, followed by product roadmap, release plan, finally, learning how to create product backlogs, follow effective bite-sized user stories.
So if you're a scrum master or an agile coach consider subscribing to learn some actionable and super effective ways to be Agile. There are timestamps available, so feel free to skip around the video if you feel like it. But for now let's get started.
So what is an MVP or a minimum viable product? Minimum viable product as a concept was popularized by the book, the lean startup by Eric Reese. In his book Eric Reis defines a minimum viable product as that version of the product, which allows a team to collect the maximum amount of validated learning about customers with the least effort.
Now within the Agile community, the word Viable in the minimum viable product has caused a lot of confusion. The word minimum is pretty straightforward, the least effort. Viable tends to be the word that people debate when the debate about minimum viable product.
Keeping with the concept, which is the core to lean startup, Viable is anything that is validated by asking three simple questions. Do people want this thing? Will people pay for this thing?
And is there a place for this thing in the real market? Unlike a prototype, a minimum viable product, needs to be validated by a measurable experiment in a real world market. With a prototype, you might make a little paper mock up, show it to a few friends and say, oh great!
This is working really well. The minimum viable product on the other hand is designed to get us thinking, not just about individual users or individual people, but rather about markets. How can we make this artifact and put this artifact out in the real world in a way so we can measure whether there is a place for it or not.
This is how we get from, oh, it seems like people like the thing, to, I know enough about the market, I know enough about the thing I'm testing that I'm comfortable committing ahead of time to what the success will look like. In short, a minimum viable product is nothing but a product in its simplest form. Based on the context of this form can be different for different types of products.
Meaning that a minimum viable product can range from a demo video, like in the case of Drpbox, Drpbox created a demo video as an MVP. To a working software prototype. Okay.
Now that we know what an MVP is, let's identify an MVP for an example product. If you're watching this video series for some time, you know, that we created an initial product backlog in the last few videos. Prioritized it and then broke the high-level features or epics into smaller workable user stories.
Let's imagine, for example, we are developing a website to sell various kinds of products online. An MVP, in this case, would be a minimal website with a minimal set of functionality that the potential buyers can use and provide us with the necessary feedback. With this example in mind, our prioritized initial backlog would look something like this.
With managed product catalog, find product, examined product, sign up/ sign in, add to cart, place an order, make payment, make shipment, cancel order, and submit feedback, as prioritized features or epics vertically stacked over each other. We then decompose these high level features or epics into smaller user stories that the team can work on in batches. After splitting epics into smaller user stories, our product backlog looks like this with prioritized user stories beneath every epic.
If you look at it carefully, this is just a prioritized list of everything we need in the website. In order to provide the value to the customer and gain the feedback in the shortest possible time, we need to identify the minimum set of functionality or the minimum viable product that the potential customer can use. When working with prioritized backlog, we typically pick the top most items from backlog and put them in our release backlog until our team's capacity is exhausted, or when the team feels picking additional items would not be possible, given the number of people in the team.
Let's imagine that this exercise gives us 10 user stories in the release backlog like so. But do these stories together constitute an MVP? The two features or epics that this release will deliver our managed products for the seller, and find products for the end user, the buyers.
So the only functionality that the end users are getting is the ability to find products on our website. They can't research or see details about the product on the website to make buying decisions. Neither can they buy any product.
So is this a minimum viable marketplace website? I don't think so. A prioritize product backlog with user stories stacked on top of each other is not of much use to identify the minimum viable product or functionality.
So does it mean that all the work that we have done in the past creating the prioritized product backlog, was a waste! No. Not at all.
Why? Let's find out. With all the user stories and epics already prioritize in the product backlog, all we have to do is make a slight change.
Currently the epics and user stories in the backlog are stacked vertically on top of each other. If you simply drag all the epics and stack them sideways, we immediately start to see something really interesting. We could see the steps, a user will take while interacting with our website.
First, the seller will manage the products. A buyer then can find the products and research the products. If they like what they see, the buyer will then sign up or sign in to the website to add the selected product to the cart followed by placing the order, making the payment and selecting a shipping method.
This is what most people call a story map. It helps in mapping user stories, visually arranging them in a two dimensional format. The vertical order denotes priority while the horizontal order represents steps that a user will take to perform actions in the system, also known as the user journey.
Now that we can see a user journey clearly mapped out, let's identify the minimum functionality or MVP that will appeal to the potential buyers coming to the website to place an order. We do it by looking at the first epic, the first column in the story map, and asking our team to collectively identify the minimum set of user stories required to fulfill the basic need of the end user. We then draw a line below the last user story selected within that epic.
Similarly, the next Epic in sequence will give us basic search and browse by category, user stories for the end user, the online buyer. Repeating this exercise horizontally across the story map will give us all the user stories required within our MVP. All we got to do now is connect the horizontal red lines like so.
Everything above the red line represents, the minimum viable product. So they have it. Now that we have a way to identify our MVPs in the following video, we will learn how to estimate user stories in the story map so that we can determine a scope for our upcoming release.
If you liked this video, then give it a thumbs up subscribe, and don't forget to provide your valuable feedback in the comments. I'll see you in the next video.
