What is a Backlog?
The Backlog is the tool that connects the Product Plan to the team’s day-to-day work.
According to the Agile Alliance:
“A backlog is
– a list of features or technical tasks
– which the team maintains
– and which, at a given moment,
– are known to be necessary and sufficient
– to complete a project or release.”
Who owns the Backlog?
Although a Backlog item may have many stakeholders, the Backlog itself is owned by the Product Owner.
- Only the Product Owner can:
- decide whether an item can be included.
- authorise priorities.
- This ensures that the team have a single, unified point of contact with the external world.
- This greatly improves the efficiency of
- their work.
- the decision-making process.
Scope of the Backlog
The scope of the Backlog is also well defined by the Agile Alliance:
“The backlog is
– the primary point of entry for knowledge about requirements,
– and the single authoritative source defining the work to be done.”
So everything goes into the Backlog – everything:
- Ideas & concepts.
- Complete new Product types.
- Proposal for complete projects.
- Epics, features & themes.
- Non-functional Product requirements.
- Spikes & knowledge capture.
- Known issues & risks needing committed effort.
- Technical/engineering tasks (e.g., technical debt reduction).
- Sketches & notes.
In short, the Backlog should include anything that will take up the team’s time.
‘Necessary and sufficient’
The Agile Alliance’s definition argues that a Backlog contains all the items that are ‘known to be necessary and sufficient to complete a project or release’.
This is very ambitious, but highly desirable. At the same time it is not unachievable, especially if the remainder of the definition is understood properly:
“- if an item on the backlog does not contribute to the project’s goal, it should be removed;
“- on the other hand, if at any time a task or feature becomes known that is considered necessary to a project, it should be added to the backlog.”
Yet there are important reservations that still need to be made:
- Early in a project or Release, the scope and outcomes are typically too imprecise to know what specific ‘features or tasks’ are needed to complete work.
- Before Release planning is complete, many Backlog items will be so general that it is impossible to know whether or not the Backlog satisfies the definition.
- E.g., placeholders, concepts, epics, themes, etc.
- So early on, the formal definition is aspiration and goal, but not a fully sensible test.
- In summary, the Backlog is constantly evolving towards credibility.
So the Agile Alliance definition is a high but good ideal, and should be treated as such – in every sense.
Benefits of a Backlog
The presence of a Backlog doesn’t guarantee that the results the team deliver will be good, but the absence of a Backlog almost guarantees that they will be bad.
This is because a well-managed Backlog serves many more purposes than simply listing the work that needs to be done.
- An actively managed Backlog generates more value more quickly.
- Better prioritisation, opportunities identified, synergies detected, etc.
- It puts work into a sequence.
- So affected stakeholders can see when the work will be finished.
- And allows a flexible work strategy to be developed.
- It makes the team’s pipeline visible
- to the team.
- To stakeholders & the Product Owner.
- And so explains why they may have to wait for what they want.
- This obliges stakeholders who want work done to prioritise it among themselves.
- It makes background work visible to stakeholders & the Product Owner.
- And so explains what the team is doing when they aren’t implementing user stories.
- And why it is still important.
- It makes it easier to express trade-offs.
- By relative priority within the Backlog.
Any Backlog should probably include these fields as a minimum.
|Identifier||Arbitrary identifier that is maintained even when other detail (e.g., title) change. Ensures consistent referencing.||Product|
|Title||Current brief description of the item.||Product|
|User type||A means of grouping related stories into functional or organisational themes.||Product|
|Author||SME or contact for clarifying & articulating the item.||Product|
|Product||Of which Product is this item part?||Product|
|Business value||Estimated contribution to the business. The basis of prioritisation.||Product|
|Maturity level||Placeholder, concept, epic, theme, feature, story.||Product|
|Release||To which Release is this item assigned?||Release|
|Iteration||In which Iteration will this item be implemented?||Iteration|
|Estimate||How much effort will implementing this item take?||Release|
|Priority||How urgent/important is it to implement this item?||Product|
|Stakeholders||Who has an interest in this item (for Showcases, etc.)?||Release|
|Extended Team||Whose support or authority is needed to implement this item?||Release|
|Status||How far has this item progressed towards implementation?||Release|
* Which is the latest Backlog in which this item needs to be documented?
- You may also need to include other details for local reasons.
- Where the Backlog item is not a story (e.g., a risk or task), make sure that you use these fields constructively.
- Not all fields will apply.
- Some will need some interpretation.
There are other fields that may be useful.
|Story details||Agile-standard description of what is to be implemented.||Release|
|Acceptance criteria||User-defined criteria for deciding when the story is complete.||Iteration|
|Story type||User, strategic or foundational.||Release|
|Dependencies||Other items or factors (e.g., seasonality) on which this item depends.||Release|
|Developer||Which team member will implement this story?||Iteration|
|User||The business/operational expert & authority who will collaborate with the developer on this story.||Iteration|
- As with everything else in Agile, it is important to maintain creativity, flexibility & productivity.
- If the complexity of your Backlog is inhibiting delivery, change it.
- These data may be better recorded elsewhere.
How many Backlogs?
How many Backlogs are there?
Agilists frequently talk about ‘the Backlog’ – but at the same time talk about the Product Backlog, the Release Backlog and the Iteration Backlog as though they were different things.
- Each level of Backlog includes all the information from the previous level, and then adds a little more.
- Or makes the same information more precise.
- So you could make them all into a single Backlog, based on the same principles.
- A single Backlog.
- Refined as you move from Product to Release to Iteration.
- This is the basis of all Agile backlog tools and probably most in-house Backlogs too.
- But it’s not so easy to do using a pen-and-paper system.
Even where multiple teams are working on a Product, it has only one backlog.
- All items relating to the overall product are included in the same Product Backlog.
- This allows work to be visible, allocated and re-allocated across multiple teams.
- And also ensures that the impact of changes in one area are understood by all teams that might be affected.
- In a flexible Backlog tool, irrelevant parts of the overall Product Backlog may be concealed from individual teams.
- During individual Releases & Iterations.
The maturity of stories also increases as they move between Backlogs.
- They accumulate more information.
- The information becomes more precise.
- The information comes closer to describing what the stakeholders really want.
A Product Backlog can include almost anything.
- The only requirement is that the Backlog items should represent:
- The Product Vision.
- The actions and outputs needed to delivery that Vision.
- There is no standard for how well the Product Backlog defines them.
- It could be anything from placeholders to mature stories & tasks.
- There may not even be enough for development & delivery to begin.
A Release Backlog should contain only items that are close to being fully deliverable stories.
- Never less than epics or themes.
- Always capable of being turned into stories.
- And always estimated and prioritised.
- Ideally, the next 2-3 Releases should be at least this well defined.
Finally, the Iteration Backlog consists of nothing but mature stories.
- These may need to be developed still more as implementation proceeds.
- But they are always defined well enough for the team to commit to implementing them.
- Ideally, the next 3-4 Iterations should be at least this well defined.
The Backlog provides some of the features of a plan. If more details are needed, the Backlog may be supplemented – or even replaced – by a Story Map.