Scrum Artifact: Product Backlog

Posted on: 05-13-2009 Posted in: Scrum

As I’m gathering information and slowly writing the content of my book, there is some information I need to refer to in the book but I don’t want to include as it distracts the reader. As such, I decided to start keeping that information and post it on this blog. It will be easy to know when a blog post is done in the context of the book as it will be tagged “the agile bi book“. Today’s post relates to the Product Backlog.

The Product Backlog

Definition

The Product Backlog is simply a list of customer requirements needed to complete the project and sorted by business value. It is initially prepared at the beginning of a project by the Product Owner and remains active throughout the duration of the project as completed items get removed while new items are added.

How the Product Backlog works

As time goes by, the highest priority items in the Product Backlog get broken down into smaller chunks as they become part of the Sprint Backlog.

The Product Backlog is property of the Product Owner while the business value is set by the Product Owner, the development effort is set by the team. 

Benefits of using a Product Backlog

1) It’s a simple list, discussed face-to-face
2) It provides the customer with control
3) The product backlog is allowed to change.
4) Inspection and adaptation
5) It resolves dependencies timely, and without fancy pansy dependency graphs.
6) It allows for some longer term planning
  • It’s a simple list, discussed face-to-face;
  • It provides the customer with control;
  • The product backlog is allowed to change;
  • Inspection and adaptation;
  • It resolves dependencies timely;
  • It allows for some longer term planning.

In Summary

The Product Backlog:

  • is simply a list of things needed to be done in the context of the project;
  • always lists items that add value for the customer;
  • may include functional requirements and non-functional requirements;
  • can also include items required by the team, but only the ones that will eventually bring value to the customer;
  • cannot include low level tasks. 

References:

About the Author

Martin Proulx
I am an agile organizational coach and president of Pyxis Technologies.   Most people agree that I am an effective coach, an influential leader and a change agent oriented towards achieving extra-ordinary results. For nearly 20 years, I have put in place and managed software development organizations. Throughout the years, I have developed an expertise in organizational development, business process reengineering, people and project management.