Why there should be a "release backlog"

Mike Cohn writes that there should not be a release backlog. He has impeccable timing, given my recent post defining the term Release Backlog .

I disagree with Mike. Release Backlog is a useful tool for my teams. I won't argue with Mike point by point because Mike's context is different from mine. He suggests that the context of his argument is "all projects that are not being done as fixed-scope contracts". My teams operate in exactly that context--fixed scope contracts--and in this context, Release Backlog is a useful tool.

In the world of fixed scope contracts, Product Backlog is inadequate. The product's lifespan surpasses the lifespan of the project defined by the contract. The set of requirements for the contract is a subset of all possible product requirements. We need a way to partition contract requirements from all possible product requirements, and we need a way to gauge whether we have completed the contract requirements. Thus is born our Release Backlog, distinct from the Product Backlog. Useful synonyms for Release Backlog might be Contract Backlog or Project Backlog.

At the beginning of the contract, we define our user stories and put them in our Release Backlog. We do some up front estimating and get a rough feel for when we might be done. We review the Release Backlog with our product owner (the customer or a proxy) and prioritize its items. At the beginning of each sprint, we pull Release Backlog items into the Sprint Backlog. In general, we use Release Backlog the way other teams use Product Backlog. We gauge our velocity across multiple sprints, and we get a good idea of when we'll be done with the requirements of the contract.

Release Backlog is very useful for keeping focused on getting the project done. Despite best efforts, no one knows ahead of time what they really want or when the project will really be done. As the project progresses, we and the product owner refine our vision with new or changed user stories. Some of these user stories make there way into the Release Backlog as updated contract requirements, and others land in Product Backlog as good ideas that are not intended for this project.

Here's an example. Late in a project, the Product Owner discovers that he has seven requirements that weren't accounted for in the original contract. After some discussion with the Scrum Master, he agrees that only five of the new requirements are applicable to the current project. He puts those five new requirements in Release Backlog and the other two in Product Backlog, and he reprioritizes the Release Backlog. The Team estimates the size of the new requirements. Given the Team's known velocity and the amount of work left in the Release Backlog, the Team predicts a new done date. The Product Owner and Scrum Master discuss again: should we keep the redefined Release Backlog and accept the later done date, or should we keep the original done date and prune lower value items from the Release Backlog? This is an easy conversation to have with a Release Backlog, and nearly impossible without it.

Release Backlog isn't for everyone. It is not discussed in much of the Scrum literature, perhaps for good reason. In the context of fixed scope contracts, though, Release Backlog is a useful tool that can help the Product Owner and the Team get the right stuff done at the right time.


mikalja said...

Have not checked the referenced posts yet (feel they are worth). Fully agree - fixed price contracts (fixed scope contracts) need to have limited set of features. In addition to the facts enlisted in this post, may add that usually fixed scope contracts may imply final payment upon acceptance. Periodic enhancement of the backlog may lead to additional obstacle with acceptance (payment).

Anonymous said...

Mike suggests that the context of his argument is "all projects that are not being done as fixed-scope contracts". Your say your teams operate in that context. It seems you actually agree with him.

In any event are there any other contexts in which a release backlog is appropriate?

Eric Krock said...

Hi Richard - Excellent article. I agree with you that per-release backlogs can be useful. I find them helpful even for ongoing development programs associated with a long-lived product (not just for fixed-price contracts). I discuss some approaches I've used in the past 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.

Anonymous said...

What you mean by 'After some discussion with the Scrum Master, he agrees that only five of the new requirements are applicable to the current project.'? why should have Scrum Master any impact on what is added to release plan? that is discussion with the 'product' and 'project' kind of stakeholders, so PO and the team. Not a 'process' guy SM.
Also, release backlog, and even release plan sounds as something promised. in Scrum, or any other process model/framework you could not commit/promise until you spend a lot of time on analysis. in Scrum, you really just project/predict the scope could be finished given the backlog and metrics, instead of planning.

Richard said...

Dear Anonymous July 11, 2012,

Thanks for your comment! I'm glad you read my article, and that we're having a conversation about it.

In the example, why does the PO consult with the ScrumMaster? The PO asks for help, which is always a good idea. There are no limits on whom can be asked for help. The SM is a good person to ask for help, given that the "ScrumMaster serves the Product Owner in several ways, including: Finding techniques for effective Product Backlog management ..." [Scrum Guide 2011]. In the example, it works out for the best.

Release Backlog and Release sound like something promised. Yep, in a fixed scope contract, scope is promised.

The point here is that Release Backlog isn't evil. It's a tool that you can use to get good results.

Richard said...

Dear Anonymous May 20, 2009,

Yep, you're right, I do agree with him. The special context here is fixed scope contracts.

Richard said...

Dear Eric Krock,

Thanks for the conversation.

I'm glad the Buckets idea is working for you. I usually clump things together into large backlog items and put them near the bottom of my single product backlog. Similar idea, and I don't have to worry about getting confused about which backlog is *the* backlog.


Related Posts with Thumbnails