Learning Scrum - The Product Backlog

http://www.mountaingoatsoftware.com/scrum/product-backlog

The Product Backlog is the master list of all functionality desired in the product. When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of easily. This is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.

Product backlog items can be technical tasks ("Refactor the Login class to throw an exception") or more user-centric ("Allow undo on the setup screen"). My preference is to express the product backlog in the form of user stories, which are a technique borrowed from Extreme Programming, another agile process.

The product owner shows up at thesprint planning meeting with the prioritized product backlog and describes the top items to the team. The team then determines which items they can complete during the coming sprint. The team then moves items from the Product Backlog to the Sprint Backlog. In doing they expand each Product Backlog item into one or more Sprint Backlog tasks so they can more effectively share work during the Sprint. Conceptually, the team starts at the top of the prioritized Product Backlog list and draws a line after the lowest of the high priority items they feel they can complete. In practice it is not unusual to see a team select, for example, the top five items and then two items from lower on the list but that are associated with the initial five.

An example Product Backlog from a real project appears as the following:

This Excel spreadsheet shows each product backlog item assigned a general priority (Very High, High, etc.) by theProduct Owner. Estimates have been developed by the developers but it is understood that they are very imprecise and are useful only for rough assignments of tasks into the various sprints.