What happens when your backlog grows to a point that it becomes hard to manage as a single flat list? When a flat backlog grows beyond a hundred or so items it can start to become unwieldy. For a typical small agile project, this may never happen. For larger projects where multiple Scrum-style teams are working off a common backlog, that backlog is quite likely to grow (or even start) this big.
When working with larger backlogs, what teams need is some sort of grouping of backlog items into larger chunks that can be more easily worked with as a whole. Most teams are familiar with breaking large user stories (epics) down into smaller user stories so that each user story is small enough to be designed and implemented within a single iteration. Therefore, the most obvious larger groups to start with when moving beyond the flat backlog are epic user stories. Higher level planning such as release planning can start by working with epics and then refine the details at the individual user story level.
Ken Schwaber, in his book, The Enterprise and Scrum, suggests a number of different ways to organize a large backlog into different hierarchies to make it easier to work with. The following are some of the ways I have encountered of categorizing entries in a large backlog:
By area and activity
Feature-Driven Development(FDD), because it was originally developed for a project of about a thousand backlog items (FDD-style features), advocates a three level hierarchy that groups features (the FDD equivalent of user stories) into sets of features related by user activity. These sets of features are in turn grouped into subject areas within the problem domain. For example, subject areas might include customer relationship management, product catalog management, inventory management, etc. In the CRM area there could be sets of features for editing customer details, handling complaints, etc. The Editing Customer Details feature set would be likely to include features such as change the address of a customer, add a new customer to the customer list , etc
A three or four level hierarchy is likely to be enough for most small to medium sized IT organizations. For example, in a three level hierarchy of 20 feature areas each with an average of 20 feature sets, each with an average of 20 features there would be 8000 features – more enough to keep most of the software development organizations that I have worked with busy for a while.
By aspect or 'logical layer'
Aspects or themes are another way we can categorize stories meaningfully. For example, all the user stories related to printing, or all the stories related to logging, or the user interface, etc. One larger FDD project that I worked on split the backlog into three aspects, user interface, problem domain, and system integration to match the organization of the team. Within those aspects, the backlog was organized into similar subject areas and feature sets.
By problem domain concept
By problem-domain concept is another way to categorize items in a backlog. For example, all the user stories to do with the payment class, service or component. Useful if the backlog serves a set of teams each of which is responsible for a specific service or component.
By requester
In addition, where there are multiple customers providing input into the backlog, grouping stories by requester is another view. For a product owner, this view is useful if a customer suddenly becomes much more important or conversely drops off the radar so that items requested by that customer can be easily identified and their priorities adjusted.
By marketable functionality
Minimal Marketable Features (MMF) are an interesting idea. MMF recognizes that some user stories within an epic may not be absolutely essential to delivering the core business value of that epic story. For example, one or two of the stories belonging to the epic may be of lower business value than the rest. Maybe they address rare scenarios that could still be handled manually if they arise. Therefore, planning to deliver the whole epic is less optimal from a business perspective than delivering only the high-value stories in that epic. Of course, whether that is significant in the wider scheme of things would depend on how much effort is required to develop those low value stories relative to the rest of the high priority backlog items. In many cases, a small deviation from the absolutely optimal order of story delivery is not likely to prove fatal.
Look before you leap
Before you start implementing a program to break up a large, flat backlog, consider if perhaps the backlog has grown for some other, not-so-useful reason.
Bottom line
An obvious conclusion is that as we scale agile across an organization, and create genuinely large backlog, we are going to want to view it in different ways at different times for different, equally valid reasons. The ability to organize a backlog into a single hierarchy is not going to be enough. We are going to need tools that enable us to view large backlogs in different ways using flexible filtering, sorting, and grouping mechanisms.
Your groupings are all useful. However, there is probably 1 more very important category: what we won't do. Lining up a very long list may set unrealistic expectations with the customer (or customers). As long as they see their item in the backlog, they will expect it. The reality is that many things near the bottom will never be done because there will be new items that keep pouring in at higher priority. Therefore, saying "no" to low priority items is an important (but often overlooked) technique for keeping backlogs manageable.
Posted by: Ian Buchanan | February 25, 2009 at 02:03 AM