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 in agile 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 cross-functional 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 or product backlog item. 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 to the agile Scrum Master “It all needs to be done!” in your release planning meeting, 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 by a 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.
| Story | Estimate | Cumulative estimate |
| Homepage (anonymous) | 5 | 5 |
| Login (happy path) | 5 | 10 |
| Login (unhappy paths) | 5 | 15 |
| Homepage (authenticated) | 5 | 20 |
| Calendar view | 5 | 25 |
| Add new calendar entry | 5 | 30 |
| Edit calendar entry | 5 | 35 |
| Task view | 5 | 40 |
| Add new task | 5 | 45 |
| Edi task | 5 | 50 |
| Friends list | 5 | 55 |
| Share calendar | 5 | 60 |
| Share task | 5 | 65 |
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, in agile methodologies. It is not a measure of “performance” and should not be used as a management metric (seriously). It is an agile metric 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. Velocity is not formally part of the Scrum framework, but is a very common pattern used in agile development cycles.
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 backlog looking like?
Backlog with 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 product 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.
For agile release planning, I like to therefore characterise the agile release roadmap with colour ranges to show the likelihood of various stories getting delivered. This approach is sometimes called “probabilistic forecasting“. It is one of the many useful agile planning techniques you should have in your toolbox (along with release burn-down chart, release goals, agile estimation, etc).
For example, it’s drastically unlikely that the agile teams 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:
| Story | Estimate | Cumulative estimate |
| Homepage (anonymous) | 5 | 5 |
| Login (happy path) | 5 | 10 |
| Login (unhappy paths) | 5 | 15 |
| Homepage (authenticated) | 5 | 20 |
| Calendar view | 5 | 25 |
| Add new calendar entry | 5 | 30 |
| Edit calendar entry | 5 | 35 |
| Task view | 5 | 40 |
| Add new task | 5 | 45 |
| Edit task | 5 | 50 |
| Friends list | 5 | 55 |
| Share calendar | 5 | 60 |
| Share task | 5 | 65 |
Neat, huh? You can take this further and do in-between shades of orange bordering on red or whatever you want. Just don’t go too crazy. As always, it’s more about the people and conversations than the numbers or the tools. Just ask anyone experienced with agile project management.
Aim for more frequent releases
Of course, you should always be aiming for smaller and more frequent releases. A lot of these questions (“how many features can we get in this release?”) go away when you are releasing every month, every week or even every day.
It’s not just about incremental development, it’s about incremental releases. There’s not much point in working in two week sprints if you only release once every six months! Teams should be revising and expanding their Definition of Done, until the point where the DoD includes “released to production” (or at least “deployed to production”). Agile retrospectives are a perfect opportunity for a Scrum team to work on their Definition of Done.
This is part of the long, hard road to continuous integration / continuous delivery. Where DevOps and Agile finally work together. And is a vitally important part of your journey towards proper, sustainable agile software development.
Summary / Frequently asked questions
What is the meaning of agile release planning?
Agile release planning is the process of planning out one or more releases over time for a team (or teams) that is doing agile software development / iterative development. I recommend using a “probabilistic forecasting” method, described above. It produces a range of scenarios based on variations in velocity.
Who creates an agile release plan?
That depends a lot on the organisation and its context. Sometimes it is a Scrum Master. (although the Scrum Guide doesn’t describe this as one of the Scrum Master responsibilities). It might be an Agile Project Manager or Agile Delivery Manager, if there is one of those around. Some places have dedicated Release Managers who might do this.
What is the meaning of release plan?
Release plans can be important in agile software development
A release plan is a forecast of the backlog items, features, bugs and so on that are intended to be deployed in an upcoming release. It might also include a Release Runsheet, which defines the exact tasks (and their order and dependencies) that have to be done in order for the release to be done.
What is the difference between release planning and sprint planning in an agile project?
Release planning is a plan of what will go into a release and what needs to happen for the release to work. A release is not specifically tied to a sprint! Scrum teams do not have to do exactly one release exactly at the end of a sprint. They can release once per sprint, or less frequently, or more frequently. And they can release at any time during a sprint.
A sprint planning is a plan of work that sprint. It defines the backlog items that the team intends to get done within a sprint, in order to achieve a sprint goal.
If you want to know more about agile release planning, this video might help you to understand it.
