The Product Backlog (PB) is an ordered list which contains all things needed to be done in order to make product successful. The Product Backlog is the one and only source of the requirements for the product created by the Scrum Team. And there is only one person accountable for the Product Backlog. It’s Product Owner.
Very important fact about the Product Backlog is that it is a living organism. The Product Backlog is never completed. The Product Owner, or anybody at the Product Owner’s discretion, constantly adds or removes items form that list. New one are added to the PB when: new requirements appear, some requirements have changed or a bug has been found. From time to time some items are removed from the PB because they have become obsolete. However, in my honest opinion, two the most frequent action perform on the Product Backlog are: shifting and splitting.
The Product Owner must make sure that the most important items (with highest priority or value) are on the top of it. To make sure that Development Team is able to take most top items into the Sprint, those items need to be well defined as well. Less important items should be lower in the PB. Those items might not be defined in much details – it can be only a name or idea for a new functionality. All dependent items should be lower than one they depend on. But what is more important as the product evolves the requirements evolves with it. Each release gives an opportunity to get a feedback from the end users which might have impact on the requirements. Even market itself have an impact on the product (new competitors or functionality added by existing one). All those circumstances have to be taken by the Product Owner into consideration. Those circumstances may force PO to change the order, to shift some Backlog Items all around. And from my experience it happens more often than expected.
The Product Backlog Items has live on its own. Very often Product Owner creates a new item with just a name of it – as a reminder of some idea he or she had. When the time passes more and more detailed are defined. It might happen that after some time the item is too big to be taken by the Development Team into a Sprint. The Product Owner can decide to test the idea by introducing only part of defined functionality into the product. Some dependencies might be identified which allows to introduce only part of the functionality. In such cases the Product Backlog Items can be splitted into to two or more independent (or depended) items.
As the Development Team is working on the Sprint the Product Owner must work on the Product Backlog – ultimately it is ongoing process. He or she must make sure that there is always enough work for the Development Team. In my opinion a perfect practice is to have as much Backlog Items ready to fill up 2-3 upcoming Sprints. A good practice (well enough) is to have next upcoming Sprint ready.
The thing very often forgotten about the Product Backlog is that it is a list of all things that need to be done. Most of the Backlog Items are related to the End Users’ requirements as they are the most significant Stakeholders – usually income comes from them. However, they are not the only one. The Sponsors of this product are also very important Stakeholder. But the Development Team also is one of the Stakeholders and the Product Backlog must reflect the requirements of the all Stakeholders. Therefore, needs of the Development Team should be accounted in the Product Backlog and the Product Owner is there to decide which are more important.
In case where more than one Scrum Team is working on the same product all of them should use one Product Backlog. And by the extends all of those team should have the same Product Owner (product owner is a single person accountable for the Product Backlog).