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 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 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. The allocation takes into account both the needs of the Agile Release Train (ART) and a team.
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 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 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 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 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 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!
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 given timebox, as Figure 2 illustrates. The PO in collaboration with the teams 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’ 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 type can be changed over time, typically done 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 maintaining this level of backlog readiness, typically by having at least one team backlog refinement workshop 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 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, 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 meetings.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 9 November 2017