In this article, we will be covering the basics of Product Backlog, one of the Scrum Artifacts. We will provide a definition of the Product Backlog, we will take a look at its dynamic nature and its evolution from a high-level document to a detailed, ordered list of items to be worked on in the upcoming Sprint. We will also cover the basics of Product Backlog items. Finally, we will also answer some of the most commonly asked questions about the Product Backlog.
The Product Backlog is an ordered list of all the things that have to be done in order to deliver a product. Depending on the nature of the product and the industry, this will include all kind of different work, but it is crucial to point out that it will include both critical requirements, features and functions and non-critical work such as learning, experimentation, investigations into new practices and tools, etc. Scrum's Product Backlog is generally considered the most advanced agile project management backlog and teams that wish to have success with Scrum need to do everything in their power to maintain a clear and efficient one.
Product Backlog Items
The Product Backlog is expressed in the form of Product Backlog items which define the work to be done in more detail. According to the Scrum Guide, regardless of the kind of work they describe, all Product Backlog items have the following characteristics:
While the Scrum Guide makes no mention of them, most Scrum Teams express the majority of their Product Backlog items in form of User Stories which describe the work to be done in a way that shows how the end user will benefit from it.
The Product Backlog is not a static artifact that is set up at the start of the project and serves as a never-changing to-do list. It is a dynamic artifact that is constantly updated, modified and worked on so as to provide the most value for the Scrum Team and, indirectly, the stakeholders.
For example, the Product Backlog items that are ordered lower are described only roughly and they are usually not estimated or evaluated until they come closer to being part of a Sprint. This way, the team can better respond to changing requirements and circumstances, reducing potential waste. This also makes for more precise estimations and evaluations.
Even the ordering of the Product Backlog is not set in stone and it can (and should) change as new information becomes available.
Product Backlog items that will be worked on in the upcoming Sprint have to be refined so that they can be “Done” within a Sprint and they are then considered “Ready” for Sprint Planning.
The process of adding details to the Product Backlog items, estimating them and ordering them in response to changing circumstances is called Product Backlog refinement.
Scrum Teams can choose how to approach Product Backlog refinement so as to best fit their process. Most teams have a defined Product Backlog refinement process and meetings where they discuss the best way to do it. Some, usually very mature, Scrum Teams feel confident enough about their communication and collaboration skills to do it on the fly.
The Scrum Guide states that refinement usually takes up no more than 10% of the Development Team’s capacity.
Product Owner’s Responsibility
The Product Owner is solely responsible for the Product Backlog. Only the Product Owner can add items to the backlog or remove them. They also have the final word on the ordering of the Product Backlog.
While the Product Owner is the person responsible for the Product Backlog, its refinement should be a collaborative effort where the rest of the Scrum Team contributes with its knowledge, insights and experience on the project so far.
Besides helping the team deliver the product in the best way possible, the Product Backlog also plays a crucial role in monitoring the progress towards the goal. At any given point in time, the Product Backlog provides a clear picture of how much work remains to reach an agreed-upon goal.
For example, at the Sprint Review, the Product Owner can compare the work remaining with the amount of work remaining after the previous Sprint, thus getting an insight into how fast the work is progressing.
By using projective practices such as burn-downs, cumulative flows and burn-ups, the Product Owner can forecast the future progress of the work. Of course, this kind of predictive forecasting should be considered imperfect and should not be seen as the purpose of any agile project management backlog, Scrum or not.
Product Backlog FAQ
What is Product Backlog?
The Product Backlog is an ordered list of everything that has to be done in order to deliver a product. In simplest terms possible, it is an elaborate and dynamic to-do list for delivering a working product.
How to create a Product Backlog?
The Product Backlog usually starts off with only the most essential features and functionalities spelled out, possibly from a high-level roadmap of the product. As the team starts working on it, the Product Backlog evolves and is expanded with more details. The work that will be done in the upcoming Sprints is described in more detail than the work to be done later.
How should the Product Backlog be arranged?
The Product Backlog is ordered very carefully, keeping in mind a number of factors such as the priority of the features, the dependencies, exploration work and others. The Product Backlog is constantly rearranged as new information comes in - changing business requirements, marketplace conditions, or technology.
Under what circumstances should the Product Backlog be reprioritized?
The Product Backlog should be reprioritized constantly as the product evolves and new information is discovered. New business requirements, newly discovered dependencies and fluctuating market conditions are just some of the reasons for reprioritizing the Product Backlog.
What is Product Backlog grooming?
Product Backlog grooming is another term for Product Backlog refinement that has been going out of style somewhat lately. It denotes the process of adding new details and estimates to Product Backlog items as well as reordering them.
Can items be removed from the Product Backlog?
Yes, items can be removed from the Product Backlog. As the product starts taking form and evolves under the influence of various external and internal factors, removal of certain Product Backlog items is an indication that the Product Backlog is properly refined.
Who is primarily responsible for maintaining the Product Backlog?
Product Owner is the sole person responsible for maintaining the Product Backlog. That being said, it is a process that should involve the entire Scrum Team.
How much time should the Scrum Team allocate to maintain the Scrum Product Backlog?
The Scrum Guide does not prescribe how much time Product Backlog refinement should take. It does mention that it usually does not consume more than 10 percent of the team’s capacity.
What is a Product Backlog item?
A Product Backlog item is a described, evaluated, estimated and ordered unit of work that can be completed within a single Sprint. The Development Team pulls Product Backlog items from the Product Backlog into the Sprint Backlog and works on them during a Sprint.
Which role is responsible for turning the Product Backlog into incremental pieces of functionality?
The Development Team is responsible for turning the Product Backlog into incremental pieces of functionality. No one has the authority to tell the Development Team how to work on Product Backlog items and make them “Done”.
Who estimates the effort to complete a Product Backlog item?
The Development Team estimates the effort required to complete a Product Backlog item.
What determines how the team knows when a Product Backlog item is done?
The Scrum Team as a whole determines its Definition of Done against which “completed” Product Backlog items will be compared. If the Scrum Team is a part of an organization which has its own guidelines, conventions and standards that address the Definition of Done, the team should consider those the minimum when coming up with its own definition. The Definition of Done should also evolve as the team matures, adding new criteria to improve the quality of the product.
Which Scrum values are exhibited by not building Product Backlog items that have low business value?
The most obvious Scrum value exhibited by not building product backlog items that have low business value is focus. However, it also exhibits openness as this usually means that Product Backlog items are fully transparent and that everyone understands their value. Sometimes it also takes courage to not build low-value items that an external stakeholder might be partial towards.
Author: Goran Prijić is the co-creator and Product Owner at VivifyScrum. He is also a Certified Scrum Master.