Don’t Underestimate the Power of the Backlog

While there is no doubt that agility, at its core, requires a shift in mindset, one of the key tools used alongside that mindset (and apart from the retrospective) is the ‘Product Backlog’.  In software development this backlog is supposed to represent all of the business problems that a product is designed to solve.  By prioritizing and sizing the items in the backlog, agile teams always have an idea of what the next most valuable item is to work on.  This practice helps the team accrue value in the product as quickly as is practical.  Teams using Scrum select some highest priority subset of the remaining product backlog to work on in a given sprint.  The result of the sprint is ideally a product increment which solves the problems described by the backlog items.  The team then selects the next highest priorities and continues sprint by sprint until enough value has been accrued to warrant releasing a version of the product.

When applying the values and principles of Scrum outside the domain of software development, this backlog remains an important companion tool.  Depending on the domain, it may or may not be called a Product Backlog, but it remains a list of problems that represent a body of work (with an overall goal) and those problems are prioritized by value.  There may or may not be a need to size them, again depending on the domain and how the work is being managed.

Some examples of using this technique outside of software follow.

Goal: Create the organizational infrastructure for the management of a construction project.

When a team was tasked with setting up the organizational infrastructure necessary to manage the engineering, procurement and construction of a natural gas plant, they used a Mind Mapping technique to articulate the problems that needed to be solved (nodes) by the infrastructure and their root causes (sub-nodes).  Subsequently the team created a backlog of those problems and their common solutions.  The priorities were estimated simply by using the frequency by which the same root causes appeared as sub-nodes throughout the Mind Map.

The ‘Backlog’ in this case consisted of the problems to be solved. During each successive sprint, the problems were solved by a multidisciplinary team working on tasks related to creating, reviewing and approving the required artefacts to address the problems.

The ‘Product Increment’  in this case was an increment of functioning organizational infrastructure.

Goal: Help a team meet milestones required to meet a construction schedule.

When a multi-discipline team was tasked with meeting a series of milestones in a traditional project schedule, they identified which milestones they believed would be most difficult to meet based on empirical evidence.  The priorities were estimated based on the overall impact of missing those milestones.

Here, the ‘Backlog’ consisted of the problematic milestones to be reached and during each successive sprint the problems were solved by a multidisciplinary team working on tasks related to finding new solutions to those problems.  The team used a Breakdown/Breakthrough process  for each of those problems, therefore sprint tasks were related to discussing the problem, arriving at a novel solution, and implementing process or artefact changes to complete the deliverables on time.

The ‘Product Increment’  in this case was the successful completion of the deliverables according to the project schedule.

Even in the world of traditional project management, the power of the backlog is strong.  Can you see where you could define a ‘product backlog’ and a ‘product increment’ that fits your situation?