Scrum Product Backlog: What Works and What Does Not

A Scrum Product Backlog is the backbone of any product that is to be developed using Agile Scrum methodology. It is the master list of all desired functionalities and features that the product should incorporate. It may also contain a list of enhancements to existing functionalities or list of problems found during the earlier development iterations. Some Agilists have gone to the extent of recommending the addition of project themes, epics (large user stories), probable risks and issues to the Product Backlog, but whether a Product Backlog is a place for these elements is debatable.

Post-It notes, whiteboard, spreadsheets (MS Excel®) or web-based Scrum management tools – one can find a Product Backlog in any of these forms! When an Agile team is collocated and works in close proximity, Post-It notes, whiteboard or spreadsheets work great to manage and track user-stories. However, if the teams are working in a distributed environment, there may be a need for online Scrum management tools such as ScrumWorks® Pro or Scrum Time.

As collaboration is one of the fundamental principles of Agile, all stakeholders are encouraged to contribute their ideas towards the betterment of the product being developed. Yet, the Product Backlog is the property of the Product Owner who understands the business and values that the end-result would deliver.

Over a period of last 5 years, I have discovered and studied what works and what doesn’t when compiling and managing a Product Backlog. Though not comprehensive, this is my attempt to share what I have learnt from my experience about the Scrum Product Backlog, and it may prove nifty to anyone passionate about Agile.

What works...
1. Assigning priorities to Product Backlog entries based on their complexity and impact

When creating an entry in the Product Backlog, a user-story or requirement should hold a Complexity Factor and a User-Impact Factor. The Complexity Factor, on a very broad scale tells how much effort is involved in developing the particular requirement. The User-Impact Factor describes how important the functionality is for the end-user of the product while keeping in mind the ultimate goals of the product/service being developed. A matrix composed of complexity and impact for each Product Backlog item helps in deciding the priority of the requirement. E.g. A low complexity, high impact requirement would be at the top of the priority list, a high complexity, high impact somewhere in the middle, and high complexity, low impact right at the bottom. However, only the Product Owner can prioritize the Product Backlog. Also, items with highest priority are placed at the top of the Product Backlog.

Determining the complexity based on effort-estimate should be a team activity. Techniques such as PERT and Points System using Fibonacci Numbers can be used to compute effort-estimate, but their discussion is beyond the scope of this article.

At least one person who understands the business and can ably represent the end-users should be part of the team deciding the User-Impact of each item.

2. Ongoing maintenance of the Product Backlog

Regularly reviewing, and adding detailed definitions to the items that are at the top of the Product Backlog ensures that there is a well defined, prioritised and estimated Product Backlog for the upcoming few Sprint iterations. It is the Product Owner’s responsibility to ensure that the Product Backlog can continuously provide a stream of items for the Sprint Backlog.

What does not work...
1. Everyone has “Full Access” to the Product Backlog

Duplication, requirements not qualified according to the original goals of the product/service, and irrelevant or vague demands are some of the side-effects of giving everyone full control of the Product Backlog. E.g. before I came on board on one of the projects that I was handling, everyone including the sales team, senior management, customer support, business analysts and developers had access to the Product Backlog. As a result, the Product Backlog looked more like a dumping- ground or a place-holder for people’s thoughts rather than a collection of user-stories and probable requirements for the product being developed. Several entries in the Backlog were duplicated or did not at all support the goals of the product. Eventually, we had to put in several hours worth of work to filter out the irrelevant requirements and consolidate the duplicate ones. After filtering and consolidating (and using up 15 person days), the number of entries in the backlog came down from 600+ to under 450!

Although creating a Product Backlog should be a group-activity, it’s best not to relinquish control of the backlog to anyone and everyone in the team. All users’ demands and requirements should be discussed using techniques such as brainstorming, interviewing and survey (Delphi), but entries should be moderated by a select few, preferably by the Product Owner and business analysts. At no point should the moderators lose focus of the ultimate goals of the product/service being developed and every new probable item should be scrutinized to see if it fits these goals. Restricting the number of people creating entries in the backlog will reduce the chance of duplication and thus decrease waste of time and effort.

2. User-stories entered in the Product Backlog are too brief

One-liners in the Product Backlog leave too much room for speculation and imagination about what the user and the requirement actually demand. If such requirements somehow slip through into the Sprint Backlog, there is a good chance that someone misinterprets the one-liner and converts it into a functional specification far from the customer’s actual needs. This can cause considerable rework, schedule slippage and budget overshoot. E.g. consider a one-line requirement “Showroom manager would like to see a report of used cars sold.” The requirement does not specify anything about which columns the report should contain, the dates between which the records should be picked, or how they should be sorted.

User-stories sitting very low in terms of priority and without any plausible chance of making it to a Sprint Backlog in the near future can be exceptional cases, and can be sketchy at the most.

Moderators can reduce problems arising from brief user-stories by deciding on some ground-rules and format for writing the stories. Along with a broad description of what the requirement demands, the following details should also be added to the user-stories: effort-guesstimate, impact on product’s functionality, priority, and name of end-user or customer who made the demand. Wherever possible, the requirements should be quantifiable, e.g. “Screen for ‘All Vehicle Details’ is taking more than 8s to load – should load in less than 4s.” All this will reduce the scope of misinterpretation, need to redefine the requirements, and thus reduce chances of wrongly developing the functionality.

Following these simple guidelines when managing a Scrum Product Backlog should steer most new Agilists clear of the pitfalls that we fell in when we started off on this path. After all, we don’t want to reinvent the wheel, do we?