So what is the Product Backlog?

Trying to define what is a product backlog is always a tricky business. One definition I use from time to time is:

The product backlog is just another way of describing the system requirements and serves to describe the work needed to be done

Which is a good way to simplify it to death. I had reasonable success using this definition with agile beginners, but clearly it doesn’t start to capture its entire meaning.
The more official definition taken from the Scrum guide at Scrum.org is:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

Which is more complete, but still raises quite a few questions. for example:

• What is everything? (new features? bugs? technical enhancements?…)
• If it’s a single source does it contains all the details? (i.e. the requirement docs)
• what is actually written inside it (how do we write those requirements? use cases? stories? plain English?)
• Is it a business facing document (i.e. read by clients and user) or is it a technical document (i.e. serves the team who needs to understand what to build)

So what is the Product Backlog

when trying to answer this I go back to my first initial encounter with  agile. At that time what I actually read and first saw was the work done by Ron Jefferies and Kent beck on eXtreme Programming. and what I still recall today is the simple statement in which Kent Beck explained that the whole purpose of agile is to bring all involved parties to one table and make them work together in order to create great products. (unfortunately I cant seem to locate the exact quote). At that time I didn’t know what a Backlog was and I was just starting to understand all the various agile techniques. but that statement just stuck and for me it’s the best way to describe what is the main goal of the Product backlog.
Forget about stories, requirements prioritization, acceptance criteria and all other technicalities which are associated with the product backlog.
In essence, when done right, the product backlog is the one “thing” that makes all involved parties converge communicate and cooperate in order to make the product a success.

The interface between the problem space and the solution space

To take it down into more specific terms what I think that the product backlog main role in the project is to serve as an interface between the business facing aspect of the product AKA the Problem space and the technical sides AKA the Solution space. On one side the Problem space is using the backlog in order to help it define the problem and describe on his terms WHAT its need to be done in order to help with the problem and on the other hand the Solution space uses the backlog in order to sort out the actual work. the team need the backlog in order to understand what is actually expected from him, what exactly he should build, what needs to be developed first. and most important use it to create a shared language he can use to talk to the business people and create a shared understanding.
And I’m guessing that this dual nature of the product backlog is what sometimes causes all these misunderstandings we see. here are some examples:

1. Every team occasionally needs to do things which are very technical in nature and involves a significant amount of effort. Being the single source of incoming work its not unreasonable that they will want to add it to the product backlog. However, these kind of things tends to be less understood by the business side, and suddenly there’s a conflict: “why do you add theses things that has no value to me?” asks the PO. “you know what, if you need it lets keep it there but please reduce the priority of it” which practically means ok I will let you put it there, but lets make sure that you actually wont work on it.
2. Being the single source of work, a reasonable team working in short iterations will expect backlog items to be of a certain size (typically a few days worth of effort). However, splitting requirements in a sensible manner is really hard work. The “Problem space” natural tendency is keeping the items size much bigger. I’m guessing it makes things easier to manage on their side (and of course avoid the extra work of splitting those into small chunks) and again we have a conflict
3. Not only that the Solution Space demands the things to be small, it also needs them to be FULLY prioritized. Even more hard work for the “Problem” side.

Now don’t get me wrong, there is no right and wrong here. All sides in all these situations are “right”. IF you look at it from there side. 

Treating the Product backlog as an interface

The moment all sides respect the fact that the product backlog is not only there to serve their needs alone, things tends to become much easier. When Technical people understands that the product backlog is the place in which business side describes the “Problem” and respect that. They find it much easier to keep it in a way which is understandable by the business side (avoiding the regular technical language they tend to use internally). When the business side respect the fact that the backlog is used to manage the actual work done. they find it reasonable to invest the effort needed in splitting, prioritization and other activities needed.
So don’t forget the Product Backlog is an interface. it’s the one thing that can be used to establish effective and productive communication by all sides of the business. Take advantage of it.


if you are also

• Having a hard time splitting user stories to shippable items?
• Struggling with predicting when will we reach the deadline?
• Having a hard time with prioritization of requirements?
• Does it seem that the team never understands what you mean?

Then come join our Product owner workshop.

Posted in: Agile practices,Scrum