The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.
Today we are going to talk about the one of these terms in the Scrum Glossary: Product Backlog. The glossary has the following description:
Product Backlog: an ordered list of the work to be done in order to create, maintain and sustain a product. Managed by the Product Owner.
Again, so many misconceptions about this particular artefact being used in practice at organisations. The Product Backlog enables transparency on what work is currently known to be required to still be done for the development of the product. It provides transparency on the consequences of emergence (see my previous article about this term) having taken place, and decisions that have been made after inspection of the Increment. The first part of the description already allows for quite a few misconceptions:
an ordered list
An ordered list means something really concrete. The Oxford dictionary has a number of definitions for the word “list” of which the first mentioned is the one meant in this description:
“A number of connected items or names written or printed consecutively, typically one below the other.”
The addition in the description of the Product Backlog mentioning it to be an ordered list makes it so there is relationship between the items in the list which makes for reasoning to the order.
So an ordered list means a set of things are put consecutively below one another because of some relationship. In Scrum this means the Product Backlog has no items that is next to another item as this breaks the convention of it being a list. Everything is set consecutively. There’s a consequence to doing that, which is that there is nothing equal regarding the order of items. Every item could, if someone wanted to do so, sequentially be numbered without doubling.
of the work to be done in order to create, maintain and sustain a product.
This part describes what the units of things are on the ordered list. Every item should describe work in relation to the product we are developing. The description splits this work out in three categories:
- Work to be done to create a product, which is any work relating to creating new things that aren’t part of the product yet
- Work to be done to maintain a product, which is periodic work relating to maintaining a working product over a longer period of time
- Work to be done to sustain a product, which is continuous work relating to keeping a product working and functional continuously
They all mention something particular amongst them. I want to zoom in on the bit that says “to be done”. This part says something about what work that falls into one of these three categories actually makes it on the Product Backlog. I might surprise you by saying it’s not everything. But what will end up on there then? Let’s look at the final part of the phrase to get an answer to this question.
Managed by the Product Owner.
Is your Product Owner the one calling the shots about the order and what’s in your Product Backlog right now? I’ve seen otherwise in a lot of organisations. The role itself will be further analysed in the article about the Product Owner, but let’s take a look at what’s actually being said here. What does manage mean in this context? Well, it’s more than just deciding the order and it does not mean having to fill in all the Product Backlog items by him- or herself.
Managing a Product Backlog means decisions need to be made about the order. To do so the Product Owner needs certain information on his or her Product Backlog and in the Product Backlog items. To do this stakeholder management needs to take place. This can be conversations with stakeholders, measurement at stakeholders, conversations between stakeholders, market analysis, anything needed to be able to take advantage of the emergence of knowledge and prominence of knowledge that is happening at the stakeholders because they are using the current Increment. The outcome of this stakeholder management can influence the contents and order of the Product Backlog.
A common misconception is that this is refinement, and that is done only by the Product Owner. This is entirely untrue. As the Product Owner is the one determining order and therefore also what is both on and not on the Product Backlog, the Development Team should be doing the refinement of Product Backlog items by talking to the stakeholders on the subject of what they want the product to do in enough detail to understand what they are expected to create. The result of both stakeholder management and refinement are reflected on the Product Backlog.
As one of the artefacts in Scrum the Product Backlog enables Transparency on an important variable to inspect and adapt on. In this case it’s about the forecasted next best steps to take, or next experiment to do to ensure the way the team does product development is still maximizing whatever we deem as value to be delivered. For example, I would want to see expected market share gains (relatively if needed) per item if that is also the most important thing also measured at the Sprint Review. The Product Owner can use this to decide if something is even worth doing, and if so, put it somewhere in the existent ordering.
I hope this article helped to understand what a Product Backlog actually is a bit better. Next up is Product Backlog Refinement. A subject close to the one in this article.