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.

6 thoughts on “Enterprise Agility–The Big Picture (4): Backlog

  1. Great post! I would like to highlight the need for one more level of “prioritization”. We treat it as more of an “initiative” concept.

    Agile planning does a fantastic job of aligning the Product Owner with the Team. As a result, the Product Owner becomes much more knowledgeable about what the team can deliver vs. what the team “should” deliver. The good ole PM vs. Dev debate (see Dean’s recent post for more on this subject)

    As a result of above, it is easy for development to lose sight of what it takes for the product to be marketable or consumable by a client going into production. What you need is a way to distinguish between what can be delivered vs. what needs to be delivered to generate bottom line value (profit, market win, etc.)

    We introduced the concept of an initiative that is really independent from release planning. It helps PM and development understand what features and epics are required to successfully complete an “initiative”. The initiative might be the first go live or it might be the client sign-off for a key contract that generates critical revenue

    Finally, the release and portfolio backlog concepts mentioned above are what most non agile folks fail to understand and as a result, declare agile “short sighted”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s