2010-12-01

The Product Backlog

Managers who have worked with products that are well-established in the market would be familiar with the maintenance pattern, where all work becomes a series of new feature additions, change requests or bug fixes on that product.

They would also know that it is in fact much easier to manage a project which is in this stage, because all work is defined as a series of discrete tasks that can be individually assigned, tracked, developed and released. Progress and performance can now be measured numerically, based on the number of tasks completed and the complexity of each task, as in any other industry.

In contrast, a project for developing the first version of a product tends to be more chaotic, more so when developed using one of the traditional waterfall models.
  • Multiple features are specified, defined and estimated by the project management team.
  • The engineering team tries to design and develop all these features in one big step
  • QA tries to test them all in another big step, and
  • the customer expects to see only the end result which consists of all these features.
A delay in any of these steps affects the final deadline that has been committed to the customer.

Using SCRUM, one aims to bring the project to the “maintenance state” described above as early as possible, so that all subsequent work can be defined as a series of tasks in a pipeline.

This is done by identifying the bare minimum functionality required to demonstrate a working application. Having reached this state, all subsequent work is defined as a series of tasks that adds more functionality to the existing application.

Consider the example of a scientific calculator software. One can define the baseline product as a simple calculator, capable of performing basic arithmetic operations such as add, subtract, multiply and divide. Clearly, this baseline product is too immature to release to the general market, but it can definitely be released to various internal stakeholders.

For example:
  • The QA team (and perhaps beta testers) can start testing for obvious bugs and edge cases.
  • The business analysts can either verify that the product is in line with their expectations, or make changes to the original requirements they had defined.
  • The user interface and usability experts now has a concrete application to provide recommendations against, and so on.

The significant benefit here is that all stakeholders can start providing inputs, and the company has the flexibility to make changes to the original requirements of the product based on these inputs.

It is important to note that all requirements are defined as a series of tasks. Each task can, at a minimum, be either a new feature to be added, or a change to an existing feature, or a bug fix. The job of the project manager now is to prioritize and manage this task pipeline efficiently.

In the calculator example above, subsequent feature requests could be for implementing square and square root functionality, sin and cos functions, etc, such that each of these functions become a separate task in the pipeline.

In SCRUM terminology, this pipeline is called the Product Backlog. Despite "Backlog" being a word with a slightly negative connotation, it is apt. The Backlog is the list of tasks that should be completed for the next deliverable version of the Product, and becomes the central axis around which all development efforts revolve.

No comments: