What is a Product Backlog?
The Product Backlog is a collection of items that contain all the work that will at some time be done regarding the product that we are building. One product has one (and only one) Product Backlog. That means all the work is on that product backlog. The types of work are often new features, enabling work, technical work and fixes. In Agile / Scrum, the items on the Product Backlog are usually called “User Stories”. A User Story is a requirement described from the end user point of view. It’s also important to mention that the Product Backlog is managed by the Product Owner, and that he/she is the only person that is allowed to do updates on the Product Backlog. He/she is ofcourse able to deligate work to other people.
Items on the Product Backlog are ordered in whatever order the Product Owner decides. This will usually be decided by a combination of value to the product and effort to implement. The items on the top of the Product Backlog are usually more detailed and finegrained because they were already refined by the Scrum Team. The items towards the bottom of the Product Backlog are often bigger chunks of work which still lack a lot of detail, and will be investigated in the future.
During the Sprint Review, the Product Backlog will be updated as new feedback and insights arise. Since the Product Backlog is a living document, the Sprint Review is a good moment to make updates based on the new insights and feedback from the stakeholders.
During the Sprint Planning, the development team will pick up work items from the Product Backlog that need to be implemented to achieve the desired Sprint Goal. This is why each item on the Product Backlog clearly states it’s value and the effort needed to implement it. Without this information, it would not be possible to decide which items need to be planned in a sprint, and the team would not know how much work items it could pick up in one sprint. By the time an item from the Product Backlog is picked up in the sprint, it should have tasks that clearly define the work that needs to be done to implement the work item. Tasks are for example: update database, update UI, change user role, update API validation, perform functional test and so on…