With this video I’m try to communicate two messages; firstly, the product backlog is a simple list for work, and secondly, it’s ordered in a single rank order, often from highest priority to lowest priority. Even though the Product Backlog is a simple concept it can be used to model very complex behaviors. Ken describes the Product Backlog in the Scrum Guide:
[blockquote cite=”Ken Schwaber” type=”left”]The requirements for the product that the Team(s) is developing are listed in the Product Backlog. The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization. Product Backlog is never complete. The initial cut at developing it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Backlog is dynamic in that it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, Product Backlog also exists.
The Product Backlog represents everything necessary to develop and launch a successful product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases.[/blockquote]
You’ll notice that Scrum doesn’t dictate how to write a product backlog. For example, Scrum doesn’t dictate that the product backlog is written in the form of User Stories, although it often is. Scrum simple says that you need a Product Backlog and that it needs to be ordered in a single rank order.
Here’s an introduction to the concept and main characteristics of the Product Backlog.