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 Dropbox, Dropbox 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.