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.
