Team Backlog

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. It can contain User or Enabler Stories, most of which are stories that originate from the Program Backlog, while some others are local to the team’s specific context. The team backlog is owned by the Product Owner, although backlog “ownership” does not mean that the PO is the only one to populate it but rather that the PO prioritizes the work for execution.

Since both enabler and user stories are part of the backlog, it is important to apply capacity allocation to help ensure that investments are balanced across conflicting needs. This is based on the capacity allocation of the Agile Release Train as a whole and on the needs of the team.


While “backlog” seems to be a simple notion, there are a number of subtleties that create the power behind this simple construct.

  • It truly contains all things. If a thing is in there, it might get done. If it isn’t there, there is no chance that it will get done.
  • It’s a list of “want to do” items, not a commitment. Items can be estimated (preferable) or not, but neither case implies a specific time commitment as to when any of them 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.
  • All team members can enter stories that they think are important into the backlog.
  • It contains User Stories, Enabler Stories, and “improvement stories,” which are those stories that capture the results of the team’s Iteration Retrospective.

The Team Backlog is a simple and unifying construct, and one that conveniently hides some of the complexity of 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
Figure 1. Exploded view of a Team Backlog

The Program Backlog consists of upcoming Features that are planned to be delivered by an Agile Release Train (ART). During PI Planning, the features that are planned for the Program Increment (PI) are broken into Stories and tentatively allocated to individual upcoming Iterations in the team backlog. In addition, some future work is planned for upcoming periods; in this case the team backlog can also contain future features that have yet to be broken into stories. At other times a feature requires multiple teams for delivery, in which case a placeholder for that team’s part of the work, and its size estimate, is maintained in the team backlog.

The team has its own context as well. In addition to the stories needed to fulfill features, the team typically has a backlog of local stories representing new functionality, refactors, defects, research spikes, and other technical debt. These latter must also be identified, written as enabler stories, estimated, and sequenced.

Teams on the release train are not islands, and their backlogs will reflect certain stories that are in support of other teams’ and stakeholders’ objectives. These can include research and estimating spikes for features, Capabilities and even Epics, stories to reflect team dependencies, and other external commitments.

Optimizing Value Delivery and System Health with Capacity Allocation

Just like the ART itself, every team faces the problem of 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 functionality 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 technological obsolescence, 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 sequencing work, as the Product Owner is constantly trying to compare the value of three unlike things: 1) defects; 2) refactors, redesigns, and technology upgrades; and 3) new user stories. And there is no upper limit to the demand for any of these things! Much as in the program backlog, capacity allocation is used by the teams to make a policy decision as to how much of their total effort can be applied to each type of activity for a given period, as Figure 2 illustrates.

Figure 2. Team Backlog capacity allocation
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 iteration. For stories that are committed to the program, sequencing is probably already predetermined by PI planning commitments. But for local stories, the Product Owner can sequence those using value/size, or even apply full WSJF where beneficial. 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 PI).

Backlog Refinement

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 flow-based approach to this process as well, typically by having at least one team workshop per iteration (or even one per week) whose sole focus is to look at upcoming stories (and features, as appropriate), discuss and estimate, and establish an initial understanding of acceptance criteria. There is no standard term for this meeting, but backlog refinement describes this meeting in SAFe, though it is recognized that the backlog refinement function is continuous and cannot be relegated to a single-meeting timebox. Teams applying Acceptance Test-Driven Development will typically invest even more up-front time in developing specific acceptance tests, sometimes in special sessions often called specification workshops. In addition, as multiple teams are doing backlog refinement, new issues, dependencies, and stories are likely to result. In this way the process of backlog refinement helps surface underlying problems with the current plan, which will come under discussion in ART sync meetings.

Learn More

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

Last update: 15 October 2015