I haven’t heard the term “release backlog” in many months, but it’s come up in three conversations over the past week. So, I want to share my thoughts on whether a team using an Agile project management approach should have a Release Backlog in addition to the conventional Product and Sprint (or Iteration) Backlogs.
First, let’s clarify what people mean when they refer to a “release backlog.” A release backlog is a subset of the product backlog that is planned to be delivered in the coming release, typically a three- to six-month horizon. A release backlog would presumably contain the same type of items as on a product backlog. My preference for this, of course, would be user stories. So, at the start of some release planning horizon, a product owner with help from the team and other stakeholders would example the product backlog, select some amount of high priority work and move those items to the release backlog. Later, in sprint (iteration) planning, the team would examine the release product and select some amount of work to do. (Notice how this already goes against existing agile literature that says the team selects top priority items for the sprint from the product backlog?)
I am opposed to the use of a release backlog for a couple of reasons:
First, in all projects that are not being done as fixed-scope contracts (and, arguably, even then) we don’t know exactly what user stories or features will be delivered in a release. To say that there is a release backlog may not imply a guarantee that all features on it are delivered. However, it does create additional work as items are moved off back and forth between the product and release backlogs. This will happen as the team’s velocity changes (even by small amounts) from sprint to sprint. If the release backlog is to show what a team will deliver in a release, it should contain an amount of work equal to the number of story points (or ideal days) times the number of remaining sprints. If you have an average velocity of 20 and 6 sprints left, the release backlog should contain 120 points worth of work. Suppose the team finishes 24 points of work in a sprint. The backlog is now down to 96 points (120-24) but should contain 100 (5 sprints left x an average velocity of 20). Things get even more difficult if that good velocity of 24 increases the team’s average velocity to 21. In that case the release backlog should contain 5×21=105 points of work; we need to move 9 points of work from the product backlog to the sprint backlog. If there’s a release backlog, this moving of items back and forth from product backlog to release backlog will happen every sprint.
Second, introducing a release backlog creates additional confusion. We’ve already overloaded the word “backlog” with “product backlog” and “sprint backlog.” Why confuse things further with a third type of backlog unless there is an immensely compelling reason to do so?
Third, introducing the concept of a Release Backlog actually makes it harder for product owners to do one of the most important things they should be doing–looking at the features or user stories that just miss the cut of being in a release. When I look at a product backlog and count down the number of story points that I anticipate will be in the release, the most interesting thing to me is not necessarily the set of user stories that will make it into the release. I’m often just as interested in the next few user stories below that cut-off point. That is, I want to know what user stories won’t quite make it into the release. After all, we say that one of the benefits of agile (on some, not all, projects) is the ability to decide later if we should release a few sprints early (if a lot has been done), on the planned date, or perhaps a sprint or two late if we want to add more functionality before a release. This is made more difficult with a Release Backlog because a product owner now needs to examine both a Product Backlog and a Release Backlog to make these decisions.
So, what do I propose instead?
I advocate that all teams track their velocities. This leads to a graph like this:
This graph shows a team calculating three average velocities:
- Long term average, defined as the mean of the last eight sprints
- Worst case average, defined as the mean of the worst three chosen among the last eight sprints
- Best case average, defined as the mean of the best three chosen among the last eight sprints
You can choose your own ways of calculating long-term, best-case, and worst-case average velocities. These are just the ones I like. We use these average velocities as shown in this figure:
In this figure, the product backlog is shown on the left as a stack of index cards. We use the three average velocities multiplied by the number of remaining sprints to draw arrows pointing into the product backlog. The range created by these arrows indicates the likely amount of work finished by the planned date. Our release plan is the work defined by the arrows. Rather than a Release Backlog as a new work product or artifact, my equivalent of a release backlog is the product backlog and these arrows pointing into it.
As you can imagine, predicting velocity as a range is much more likely to be accurate than using a single point estimate (“Our velocity is 31.”) as has been implied by everyone I’ve heard talk about a Release Backlog. Additionally, looking at figures like these should make it apparent that the amount of work expected to be delivered in a release will change from sprint to sprint. Pointing arrows into a product backlog is much easier and more helpful than creating a new work product, the Release Backlog.
Tags: agile release planning, product backlog, sprint backlog, velocity
I agree that if product owners are wasting time moving stories back and forth between a release backlog and an overall product backlog, that would be a bad thing. In practice, I’ve never had that problem. As I describe in Use Multiple Backlogs, I started off by tagging user stories/feature requests in the product backlog to put them into maintenance, minor, and major release “buckets,” plus a “future” bucket for all the good ideas I didn’t expect to make the next major release. I was always conservative about putting things into these buckets (biasing towards sticking things in “future” unless I though there was a high probability the ticket would in fact be done on the next maintenance/minor/major release), so I didn’t in fact waste time moving things around. This practice saved enormous time when it came time to create the “release plan” for a given release. I only had to review the items I’d put in the appropriate bucket (s) for the upcoming release and any finer-granularity buckets (e.g. review both maintenance and minor buckets when planning a minor product release). Then we could track a burndown chart for the work we approved for the release plan. I continued a version of this approach (“future” tagging) when I moved to another company that was in fact using Agile to get an unorganized 1800 ticket backlog under control. Now I use an Agile tool with explicit release support. This discussion may get a bit confused by a semantic question. If you tag user stories on the master product backlog, is that creating a separate backlog? One might view the practice I outline as simply informative tagging on user stories to save time in release plan development–overlaying these tags on top of the standard master backlog. What I *do* know is that when I’ve got a large team of smart developers and lots of customers all submitting good ideas for a long-lived product whose lifespan spans a decade or more, I don’t want to have to review every idea ever submitted each time I plan a new release. This approach also saves me from having to maintain a precise total order on all the user stories in the system, which although a good theoretical goal, ultimately gets a bit imprecise. Can I *really* say for certain that this item is the 138th most important item on the total backlog and the next one is really the 139th? All that said, I think your approach of keeping a total order and then defining the release as a “bubble” floating part way out on the product backlog is a perfectly viable alternative as well. Part of which approach you choose may have to do with the lifespan of the product and project. If the team is only writing user stories for the current project/release and not keeping track of other requests it knows it won’t do for this release, the single backlog without tagging or bucketizing will work really well. When you’ve got a continuous stream of existing and incoming ideas, many of which you know you can’t address in the current project/release, but which you want to capture for future evaluation, bucketizing gets more attractive.
Great article. Thanks. Though I have some question regarding sharing backlog between several branches of development. Consider same team working on the major release and several service packs to prior releases. Most of the features planned for service pack also reach next major release but not all of them because the code base has changed. How would you treat the items in the back log in that case? Currenty we track them in a single backlog but that also causes issues understanding what features will be in what release. So currently I am trying to find alternatives to single Product Backlog approach although have not found anything workable yet.
Hi Alexander–
I’m glad you liked the article. I would tend to treat this as one backlog. I’d most likely do it in Excel where I could set easy sorting columns, though. This is better (IMO) than the alternative of separate backlogs. With separate backlogs, the product owner cannot easily see the relative priorities between work on the major release and the planned service packs.