The Product backlog is the place where the Product owner gathers and prioritizes all the functionality and deliverables he wants the team to work on.
Purpose and Logic
The backlog should contain all work currently on the horizon. Items that are still in the far future only need to be outlined roughly, but the level of detail must increase as an item moves closer to actually being worked on. The intended audience shifts over time: Items that are "far away" probably matter only to the product owner. They may be vague ideas or things that shouldn't be forgotten but have no significance now. Items that are "near" will soon need to be implemented, so they matter to the team in order to understand the preparations and work necessary.
The preferred format for describing desired functionality is by writing a User story which is both simple and effective. In order to be properly planned each User story should be accompanied by Acceptance criteria that outline clear criteria to measure the work result on.
The Product owner prioritizes the Product backlog by value. The items that are most important and generate the most value to the company have to be at the top of the list. Prerequisities evidently must have a higher priority than the items based on them.
There can never be two items with the same priority. This sounds simpler than it is but is an absolute requirement. The Product owner must always be able to tell which of any two items in the backlog comes first.
How to add new items
Often team members or external stakeholders have ideas that they want to add to the Product backlog. These can be added in the unscheduled section at the end of the backlog. The Product owner revises these entries from time to time and prioritizes them. The person adding them can also alert the Product owner to their ideas if necessary.
Estimations and Release Planning
Items in the product backlog need to be estimated by the team for the Product owner to understand their size. If no future perspective is required this can happen right before planning a new sprint.
Estimations become really useful however when it comes to looking at the future: If the Product owner wants to know by when he can expect a feature or a release containing a number of features to be ready, he needs to at least obtain estimates for all backlog items up to this point. By comparing the past speeds of the team's sprints with these numbers, he can get a fairly reliable idea of a realistic delivery date as well as worst and best case scenarios.
At Openbravo, the Product backlog for each team is located in the spreadsheet used by the team to plan and track their sprints.
In addition we are in the process of building a global master backlog that keeps track of the high-level goals we have across the teams.