When a project is initiated there is no comprehensive, time-consuming effort to write down all foreseeable tasks or
requirements. Typically, a project writes down everything obvious, which 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.
During the Sprint Planning Meeting the Product Owner prioritizes the
items in the Product Backlog and describes them 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.
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"). A very interesting prospect is expressing Scrum backlog items in the form of
Extreme Programming's User Stories.
The Product Backlog can be maintained in an Excel spreadsheet. An example from a real project is shown below. This
Excel spreadsheet shows each product backlog item assigned a general priority (Very High, High, etc.) by the Product
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.
 |
