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.
The Team Backlog contains user and enabler Stories that originate from the Program Backlog, as well as stories that arise 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 their 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. This capacity allocation takes into account both the needs of the team and the Agile Release Train (ART).
While ‘backlog’ seems to be a simple notion, there are some critical concepts behind it, for example:
- Indeed, it contains all things. 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.
- It contains user and enabler stories, and improvement stories, which 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 illustrates a view of the team backlog with its three primary input sources.
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 on the ART are not islands, and their backlogs will contain some stories that support other teams’ work and the ART’s Program PI Objectives. These can include spikes for research that are required to support the 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 technical debt. These are written as enabler stories, which are estimated, and prioritized in the same manner as user stories.
Optimizing Value Delivery and System Health with Capacity Allocation
Just like the ART itself, every Agile 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 while, and even provide immediate gratification to the market, but this will be short-lived, as development velocity will eventually be slowed beneath the weight of increasing technical debt. To mitigate this, teams continuously invest in evolving the architecture of the Solution, as well as keeping existing customers happy with bug fixes and enhancements, to avoid the need for wholesale replacement of the system due to technological obsolescence,
Balancing these 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!
Just like the program backlog, teams apply ‘capacity allocation’ to the team backlog to determine how much of their total effort can be used for each type of activity in a given timebox, as Figure 2 illustrates. The PO in collaboration with the team select the highest-priority backlog items for each ‘slice’ of the capacity allocation to implement in an iteration.
For stories that are committed to the program, sequencing is probably already predetermined by PI planning commitments. But for a specific team’s local stories, the PO can sequence those using ‘value/size’ considerations or even apply full Weighted Shortest Job First (WSJF) where it is beneficial. Also, to balance long-term product health and value delivery, the percentage allocation to each type can be adjusted over time, typically at PI boundaries.
The team backlog must always contain some stories that are ready for implementation without significant risk or surprise. Agile teams take a flow-based approach to maintain this level of backlog readiness, typically by having at least one team backlog refinement event per iteration (or even one per week). The sole focus of backlog refinement is to look at the upcoming stories (and features, as appropriate), discuss, and estimate, and establish an initial understanding of acceptance criteria.
The backlog refinement process is continuous and should not be limited to a single meeting timebox. Teams applying Behavior-Driven Development will typically invest even more time up-front in developing specific acceptance tests but benefit from a rich set of (potentially) automated functional tests that can continuously validate the solution. Also, as multiple teams are doing backlog refinement, new issues, dependencies, and stories are likely to result. In this way, backlog refinement helps surface problems with the current plan, which will come under discussion in ART sync events.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 31 December 2019