Definition of BACKLOG
1. A large log at the back of a hearth fire
2. An accumulation of tasks unperformed or materials not processedBurn 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 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).
Details
While ‘backlog’ seems to be a simple notion, there are some critical concepts behind it, for example:
- 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 the weight of increasing technical debt slows development velocity. To mitigate this, teams continuously invest in evolving the Solution’s architecture as well as keeping existing customers happy with bug fixes and enhancements. This avoids 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 Product Owner (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.
Backlog Refinement
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). Backlog refinement looks at upcoming stories (and features, as appropriate) to discuss, estimate, and establish an initial understanding of acceptance criteria. Teams may apply Behavior-Driven Development, using and use specific examples to help clarify stories.
The backlog refinement process is continuous and should not be limited to a single event timebox. Teams may revisit a story multiple times before finalizing and committing to it in Iteration Planning. 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
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.Last update: 10 February 2021
