Definition of BACKLOG
1. a large log at the back of a hearth fire
2. an accumulation of tasks unperformed or materials not processed
Burn the first slowly and the second quickly

Team Backlog Abstract

The Team Backlog represents the collection of all the things a team needs to do to advance their portion of the system solution. It can contain user stories, future features, technical stories, defects, infrastructure work, spikes, refactors, and anything else a team needs to do. Most of these stories are discovered during Release Planning, others are local to the team’s specific context. While backlog seems to be a simple notion, there are a number of subtleties that create the power behind this simple construct.

It is truly ALL the things. If a thing is in there, it might get done. If it isn’t there, there is no chance that it will be done.
It’s a list of “want to do”, and not a commitment. Items can be estimated (preferable) or not, but neither case implies a specific time commitment as to when any of it will be done.
It has a single owner – the team’s Product Owner. This protects the team from the problem of multiple stakeholders, each with potentially divergent views of what’s important.

There are a number of sources that contribute the content for the backlog, including the Program Backlog, the teams local context, and the needs of stakeholders outside the team. Keeping the backlog estimated is the responsibility of the team, as this drives economics for the team and the program. Teams apply capacity allocation to help assure that investments are balanced across conflicting needs.

Details

Team Backlog Overview

While the Team Backlog appears to be simple and unifying construct, the fact is that it conveniently hides some of the complexity of Agile, and Agile at scale. Figure 1 illustrates a view of the Team Backlog, with its three primary input sources.

Figure 1. Exploded view of a Team Backlog

Source 1. Program Backlog

The Program Backlog consists of upcoming Features that are planned to be delivered by a single Agile Release Train. During Release Planning, the features that are planned for the PSI are broken into Stories and tentatively allocated to individual upcoming sprints in the team backlog. In addition, some of the future work is planned for upcoming periods; in this case the team backlog can also contain future features and the implementation estimate (in story points). In other cases, a program-level feature requires multiple teams to deliver it, in which case a placeholder for that “teams part of the feature” and its size estimate is maintained in the team backlog.

Source 2. Team Context

The team has its own context as well. In addition to the stories needed to fulfill program features, the team typically has an identified backlog of Refactors, defects, research Spikes and other technical debt. These must be identified, estimated, persisted and prioritized as well.

Source 3. Other Stakeholders

Teams on the release train are not islands, and their backlogs will reflect certain stories that are in support of other team’s and stakeholder objectives. These can include research and estimating spikes, stories to reflect team dependencies, and other external commitments.

The Backlog Is Estimated

Continuous, relative estimating is a hallmark of effective agile enterprise teams. In the team backlog, most backlog items, including stories and future features, are estimated. If the feature can be implemented solely be the team, then the feature estimate is the total estimate for the feature, and that estimate is used by Product Management to determine the denominator (job size) in the WSJF prioritization model. If the team can implement only a portion of the feature, then the total of the feature estimate for the program includes the rollup from each of the teams involved in the implementation of that feature. In this way, enterprises can play “what if” games with the program and portfolio based on team and program velocity (capacity) and rolling estimates of the size of an upcoming feature (or Epic which has been divided into features).

In addition, as portions of a feature are implemented, then the feature placeholder in the team backlog should be updated to reflect an estimate for only the work remaining, that portion which has not been planned or divided into stories. In this way, a tooling query can be used to determine how much work is remaining for that feature. This provides transparency and visibility to the work in process and the work remaining. It also provides the ability to ignore sunk costs, in that if the work remaining does not contain value proportional to the remaining effort, the team or program can pivot to more important work and kill the remaining work on that feature, thus freeing capacity for higher value jobs.

Optimizing Value Delivery and System Health with Capacity Allocation

One of the challenges every team faces is how to balance the backlog of internally-facing work—maintenance, refactors and technical debt—with the new user stories that deliver more immediate value. “All new user stories all the time” may work for a bit and even provide immediate gratification in the market, but this will be short lived as delivery velocity will be eventually slowed by a crushing load of technical debt. In order to avoid velocity reduction and to defer the need for wholesale replacement of the system due to technologic obsolesce, agile teams invest continuously in evolving the technical underpinnings of the solution, as well as keeping existing customers happy with bug fixes and enhancements.

This complicates the challenge of prioritizing work as the Product Owner is constantly trying to compare the value of three unlike things: 1) defects; 2) code refactors, redesigns, technology upgrades; and 3) new user stories. And there is no upper limit to the demand for any of these things! Fortunately, we have other tools in our lean and agile toolkit that can address this problem. In KANBAN, Anderson [2] notes: “Once we establish WIP limits for the flow through the system, we can consider capacity allocation by work item type or class of service…capacity allocation allows us to guarantee service for each type of work received by the kanban system.” With capacity allocation, the teams simply make a policy decision as to how much of their total effort can be applied by for each type of activity, as Figure 2 illustrates.

Figure 2. Team Backlog Capacity Allocation

Once that decision is made, the teams still need to select the highest priority backlog items from each slice to implement in each sprint. For User Stories which are committed to the program, sequencing is probably already predetermined by Release Planning commitments. But for local stories, refactors, defects, etc., the teams can prioritize those using value/size, (or even apply full WSJF). In addition, in order to balance long-term product health and value delivery, the percentage allocation to each type can be changed over time (for example, for each PSI/Release).

Backlog Grooming

We noted above that the backlog contains some stories that are in an advanced state of maturity, essentially ready for implementation without too much risk or surprise. Since the whole team is involved in this process, most teams take a cadence-based approach to this process as well, typically by having at least one team workshop per sprint (or even one per week), whose sole focus is to look at upcoming stories (and features and epics as appropriate), discuss and estimate, and establish an initial understanding of acceptance criteria. There is no standard term for this meeting, but we use Backlog Grooming to describe this meeting in the Framework, while also recognizing that the backlog grooming function is continuous and cannot be relegated to a single meeting timebox. Also, for teams applying Acceptance Test-Driven Development, they’ll typically invest even more up-front time in developing specific acceptance tests, sometimes in special sessions they often call specification workshops. In addition, as multiple teams are doing backlog grooming, new issues, dependencies and stories are likely to result, so the process of backlog grooming helps surface underlying problems with the current plan.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.

Last update: 4 May, 2013