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.
Transcript
As work progresses, large bodies of work at the bottom of the product log were raised up in priority order. As those large items enter the second 20%, they’re broken down and as those items then enter the top 20%, they’re broken down further. This continual process of breaking down large items into smaller items is known as refinement, and it is recommended that teams spend 10% of their time refining the product backlog.
There are a number ways of maintaining the product backlog, and here are a few examples. My favorite way is to use index cards. Index cards are quick and easy way of ordering the product backlog from highest priority to lowest priority.
