Release Planning with Scrum

As mentioned in the Fixed Price Fixed Date Scrum post, there are some techniques you can use to help you build a release plan that you can communicate to customers. This release plan can also been used as the basis of a contract, if required. Below are 7 steps to help you do this.

1. Understand the goal.

Before you embark on a project you need to understand the key reason you are doing it. Maybe something like, we need to improve our efficiency to handle 20% more bookings per day. Understanding the core purpose for a project or release is important. It is something you need to revisit regularly in the project to confirm that you are on track. If you can’t figure this out, maybe you need to reconsider why you are doing the project at all.

2. Understand the customer requirements.

The next thing you need to tackle is understanding the customer requirements. You might think this is simple and the basis of how you have started every project in the past, but beware. I have seen lots of projects were the requirements are statements of how something will be achieved in the application. E.g. Add a logon screen to the application. In my terminology this is not a customer requirement. The customer requirement is more likely to be something like, make sure only authorised people have the ability to do x. The reason it is important to understand the customer requirement is that it gives the team flexibility on how to implement the requirement later. If you contract with a customer to add a logon screen you are pretty much tied into that. If you contract to ensure only authorised people have access you could potentially implement this as a logon screen, or single sign on, or maybe something else.

Another important point is to understand why the customer has that requirement. Be careful here. When chatting to customers, if you ask “Why do you want that?” They automatically think you want to talk them out of the feature. Maybe because we’ve been doing that in software for so long. You don’t want to ask this question to alienate and cause conflict with your customers. You want to ask it so that you can make sure any assumptions you make about how this needs to work can be validated against the actual business benefit for the feature. Try asking: “Help me understand why this is important?” or What benefit is this going to bring to your business?”

It is best if you arrive at these requirements in a workshop setting which could take 1 or 2 days depending on the complexity of the project. It’s also a good idea to include some or all of the project team that will work on this, in this workshop. I know it is sometimes scary to put developers in the same room as customers, but a lot of problems in software are due to communication failures. The closer the people creating the software are in understanding to the people using the software, the more likely it is to be successful.

If this really is impossible, try to minimise the number of points of translation there are between the end customer and the project team. Every time there is a person between the team and the customer, that’s an opportunity for misunderstanding to creep in. So if customers talk to product managers, and product managers talk to the team, you have one additional point of translation. If customers talk to sales, who talk to product managers, who talk to project managers, who talk to analysts who talk to architects, who talk to developers… well let’s just say that’s not very agile, and I wouldn’t be surprised if you have some communication problems and end up building the wrong thing regularly.

If you are familiar with Scrum then you will realise that the output of this workshop is the initial Product Backlog. It is best if the features are stated as user stories, have a business reason and value attached, as well as some acceptance criteria for how you will know when you’ve achieved this feature.

If you are not familiar with Product Backlogs, then think of the output of this meeting as a list of customer requirements at a fairly high level, where the reason for each feature is understood, and that they are roughly ordered by priority.

If you want to take this one step further you can create a Story Map.

3. Prioritise and Estimate the Backlog

Now that you have an initial Product Backlog or list of requirements it’s time to start estimating them. You might wonder how we can estimate them when we don’t even know how we will implement them, but let me assure you it is possible, especially if we separate the concept of commitment from the process of estimating.

Here is what we do. We pick one requirement or story (as I will refer to it from now on), and assign it a value. Say ’3′. It’s best if this is one of the smaller requirements, but not the smallest you can imagine. The 3 here does not have any associated time unit. Often we call the unit ‘Story Points’ . This story becomes the reference point for other stories. Now the team (the people who will actually do the work, not the manager or the architect or the analyst) estimate the rest of the backlog in Story Points. The estimates are all relative to the reference story. So if one story is easier it might be a 2. If another story is almost 3 times as complex as the reference it might be an 8. Some might be so massive we just give them a huge value like 100.

There is a lot written about planning poker and other estimation techniques as well as the reason for using only certain numbers for estimates which I won’t go into here. I will just mention 2 of the benefits of using story points for estimates.The first is that as humans we are much better at estimating relatively (the dog is twice as big as the cat) than explicitly (the dog’s weight is 10.3 kgs, the cat is 4.7kgs). The second is that if the speed at which the team deliver software (lets call it their velocity) changes, then we don’t need to re-estimate all the work, we just do a different calculation for how long it will take the team to do 30 Story Points.

