The Legitimacy of Release Backlog

We heard this story tens or even hundreds of times: there's sprint backlog and product backlog in Scrum. Sometimes I hear even more specific statements, like: there should not be any other backlog at all, besides the two mentioned earlier. Question is whether release backlog is legitimate entity in Scrum or not? That's our target...

So, before I start convincing you that there are very strong reasons to maintain one, let's agree upon the rules of the game: not everything states in Scrum axioms is necessarily a real life model but rather some kind of necessary simplification or abstraction. Let me give you an example... How many software companies do you know that have no engineering managers (or their equivalent)? I guess none! Even those claiming they adopted Scrum, they themselves still have engineering management. Now, as a Scrum primer, there's only three roles in Scrum, we know it: Team, PO, SM - no managers! See where I'm heading?.. It's like a chess game... total abstraction: you only have few kinds of chess pieces even though there's way more military ranks and arms in real life.



So why do we need release backlog?

Well, first of all business thinks that way. Business thinks in tangible releases and I can't say that that is a bad thing. Let's think about it for a second, what is a release as we know it? It is some kind of solid and logically consistent chunk that represents marketable value. We still assume that scope is variable but it does not mean that variability should be so high that we can't approximately say what will be released. Eventually, epics and stories that go into releases are some sort of "containers" (negotiable, the second term in the INVEST acronym by Bill Wake) - their content may vary to some extent, but still business wants to know what containers (think of it as labels on the release product box; similar metaphor to "Product Box" game in Luke Hohmann's "Innovation Games") will be included. Sounds legitimate, as product management, company leadership, their investors and users want to know.

Next, Release backlog is impotant because it is bound to Release Planning. Only sprinting may not be enough, especially in the case of large scale distributed development. I saw this multiple times in case of big product development effort and even more so in case of outsourcing: Release Planning is the primary chance for teams and objectives alignment, obtaining shared context and building common understanding of "what it is we are working on". I witnessed the case in Mumbai (India) when after a two-day distributed release planning session one of the developers said at the retrospective meeting: "Before this planning session we didn't even really know each other in the program and now we are like a family..." - very strong comparison in India, I have to say... as family is everything.

For a large scale development release planning is not even about "scoping" or "scheduling" but a chance to better express stakeholders' expectations, to convey business and technology vision to agile teams and get their understanding of what they can deliver resulting in a mutual committment. Sprint planning is simply too frequent and too local to get to this level of high-rank stakeholders involvement and direct teams-stakeholders collaboration.

Next reason is that stakeholders like to not only see what's in the release but also what isn't. Sometimes it is very helpful to elaborate the Release N Plan and a draft plan for Release N + 1. This also provides a meaningful guideline for everyone in the company as to where are we heading as a business - sort of information product backlog will not necessarily convey to you. It may simply be hidden behind layers and layers of features and user stories. Instead quite often we use very straightforward and compact mechanism to express a release backlog - Release Objectives - very short statements of intent for the release. It is very easy to comprehend and having 15 such objective sheets for 15 teams in a program makes it much easier for stakeholders to understand and discuss what teams may actually deliver.



What is sometimes offered as an alternative to a release planning and release backlog is mean velocity. So you simply make a projection against your product backlog. There's nothing wrong with the tool but only if you use it for rough approximation purposes. Other than that there may be serious trouble involved. Imagine distributed program, that has not yet finished their transition from component oriented to feature oriented group configuration, in which one of the Indian component teams leaves for 1-week vacation during Ganesh Chaturthi and prohibits entire program (including US teams) from delivering anything substantial in that sprint. It's hard to catch this if you don't go thru release planning exercise.

Finally, when dealing with Release Backlog, we have a chance to spot and start fixing the root causes of problems with product development such as insufficient stakeholders' involvement, lack of business expertise on the side of engineering, etc.

I don't even seriously touch the technology vision part in this post as it is itslef a huge topic. I can direct the reader to this great outline of enterprise architecture concepts by Dean Leffingwell, Ryan Martens and Mauricio Zamora. I will only mention one metaphor from there - architecure runway - the distance for an architecture epic to take off. The bigger the system the longer the runway, which is hard to argue. Now you see, it is useful to see what we can count on technologically in different points of time and best way to do so is via releases as major "consumers" of architecture and infrastructure epics.

Topics that fall beyond basic axioms of a theory are most exciting and sensitive as they originate from the contraversies of practical applications. It's good we have them...

1 comment: