Backlog

Backlog2018-07-16T16:30:35+00:00

What is a Backlog?

Definition

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.
  • Stories.
  • Non-functional Product requirements.
  • Bugs.
  • Spikes & knowledge capture.
  • Tasks.
  • 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.

Backlog structure

Recommended fields

Any Backlog should probably include these fields as a minimum.

FieldFunctionBacklog*
IdentifierArbitrary identifier that is maintained even when other detail (e.g., title) change. Ensures consistent referencing.Product
TitleCurrent brief description of the item.Product
User typeA means of grouping related stories into functional or organisational themes.Product
AuthorSME or contact for clarifying & articulating the item.Product
ProductOf which Product is this item part?Product
Business valueEstimated contribution to the business. The basis of prioritisation.Product
Maturity levelPlaceholder, concept, epic, theme, feature, story.Product
ReleaseTo which Release is this item assigned?Release
IterationIn which Iteration will this item be implemented?Iteration
EstimateHow much effort will implementing this item take?Release
PriorityHow urgent/important is it to implement this item?Product
StakeholdersWho has an interest in this item (for Showcases, etc.)?Release
Extended TeamWhose support or authority is needed to implement this item?Release
StatusHow far has this item progressed towards implementation?Release

*   Which is the latest Backlog in which this item needs to be documented?

NB:

  • 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.

Optional fields

There are other fields that may be useful.

FieldFunctionBacklog
Story detailsAgile-standard description of what is to be implemented.Release
Acceptance criteriaUser-defined criteria for deciding when the story is complete.Iteration
Story typeUser, strategic or foundational.Release
DependenciesOther items or factors (e.g., seasonality) on which this item depends.Release
DeveloperWhich team member will implement this story?Iteration
UserThe business/operational expert & authority who will collaborate with the developer on this story.Iteration

NB:

  • 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?

Backlog levels

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.

Sharing Backlogs

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.

Backlog maturity

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.

Product Backlog

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.

Release Backlog

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.

Iteration Backlog

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.

Story Maps

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.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?