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.
A ‘living backlog’ is one that:
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:
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.
In a Kanban-like approach each Iteration represents a ‘bucket’ of functionality to deployed.
Teams using Scrum will include the sprint iterations within the iteration for the release/deployment
Teams who deploy frequently will benefit by using the Iteration path to manage their different release horizons, for example:
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
These can be used to align the backlog to the original business case
Note: Your work-items may have different names from those above.
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.
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.
In this example from an online retail application, the Area Path is used to slice the backlog by role.
Here the Area path is used to slice up a product like Outlook, by functionality
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:
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.
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.
Email Bazil Arden
© Copyright 2018 RippleRock