Agile Release Planning as a range of probabilities

A lot of people find release planning difficult and confusing in Agile. How can we plan out our releases when we don’t have fixed scope? When will we know something is ready for release? How do we use velocity to help our planning? Are releases tied to iterations? I’m going to try and answer these questions in this post, and describe a model that I have found to be useful in release planning.

Release Planning isn’t a binary question

A lot of people think about release planning as a binary question: will this thing be completed in time? A common scenario would be a team that has a release due in two months. They have some stories and features in a backlog, and they’re trying to determine if they can get them done in time for the release.

One thing to remember is that it’s usually not necessary to complete every  user story. Product Owners usually put in a bunch of things they want to be built, ranging from the essential to the unimportant. The product backlog should be put and kept in order of priority by the product owner. If your product owner isn’t doing that, tell them to do that, it’s their job.

If the product owner says “It all needs to be done!”, tell them that’s fine, it will all get done. Just not necessarily at once and not necessarily all in time for the release. This is the point: release planning isn’t a “yes / no” thing. It’s more of a “how much of this thing do we think we can get done bya point in time X” thing.

You work your way through the backlog in order, and however much of it is done by the release is what gets released. It might be most of it, half of it, all of it, or anything. There is however a range of probabilities, and those probabilities are based on the size of the backlog and the team’s velocity.

Example of backlog with estimates

This will all make a lot more sense with some examples. Here is a backlog of user stories for a fictional website I’ve just made up. They have been ranked in order of priority by the product owner (with some input from the team around things like technical dependencies). The product owner wants to know if the whole thing can get built in time for a release in two months.

StoryEstimateCumulative estimate
Homepage (anonymous)55
Login (happy path)510
Login (unhappy paths)515
Homepage (authenticated)520
Calendar view525
Add new calendar entry530
Edit calendar entry535
Task view540
Add new task545
Edi task550
Friends list555
Share calendar560
Share task565

Let’s say the estimates for every story just all turn out to be five (bear with me). I’ve also shown the cumulative estimate: how many points will have been done in total for each story and the stories before it (this is important for what we’re about to do). Once we have this, and we have our velocity, we can do our release planning.

Discussion of team velocity

Velocity is a measure of how many story points a team delivers on average each sprint. It is not a measure of “performance” and should not be used as a management metric (seriously). It is based on historical data, i.e. it is a moving average of points delivered per sprint for as long as the team has been around for. Let’s say the team averages 14 points per sprint, but with obviously some variation. This variation is the driver behind our “range of probabilities”. Over a number of sprints, the average will be 14, but there might be some sprints with a higher velocity, some sprints with a lower velocity. If the release is in two months, and we are on two week sprints, that means there are four sprints to go until the release. So with a velocity of 14, what is the release looking like?

Backlog with colour ranges for probabilities

If you do a simple calculation it looks like the release isn’t going to work. Four sprints at 14 points per sprint is 56 points delivered, and the total cumulative points for the backlog is 65. It looks like the team will get down to Friends List and that’s it, missing out on the last two items. But two points to keep in mind:

  • It’s not a binary question. We’re not interested in know if either everything can be delivered (yes) or nothing can be delivered (no), we want to know how much can be delivered. The product owner might not care too much about the Share Calendar and Share Task user stories.
  • Velocity is an average and there is always variation. The team might have a couple of good (above average) sprints and reach the stretch goals. Or they might encounter major blockers and only get halfway through.

I like to therefore characterise the backlog with colour ranges to show the likelihood of various stories getting delivered. For example, it’s drastically unlikely that the team would deliver 50% or less stories per sprint over all four sprints, so we can assume that 7 points by 4 sprints means everything 28 (let’s call it 30) and below is “green” (certain to be delivered). We know the last two are unlikely to be delivered, i.e. stretch goals: we might get there, but don’t count on it. So let’s mark it red. The between range is orange: we think we’ll deliver it, but we’re not sure. Our backlog now looks like this:

 

StoryEstimateCumulative estimate
Homepage (anonymous)55
Login (happy path)510
Login (unhappy paths)515
Homepage (authenticated)520
Calendar view525
Add new calendar entry530
Edit calendar entry535
Task view540
Add new task545
Edit task550
Friends list555
Share calendar560
Share task565

Neat, huh? You can take this further and do in-between shades of orange bordering on red or whatever you want. Just don’t too crazy: as always, it’s more about the people and conversations than the numbers or the tools.

 

Leave a Comment:

2 comments
Add Your Reply