So, let me take a few seconds to explain why vision is not the why of a product.
What is a roadmap, the initial product backlog creation or requirements
gathering, as some people call it.
How to split a user story.
Finally, let's create a release plan.
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 tenth and the last video of the ongoing series, where
I've tried to simplify the process of planning and Agile product, right from
vision to an actionable release plan.
So if you're a scrum master or an agile coach consider subscribing to learn
some super effective ways to be Agile.
Before we can create a release plan, we need to know the
things, the information, the data required to create a release plan.
The first prerequisite for creating release plan is
an ordered product backlog.
Now, if you're watching this tutorial series for some time,
you know that we created a prioritized backlog in this video.
The link to this video is in this corner or in the video description,
if you're watching this on YouTube.
We then went a little further in this video and ordered our prioritized backlog
by converting it into a Story Map.
Which later helped identify our first minimum viable product or MVP.
The second prerequisite for creating release plan is estimated user stories.
If you started to watch this tutorial series in this video, then guess what
we learned how to quickly estimate the user stories in bulk with an easy to
use bulk estimation technique in this video, which again, you can find in this
itty bitty convinient little corner.
The third and the last prerequisite for creating a release plan
is the team's velocity.
For those who are unfamiliar with the term, a team's velocity in the most
simple words is the total of all the story points the team burns, in a single sprint.
And of course the sum is not always constant.
It may vary every sprint.
And for this reason, the actual team's velocity is a rolling average of
four to five sprints in succession.
Velocity, as they say is the most common, but widely misused
metric in the Agile space.
Now the good, the bad and the ugly of the sprint velocity deserves
a separate video on its own.
In this video, however, we will use it to create our release plan.
Now, you may come to me and say, Vibhor, what are you talking about?
We don't have a velocity.
The team has not started sprinting yet.
And you're right!
Without Sprinting you can't certainly have a team's actual velocity, but what if I
tell you that you can somewhat accurately guess the team's velocity for the purpose
of creating the release plan, even before the team has started the first sprint.
Here are two ways that we can use to guesstimate our team's
velocity in the beginning stages.
First is using all the teams, historical data.
If the majority of the team members within the team have worked together
in the past on another Agile project,
in that case, the team will likely continue delivering future
Agile projects, including this one, with the same velocity.
But let's not accept the theory as it is.
Let's ask WHY.
Why is it safe, to assume that the team will continue delivering
with the same historical velocity?
And the simple reason is trust.
The single most important factor in sustaining life on earth.
If you look closely, you will find that the team's velocity depends
less on its individual members, expertise and skills, and more on the
team members mutual understanding.
Tom knows that he can rely on Sally when she commits to testing or coding
a particular unit within a particular timeframe, making him safely commit to
work on the next piece of functionality in the pipeline, in the upcoming sprint.
Higher, the understanding or trust among the team members higher the
stability of the team's velocity.
So if the team members have worked together in the past, use
historical data to predict the initial velocity of the team.
Now, if the team has not worked together in the past, the second way to
predict the team's initial velocity is through the teams available capacity.
Here's how we do it.
Let's say in an ideal scenario, the total capacity of the team in
a two week sprint is 250 hours.
Of course, I'm assuming that we all know how to calculate a team's capacity.
If not just ping me or write in the comments and I'll
be more than happy to help.
Moving on.
The next thing we do is look at our Story Map, or prioritized product
backlog, if you don't have a story map.
Although you should have one, it is highly recommended, and ask our
team to select such user stories that they think they will most
likely work on in a single sprint.
They can also simply select the first few user stories in
the first MVP on the story map.
After the selection is made, the team will then break the
first user story into tasks.
Tasks like coding, updating, automating testing, et cetera.
Followed by estimating how long it will take to complete these tasks in hours.
For example, for user story A, the coding task may take 20 hours
updating the database, may take eight hours and setting up the
automation may take another 11 hours.
Once the team is done doing this, we add those hours and compare the total
with the team's available capacity.
Suppose this total is less than the team's available capacity.
In that case, we continue breaking other user stories into tasks and estimating
those tasks in hours until we reach our threshold, which is 250 hours.
At that point, we stop since the team clearly can't do more than
its starting capacity of 250 hours.
Well, unless we ask them to burn the midnight oil.
In which case I would suggest you just go waterfall.
Now, adding the story points associated with those selected user stories
will give us our team's initial velocity, but wait, we're not done yet.
This is what we call our team's best case initial velocity.
When creating release plan, you don't just want to do the best case.
You want to put some uncertainty around it as well, for things like vacation,
sick leave, unknown blockers, et cetera, and do the worst case as well.
The way I go about creating a worst case velocity, and it actually
depends upon what your team thinks about it is by reducing the best
case velocity by 30 percent.
So if our best case velocity is 20, then our worst case velocity will be 14.
Now I know you may have lots of questions about the right
and the wrong of calculating the initial velocity like this.
But again, keep in mind that this is our team's initial velocity.
Don't think of it as our final rolling average velocity.
Velocity, as a reliable metric can only be calculated with time and experience.
And the experience comes by completing the actual sprints.
But since we have not started sprinting yet, to create a release
plan, we need a starting point.
And the initial velocity calculated like this is the closest accurate,
if not the most accurate.
Okay.
Now that we have a prioritized product backlog, an estimated story map, and
a good idea about our team's best case and worst case initial velocity, we
can finally create a release plan.
The two most commonly used plans are fixed scope release plan,
and fixed date release plan.
The formulae we use for release planning is the number of sprints equals total
story points divided by initial velocity, for fixed scope release planning.
And total story points equals number of sprints times initial velocity
for fixed date release planning.
Let's first have a look at fixed scope, release planning.
Suppose your boss or the key stakeholders are looking for you to tell them when
the team will deliver the first two MVPs.
Looking at our story map we can quickly calculate the total size
of the two MVPs in story points, which for our example would be
somewhere around 140 story points.
This is our fixed scope that this information about the size of the fixed
scope, using the formula I just shared, we can easily calculate the number of
the sprints, it will take to deliver this scope, to deliver 140 story points.
Since the formula is number of sprints equals total story points
divided by initial velocity.
The best case fixed scope plan would be 140 divided by 20 which is, seven Sprints.
And the worst case fixed scope plan would be 140 divided by 14 equals 10 sprints.
Of course, the assumption is that if you're using two week sprints.
So when the time comes to provide your bosses with the timeframe, you tell
them that the team may take three to five months to deliver the two MVPs.
Next, let's take a look at the fixed date release plan.
This is the case when you boss or key stakeholders ask you to
estimate how much could be delivered by a specific date in the future.
Let's say for example, that the fixed date is 30th of September, 2021.
Looking at the calendar, if the team starts the first two week sprint
on the 1st of July, 2021, we know that we roughly have six sprints
available within the timeframe.
With this information about the number of sprints available, we can easily
calculate the total number of story points that the team can deliver
by the 30th of September, 2021.
Using the formula for the fixed date release plan, which is total story
points equals number of sprints times initial velocity, the best
case fixed date plan would be 6 times 20, which is 120 story points.
And the worst case fixed date plan would be 6 times 14 equals 84 story points.
Again, when the time comes to provide your bosses, the scope that can be
delivered by 30th of September, you would say that the team can deliver between
84 and 120 story points or looking at our example, story map, the team can
deliver MVP1 in full and parts of MVP2.
So there you have it.
This is how we do release planning in Agile.
But before I end the video and this tutorial series understand this.
At the end of the day, a release plan is well, just a plan.
And if you follow along on this journey towards agility, you
will find that plans change.
My advice to you would be to slowly but steadily teach your organization
to stop stressing on Plans.
I've used the word TEACHING and not COACHING intentionally as this
requires teaching and not coaching.
Plans are essential, no doubt, but don't treat plans as markings in the stone.
Change is the only constant.
The sooner we get it, the better we can handle what comes next.
Don't forget to like, subscribe and leave your valuable comments.
I'll see you in the next video.