Once we have some estimates the customer might want to review the list and change some priorities once they realise the relative effort. If something which was medium priority is relatively small it might make them more keen for that feature, and if something else is relatively large it might make them less keen for that feature.

If the team find there are a lot of items which they have estimated as 100 (the highest number used), they might want to break these down a bit further so that we are not in essence grouping things that might be 200 and 500 together. Or they might want to rebaseline their reference story so that the story point scale (1 to 100) covers most of their larger stories.

An important aspect to realise about estimating upfront like this is that we are consciously deferring the details to later. But, in affect by choosing an estimate earlier what we are saying is that we will limit the solution to something we can do in this agreed size. This is one of the reasons it’s important that the requirements don’t specific a specific implementation.

Now you should have a Product Backlog with a list of stories, each one with a priority and estimate in Story Points.

4. Calculate the teams velocity

Okay that’s all very well, but let’s face it you need to put a time line against it right? For this we need to figure out the team’s velocity, that is the speed at which they can deliver story points. Hopefully you will agree that the velocity is governed by many things: how many people there are on the team, how experienced they are, how good their engineering standards are, how much domain knowledge they have, how well they understand the technology they are using, how much they are interrupted during the day when trying to do their work, etc, etc. Instead of consulting a crystal ball to figure out what the velocity is given all these factors, we do something much simpler. We measure it. Studies show that it takes a team 3 sprints to establish a relatively predictable velocity, that is until one of the factors which impacts it change significantly.

The way we measure this is that we take the top items of the backlog and we work on them. It is important that we only count story points towards velocity when items are finished. Here finished means: designed, coded, tested, bug fixed, and ready to ship. Remember with agile we don’t have time at the end to do these things we do them as we go. The benefit is that while you are measuring your team’s velocity you are also getting work done, and it’s the most important work too.

You might argue that you can’t do 3 sprints (which could be as little as 3 weeks if you use 1 week sprints) before you’ve signed the contract with a client. I would like to suggest that in the past it took you more than 3 weeks to build the project plan, and document the requirements in detail for the contract. So it is not that we need more time with Scrum, it is just that we don’t believe there is any better way of guessing how long things will take us than measuring it.

If you have the same team as a previous project for the same customer, it’s in the same subject areas, with the same technology and working environment, then chances are your velocity on the previous project is good enough to use to plan this project.

So now you have:

• A list of features you need to build
• An estimate in story points for each feature
• A measure of how many story points you can complete per sprint.

So it’s pretty much as simple as add up all the story points, divide by the velocity, and multiply by the sprint length. i.e. if the features add up to 160 story points, the teams velocity is 20 story points per sprint, and the sprint length is 2 weeks, it will take 160/20 * 2 weeks = 16 weeks to complete the project.

There are a few more things you might want to take into consideration at this point.If you are a ex-project manager, lets say we need to talk about contingency:)

Question 1: How stable is your velocity?

If you team has been together for ages and has show a variance of <10% on there velocity for several sprints in a row, then it’s probably pretty solid.

If you team is new and for the 3 sprints where you measured it you got: 10, 0, 57. You have some risk. You might want to work out the plan on a best case, worst case and average case, and add contingency in case the worst case happens. If that plan would put the deal off the table, maybe it is worth one more sprint to see if a more predictable pattern emerges.

Question 2: Do you need a release sprint?

Are you shipping you software to the customers every sprint, or are there a few steps between the potentially shippable software completed in the sprint and what you will release. What are those steps? Some teams new to agile don’t have fully automated regression tests, so they need to run regression in the release sprint. Some don’t update end user documentation as go so they need a release sprint to do that. Figure out what you need and plan it in. Even better add this stuff to the backlog and size it.

5. Create a release plan

If you are still very attached to your Gantt Chart, the release plan is your new best friend. It’s kind of like a Gantt chart except that it is easier to update and tells you exactly where you are now, and when you are likely to finish.

To help you understand this, I’m going to give you a fictional example:

Let’s say your Product Backlog that came out of step 3 looks like this:

