Team Backlog

Definition of BACKLOG [1]

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.

—SAFe Authors

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 local context. It may include other work items as well, representing all the things a team needs to do to advance its portion of the system.

The Product Owner (PO) is responsible for the team backlog. Since it includes both user stories and enablers, it’s essential to allocate capacity in a way that balances investments across conflicting needs. The allocation takes into account the needs of both the Agile Release Train (ART) and the specific team.

Details

While ‘backlog’ seems to be a simple notion, it includes some critical concepts:

• It contains all things undone. If an item is in there, it might get done. If it isn’t, 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 for completion.

• It has a single owner—the Product Owner—who protects the team from the problem of multiple stakeholders, each with potentially divergent views of what’s important.

• All team members can enter stories into the backlog.

• The backlog contains user, enabler, and improvement stories; the last are those stories that capture the results of the team’s Iteration Retrospective.

The team backlog conveniently hides some of the complexity of Agile at scale. Figure 1 depicts the team backlog and its three primary input sources.

Step 1 on the left shows Program Backlog, which is a stack labeled NFRs at the bottom. The stack has seven layers, the second of which has a cut through it, and the fourth is shaded differently. Some layers of the stack are connected to one or more layers of another stack below it. This stack is also labeled NFRs at the bottom, and also has seven layers. The first layer is labeled Feature, the second is labeled Team’s part of a feature/enabler, and the rest are collectively labeled Stories. The second layer is sectored and the sixth is shaded differently. Steps 2 and 3, that have icons representing Team Context and Other Stakeholders point to the second stack. Refractors, Maintenance, and Other technical debt are listed under Team Context. Other team dependencies, Other commitments, and Spikes/research are listed under Other Stakeholders.

Figure 1. Input sources for a team backlog

The program backlog consists of upcoming Features that are planned to be delivered by an ART. During Program Increment (PI) Planning, the candidate features for the PI are split into stories by the teams and tentatively scheduled into upcoming Iterations in the team backlog.

Teams in the ART are not islands, and their backlogs will contain some stories that support other teams’ work and the ART’s PI Objectives. These can include spikes for research and estimation of features, Capabilities, and even Epics.

In addition to the stories needed to fulfill features, the team typically has a backlog of local stories representing new functionality, refactors, defects, research, and other technical debt. These are written as enabler stories, which are estimated and prioritized like user stories.

Optimizing Value Delivery 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 business value.

Focusing solely on business functionality may work for a bit and even provide immediate gratification to the market, but this will be short-lived, as delivery velocity eventually will be slowed by a crushing load of technical debt. Teams then must continuously invest in both evolving the architecture of the solution and keeping existing customers happy with bug fixes and enhancements, so as to avoid the need for wholesale replacement of the system due to technological obsolescence.

Balancing the different types of work complicates the challenge of prioritization, as the PO is trying to compare the value of unlike things: defects, refactors, redesigns, technology upgrades, and new user stories. And there is no upper limit to the demand for any of these things!

Similar to the program backlog, teams use ‘capacity allocation’ to determine how much of their total effort can be applied to each type of activity for a given time period, as Figure 2 illustrates. The PO, in collaboration with the team, selects the highest-priority backlog items for each ‘slice’ of the capacity allocation to implement in an iteration.

A stack of 10 layers is shown on the left. The first six layers pertain to User stories, the next layer to Refractors plus, the following two layers to Maintenance, and the topmost again to User stories. The pie-chart is shown beside the stack, labeled Capacity Allocation. One-fourth of the circle in the fourth quadrant pertains to Maintenance, a small portion below it to Refractors, and the rest to User stories. A legend on the right shows the colors to pertain to User stories, Refractors plus, and Maintenance.

Figure 2. Team backlog capacity allocation

For stories that are committed to the program, sequencing is probably already predetermined by PI planning commitments. In contrast, for a specific team’s local stories, the PO can sequence those using ‘value/size’ or even apply full Weighted Shortest Job First (WSJF) where beneficial. Also, to balance long-term product health and value delivery, the percentage allocation to each ‘slice’ can be changed over time. Such changes typically occur at PI boundaries.

Backlog Refinement

Since the team backlog must always contain some stories that are essentially ready for implementation, without significant risk or surprise, backlog refinement should be a continuous process. Agile teams take a flow-based approach to maintaining this level of backlog readiness, typically by having at least one team backlog refinement workshop per week; avoid limiting backlog refinement to just a single meeting. The sole focus of this workshop is to look at upcoming stories (and features, as appropriate), discuss and estimate their scope, and establish an initial understanding of acceptance criteria.

Teams applying Acceptance Test–Driven Development (ATDD) will typically invest even more time up-front in developing specific acceptance tests, sometimes in sessions often called ‘specification workshops.’ Also, given that multiple teams will be doing backlog refinement, new issues, dependencies, and stories are likely to emerge. In this way, backlog refinement helps surface problems with the current plan, which can then be discussed in ART sync meetings.

LEARN MORE

[1] https://www.merriam-webster.com/dictionary/backlog.

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