Release Plan

Introduction

The first prerequisite for creating a release plan is an ordered product backlog. Please refer to my post on ordered product backlog .. We then went a little further in this post 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 a release plan is estimated user stories. You can refer to the post on estimations where we learned how to quickly estimate the user stories in bulk with an easy-to-use bulk estimation technique.

Team Velocity

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/effort the team burns in a single sprint/release. And of course, the sum is not always constant. It may vary every sprint/release. And for this reason, the actual team's velocity is a rolling average of four to five sprints/release 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 deserve a separate write up on its own. Here, however, we will use it to create our release plan.

Predicting Team Velocity

Before the start of the release. The team has not started sprinting yet and without Sprinting, we 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 team's 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. Teresa knows that she can rely on Roy when he 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 team's 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. 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.

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 team 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, etc.

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 be 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.

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 a 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, etc., 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.

Creating A Release Plan

Now, I see 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. 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 formulas we use for release planning are 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 the 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 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 your 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, 2024. 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, 2024. 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 here we have it now. This is how we do release planning in Agile. 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.

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.

Please share your valuable comments.

#releaseplan #teamvelocity #RollingAverageVelocity