Enterprise Agility–The Big Picture (4): Backlog

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Teams, Iterations and the Agile Product Owner. To see the full series, select the “Big Picture” blog post category. In this post, we’ll describe three types of Backlog [callout (4)].


Big Picture 4 - Backlog

One of the difficult and interesting aspects to working with software process models is their lack of semantic precision. Based on my experiences in working with the UML team in the late 90s and my responsibilities for the RUP thereafter, I’m familiar with the difficulty in establishing a common semantic structure for software things. It takes collaboration, consensus and process maturity as well as some sort of governing authority to establish agreement. Little such infrastructure exists today in the agile community. That’s a bit of handicap in describing these methods and perhaps a measure of their relative immaturity (not to confuse maturity with efficacy, after all, the waterfall model is really mature!). At the same time, that’s probably one of the reasons we like agile – it’s not too late to explore and develop new methods and new meaning.

In this context, I would describe the word “Backlog” as the simplest and yet most overloaded term in agile. It’s not intended to be complicated and it really just means “stuff that needs to be done”. In its simplest form, it is primarily a repository for un-done user stories, that agile invention of value-added objects that we use to describe things our system needs to do for the user. (See Chapter 17 of Scaling Software Agility or Mike Cohn’s User Stories Applied, for a deeper treatment of user stories.).

However, in enterprise-class development things get more complicated and effective agile gets more complicated too. In one very large scale software development case, I saw a schema that had about six or seven different backlog types and while that seems complicated, it seemed to work ok in that company’s increasingly agile practice.

In the Big Picture, I’ve taken a stab at some simple clarifying labels for three common types of backlog that scale to the enterprise. However, the reader should be aware that there is no “backlog label consensus” in the industry that I am aware of, and I’m simply using these labels as I and some others have applied them. In any case, the labels matter less than the principles and it’s the hierarchical principle that I hope to make clear. In the Big Picture, I’ve indicated a three-level requirements hierarchy to hold three types of backlog. They are:

The Iteration (or Story) Backlog – holding user stories and the like that are generally intended to be implemented by a component team in their code baseline in the context of an iteration

The Release (or Feature) Backlog – holding features that deliver system-level value that typically affect multiple component teams and typically span iterations

The Portfolio (or Epic) Backlog – a placeholder for capturing and discussing the larger scale initiatives that an enterprise has, or intends to have, underway. Epics often affect multiple component teams, multiple systems, and even multiple products. Epics typically span iterations, releases, and sometimes years!

I’ll describe the first and hardest working of these, the Iteration (User Story) Backlog, in the next post.