A living backlog needs a strong internal structure (skeleton) in order to effectively guide a project and maximise the value delivered to users.

That structure enables the backlog’s primary purpose of alignment to the business with a clear sense of priority and delivery sequence.

• Time and priority to know when value is likely to be realised and the relative priority of work. Using Iteration Paths
• Business-centric to enable stakeholders to guide development and understand the evolving scope. Using Area Paths

A ‘living backlog’ is one that:

• Guides decision making, identifies risks and possible opportunities
• Is comprehensible to all stakeholders and is ‘prioritise-able’
• Provides a solid basis for metrics to answer the question ‘are we on track?’
• Is up-to-date and can incorporate emergent changes in scope
• Reflects the different streams of work including: planned (project), BAU, Support and non-functional work

As opposed to many of the backlogs I see, which feel more like a necessary but unloved artefact to be dragged along by the team.

The four dimensions to structure and slice a backlog in TFS are:

• Iteration paths to provide a time and priority-based view
• Area paths to provide the business with a recognisable perspective that will inform decisions
• The work-item hierarchy (e.g. Goals-Features-PBIs) to align to the business case
• Tags to flexibly ‘cross-cut’ the backlog thematically

Iteration paths

The Iteration path enables the creation of burn-up chart for the next release / deployment and therefore key to be able to answer the key question:  Are we on track?

Well planned and maintained Iteration paths enable a simple burn-up chart like this.

This chart is from our www.senseadapt.com collection of simple visualisations for TFS. For more see my previous blog on the 'Landing Zone' chart

Deployments to live might be a regular cadence of monthly /quarterly drops, with a preference for more frequent, smaller batches.

Three ways to use Iteration Paths

Kanban

In a Kanban-like approach each Iteration represents a ‘bucket’ of functionality to deployed.

1. Release 15.8
   1. PBI_1 to PBI_n
2. Release 15.9
   1. PBI_1 to PBI_n

Scrum

Teams using Scrum will include the sprint iterations within the iteration for the release/deployment

1. Release 15.8
   1. Sprint 1
      1. PBI_1 to PBI_n
   2. Sprint 2
      1. PBI_1 to PBI_n
   3. Sprint n
2. Release 15.9
   1. Sprint 1
   2. Sprint 2

Mature Agile

Teams who deploy frequently will benefit by using the Iteration path to manage their different release horizons, for example:

1. In the next month
   1. PBI_1 to PBI_n
2. Within 3 months
   1. PBI_1 to PBI_n
3. 3-9 months
   1. PBI_1 to PBI_n
4. Probably never
   1. All the rest of the PBIs

The ‘probably never’ iteration is a useful parking spot for PBIs that are unlikely to see the light of day – but which stakeholders get twitchy about deleting. This keeps them out of the metrics and maintain focus on the more valuable PBIs

Work-item Hierarchy: Goals – Epics – PBIs – Tasks

These can be used to align the backlog to the original business case

• Goal: the business or technical goal that we are trying to achieve
• Feature: large stories or logical collections of PBIs.
• PBI: (Product Backlog Item) – the value-carrying piece of work that will be tracked through to live.
• Bugs: can either be linked to PBI or Epic
• Tasks: The actual work that needs to be done to deliver a PBI (mainly used in Scrum)
• Tests: linked to a PBI or Bug

Note: Your work-items may have different names from those above.

Area Paths

A living backlog must actively engage business stakeholders and the Area Path is the best way to do this.

Area Paths provide a recognisable, business-centric structure for the backlog. The structure will vary by type of project, see the three examples below.

Talk through the best structure with business stakeholders, as this is their window into the project.

The Area Path branches enable rolling up of PBI data. A simple way to show the relative effort and progress for a particular aspect of the project.

Area path by stakeholder

In the example below the money to fund the teams comes from the business divisions. The HR stakeholder naturally wants to quickly see a summary, including progress, of all the work that she is funding.

There will also be non-functional work e.g. automation of testing and deployment, which should have its own Area Path, if it does not relate to a specific top-level stakeholder.

1. Marketing
   1. CRM
      1. Campaign content
      2. Campaigns
   2. Planning
   3. Tracking
   4. Advertising resources
2. HR
   1. Recruitment
   2. Reviews
      1. Permanent
      2. Contractor
   3. BAU
3. Sales
   1. BAU
   2. CRM
      1. Prospects
      2. Clients
      3. Brokers
4. Non functional
   1. Automation
      1. Testing
      2. Build & deployment
   2. Refactoring
      1. Decommissioning system x
   3. New API for brokers

Area path by user / role

In this example from an online retail application, the Area Path is used to slice the backlog by role.

1. Marketing Manager
   1. Planning and reporting
   2. Managing range
   3. Managing Product
      1. Import new products
      2. Archive older products
   4. Promoting
      1. Promote a range
      2. Couponing set-up
   5. Managing content
2. Customer delivery assistant
   1. Preparing for delivery
   2. Delivering customer orders
      1. Taking payment at door
      2. Getting customer feedback
   3. Returning to depot

Area path by functionality

Here the Area path is used to slice up a product like Outlook, by functionality

1. Organise Email
   1. Search Email
   2. File Emails
2. Manage Email
   1. Compose email
   2. Read email
   3. Delete email
3. Manage Calendar
   1. View calendar
   2. Create appointment
4. Manage Contacts

Tags

Tags are great at thematically ‘cross-cutting’ the backlog.

For example:  all PBIs that relate to a compliance strand of work; PBIs that use a specific technology; PBIs that have dependency on a third party service

A word of caution:

• Tags are not easily delete-able. You need to first remove them from every item, then wait a few days for them to be cleaned out of the database. See this description of tag-cleansing process 
• it’s easy to duplicate or slightly misspell Tags, leading to consistency problems

Use a ‘Two Dimensional’ backlog

A ONE dimensional backlog is a simple, powerful way to prioritise work however they are tedious to review and difficult to comprehend.

A poorly understood backlog makes it difficult to see opportunities and deliver more value from the project.

A TWO dimensional backlog is simple way to show both the time aspect of the project and the functional / business perspective.

• Time (iteration paths) are shown down the side
• Functional / business (area paths) are shown along the top

Add some colour and shapes and it becomes multi-dimensional. The chart above uses colour to show the state of the PBI.

Below the size of the pie chart shows how much work is in each area whilst the colours show the state.

The two dimensional backlog is analogous to ‘Story Mapping’, a popular technique for gathering requirements for Agile projects. See http://jpattonassociates.com/user-story-mapping/

I urge to read Jeff’s book, it’s a great summary of better ways to gather requirements.

Later blogs will look at monitoring the health of the backlog, what are the vital signs that you should be aware of.

Tweet.