Product Backlog
The Product Backlog is the master list of all functionality desired in the product. 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.

The product owner shows up at the sprint 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.

Product backlog in Scrum is simply a list of things needed to be done. As such it is a little different from many other to-do lists. The difference comes from the small peculiarities of the way you handle the backlog. Here some some things to note about the product backlog.
  • Product backlog always lists items adding value for the customer. It includes functional requirements and non-functional requirements. It can also include items required by the team, but only the ones that will eventually bring value to the customer, e.g. taking into use a continuous integration server in order to guarantee the continuous end product quality.
  • Product backlog cannot include concrete low level tasks and requests for building the intermediate artifacts. For example, it cannot include request for producing the design document unless customer has to ship it further for some purpose.
  • Product backlog utilizes the simplest and the most effective way for prioritizing requests - a simple list. Such a method does not allow for having 100 absolute max priority features and forces the product owner to actually make decisions about the feature priorities.
  • The higher the items are located on the product backlog, the more detailed they are. Items for the closest couple of months are usually quite detailed, while items that will be worked on in some 6-12 month can be defined very broadly and imprecisely.
  • When there are several interdependent teams in the company or department, typically they all have a single product backlog and pull their work from it.
  • Product backlog does not typically include the detailed requirement information. Usually the final requirement details are figured out with the help of the customer, when the requirement is being implemented.
Ease of use, clear and transparent purpose is what makes the product backlog so useful for seeing into the project status.

We would like to suggest you the following list of usefull resources on the topic: