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

The Team Backlog contains user and enabler stories that originate from the program backlog, as well as stories that arise locally from the team’s specific context. It can contain other work items as well, representing all the things a team needs to do to advance their portion of the system.

The Product Owner (PO) is responsible for the team backlog. Since both enabler and user stories are part of the backlog, it’s important to allocate capacity in a way that ensures investments are balanced across conflicting needs. This is based on the capacity allocation of the whole Agile Release Train and 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

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.

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

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.

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

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, 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

The team backlog must always contain some stories that are in an advanced state of maturity, essentially ready for implementation without significant risk or surprise. Agile Teams take a flow-based approach to maintaining this level of backlog readiness, 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: 21 June, 2017