In the simplest definition, the Scrum Product Backlog is a list of all the things that needs to be done in the project, ordered by their priority, with the most important showing at the top of the list.
The list is derived from the project roadmap and its requirements and is updated constantly by the Product Owner. Each item on the list contains a short description of the functionality desired in the product.
This is different from the traditional approach where you need to put a consistent effort upfront to generate a comprehensive (and usually lengthy) document which contained (almost) all requirements of the product and on which the customer has to agree upon before the development starts.
The reality has proved that such an approach is very costly and does not deliver the best results, as the customers usually do not have a complete, upfront, full picture of what they want it will be practically impossible to generate such a document without later to significantly updated it. Which makes the initial effort quite useless.
The Scrum approach is to start with high-level requirements (sometimes called epics), and delve in to each of these epics to identify more detailed, more refined requirements, called user stories.
To give an example, almost any product has some sort of user management facility, which can be seen as an epic (is a high-level requirements). Further more, the epic can be deconstructed in several user stories which are more concrete and the developers can work on them like: create an account, update account information, reset account password, deactivate an account. For each of this stories, a short description is provided by the Product Owner as follows:
“As an anonymous user, I want to be able to create my own account on the application with minimum information provided: first name, last name, e-mail address and password.”
The structure of the description is recommended to be as in the example because it’s showing the user perspective so it will be better understood by the customer;
Later on, during Sprint Planning Meeting, when the team decides to start the work on these user stories, the rest of the details will be identified (like if it is the case for the password to have a special format, or some other optional information like address should also be requested).
So, the analysis is actually completed at this stage, the user story is then transferred to the Sprint Backlog, and the developers can start working on it. When transferred, the user story can be broken in more detailed tasks (if is the case) in order to be implemented in parallel by the developers.
There are several characteristics that a Product Backlog has, as opposite to a simple to do list:
Estimation has two important roles:
It makes no sense to put concrete man-days effort until the user story is actually assigned to a Sprint backlog and the actual developer/developers can estimate it. Otherwise, since each developer has his/her own pace, a man-days estimations will only be relevant to the person that made it which is might not be the developer who will implement it.
Although in theory, the items from Product Backlog are consumed in the order of their priority, and team decides during the Sprint Planning Meeting what items can be implemented in the next sprint, sometimes items with lower priority from the list, but related to the high priority ones are included in the sprint, in order to completely develop a specific user story.
Technically, a Product Backlog can be managed using a whiteboard with cards on it, an Excel file, or one of the many applications and plugins specially developed to manage Scrum practices. It does not matter how it is done as long as it is used correctly.
While the whiteboard approach has a more visual impact and the developers can always see the backlog in front of their eyes, without opening an application, the more technical implementations are easier to maintain and you get additional features like reminders, more compact views, statistics, etc.
Independent of the way it is implemented, it requires a collaborative effort to maintain it. Even though only Product Owner is responsible for performing changes on it, the whole team is involved: sprint planning meetings, other discussions, the estimations all contribute to clarify the requirements and creates a buy-in from the team.
It makes no sense to invest time and effort to detail the specification of all items, since some of them will for sure change until the actual implementation begins(just before it will be in Spring Backlog).
However, once the item moves to Sprint Backlog in theory should not be changed anymore; if the change cannot be avoided, then the item is brought back to Product Backlog.