Priority	Estimate	Story
1	2	Feature A1
2	5	Feature A2
3	3	Feature A3
4	5	Feature B1
5	8	Feature C
6	13	Feature D1
7	3	Feature B2
8	13	Feature E
9	5	Feature B3
10	2	Feature B4
11	8	Feature D2
12	13	Feature F1
13	3	Feature B5
14	5	Feature A4
15	1	Feature F2
16	5	Feature F3
17	20	Feature G
18	8	Feature H
19	13	Feature I
20	40	Feature J

Next lets assume the team complete the first 3 items in sprint 1. A velocity of 10.

Then the team completed the next 2 in sprint 2. A velocity of 13.

Then the team completed the next 2 in sprint 3. A velocity of 16.

We average the velocities of the 3 sprints and assume a velocity of 13 per sprint.

We also decide that the team’s velocity seems fairly stable so we don’t need any contingency. Finally we need a release sprint to do the end user documentation as we don’t include that in each story. Each sprint is 2 weeks and we started the project 6 weeks ago on 19 April. So the total story points = 175. Velocity = 13. Therefore we need 14 sprints, plus a release sprint. Each 2 weeks long.

Here’s what your release plan might look like.

Sprint	Start	End	Stories	Estimates	Total Estimate for Sprint
Sprint 1	19 April	30 April	Feature A1	2	10
			Feature A2	5
			Feature A3	3
Sprint 2	3 May	14 May	Feature B1	5	13
			Feature C	8
Sprint 3	17 May	28 May	Feature D1	13	16
			Feature B2	3
Sprint 4	31 May	11 June	Feature E	13	13
Sprint 5	14 June	25 June	Feature B3	5	13
			Feature D2	8
Sprint 6	28 June	9 July	Feature F1	13	13
Sprint 7	12 July	23 July	Feature B4	2	11
			Feature B5	3
			Feature A4	5
			Feature F2	1
Sprint 8	26 July	6 Aug	Feature F3	5	5
Sprint 9	9 Aug	20 Aug	Feature G	20	20
Sprint 10	23 Aug	3 Sep	Feature H	8	8
Sprint 11	6 Sep	17 Sep	Feature I	13	13
Sprint 12-14	20 Sep	29 Oct	Feature J	40	13.33
Sprint 15	1 Nov	12 Nov	Release Sprint	13	13

Some things to notice. Although Feature B4 had a higher priority it was moved a bit later to go into a sprint with smaller items. Sprint 9 has 20 points in it, but sprint 8 only has 5 points. Together it’s 25 points which is close to the velocity of 26 points for 2 sprints. Once we get closer to Sprint 8 we will likely break Feature G down a bit and have some smaller stories some of which will fit into Sprint 8, but it is likely the feature will only be finished in Sprint 9. For feature J, it is quite large and so will take 3 sprints. At this point it’s pretty far off so it’s probably okay to just say it will take 3 sprints, closer to the time we can break it down and say what will be covered in each of those 3 sprints.

6. Communicating the release plan

Now you can go back to your customer with a plan and an end date. But it’s important to communicate that this plan will change as you know more, but that you will discuss those changes with them every sprint, and that at the end of each sprint they will have a clear view of where you are on each of the features they care about. In fact they will have an opportunity to view each of these features in a review at the end of the sprint they are completed in. They will have transparency at each step of the way. You can go further and use Jeff Sutherland’s “Money for nothing change for free” contract structure and let them change functionality or cancel the project at any point in time. 

7. Updating the release plan

Remember it’s just a plan, so it will change. Each sprint you should spend time grooming the backlog which means breaking down larger stories, re-estimating them when they are broken down and you know more, adding or removing scope as identified in the review with your customer. Also at the end of each sprint you can update your assumptions about velocity and see what the impact that has on the plan. In each sprint review you can discuss with the customer where you are and how you are doing. Remember to review the goal at each point to see that you are still on track. If the plan changes because suddenly a feature is going to be a lot more complex than expected, review the customer requirement again and see if there is an easier way to meet that requirement maybe with a slight compromise.

If you believe that in the traditional world plans didn’t change then you are mistaken, we just made people fill out forms to make it painful and called it change control, as if we had a choice and could really control change. Now we call it reality, and work with it.

Be sure to get our book which covers all sorts of exercises and techniques around Release Planning.