We started this series on the Scrum methodology with an introduction (LINK), followed by two pieces on two of the most important roles in the Scrum framework (the Scrum Master and the Product Owner, LINKS), and an article on the framework itself and why it's called a framework for Agile working (LINK). After that, we focused on the ceremonies or events around which a Scrum-based project tends to revolve.
When it comes to Scrum, a project consists of Sprints and Sprints are built up of events. The role which each of these events plays and the way in which they take place can differ considerably based on factors like the the product that is being developed, the experience of the people involved in the project, and the preferences of the team members themselves. In general though, in a traditional Scrum project, a Sprint contains at least four major events, namely Scrum planning (also known as Sprint planning, LINK), the Daily Scrum (LINK), the Sprint Review (LINK), and the Sprint Retrospective (LINK).
Besides the roles and the events that are relevant to Scrum-based projects, the so-called artefacts also represent a key element of the Scrum framework. Usually, there are three artefacts that present in every Scrum team, namely a Product Backlog, a Sprint Backlog, and a type of backlog that defines a “finished” part for you. An artefact in a Scrum environment is a type of tool that teams can use to solve complex problems together.
Especially for those people who have little or no experience with Scrum projects we will briefly explain what artefacts in a Scrum environment are and what their purpose is. You have probably heard of artefacts in a historic or archaeological context before, where the term refers to any object that was made by a human being. So, in that sense, an artefact is a tool or a work of art that was made by a human and that is actually exactly what a Scrum artefact is as well. Scrum teams create artefacts themselves as well, as tools to help them achieve the set Sprint goals in the most transparent and efficient manner possible. In this article we want to take a look at what the Product Backlog exactly is and why it is so important to the success of a Scrum team.
What is the Product Backlog?
To put it very simply, the Product Backlog is a kind of ultimate to-do list for Scrum teams, and as well-known statement in the world of Scrum goes: a healthy Product Backlog is much like a healthy person: organised, groomed, and living in the open. The Product Backlog provides the foundation for much of the processes that are essential to running a successful Scrum-based project, which is why it's so important for this element to be clear and unambiguous.
Basically, the Product Backlog is a list of all of the tasks the development team needs to work on in order for the team to be able to deliver a finished product according to the previously agreed upon specifications. It is the single authoritative source for things the team needs to work on. What's important to understand here is that, while not every item that is on the Product Backlog will necessarily be delivered, it is absolutely not possible for the team to work on items that are not on the list. Therefore, more than a list of tasks, the Product Backlog can also be called a list of options for the development team.
A bit later on, we will take a look at who is responsible for the management of the Product Backlog and what that generally means, but we feel it's useful to first go over the possible items that can appear on the Product Backlog.
Features are the primary item on the Product Backlog and are more often than expressed as so-called user stories. These are simple, short descriptions of the features on the list, described from the point of view of the final user of the product.
Bugs, or better said bug fixes, also appear on the Product Backlog, because they don't differ that much from new features when studying them as a Scrum developer. In the end, both features and bug fixes refer to something new that the final user of the product wants or needs.
Technical work in this sense refers to anything the development needs to work as efficiently as possible. Seeing as maximum production efficiency is a main priority at all times, these items are also placed on the Product Backlog. An example of technical work would be upgrading the software with which the development is working on the product.
Who is primarily responsible for the Product Backlog?
In Scrum-based projects, it is the Product Owner who builds and maintains the Product Backlog, who facilitates the understanding of the backlog for everyone on the team, and who provides guidance on and during Sprints. He or she is in charge of the Product Backlog, and the Scrum Master supports him or her in this task. Much of the project information for the development team comes from the state and updates of the Product Backlog, so for an efficient workflow, it's essential that this list is maintained meticulously. Only by making the management and interaction with the Product Backlog as efficient as possible can a Scrum team work towards the maximisation of value.
This means that, even though the Product Owner tends to have less direct contact with the development team than the Scrum Master, the Product Backlog is a main way in which he or she communicates with the team. It's essential for the success of a project that all items in the log are expressed clearly, that everything is ordered and ranked in a way that makes sense for everyone involved in the project, that all tasks and responsibilities are obvious to each team member, and that the Product Backlog does not become an obstacle for any team member trying to reach his or her goal for the ongoing sprint.
At Sprint planning meetings, which take place before the start of each new Sprint, the first thing that usually happens is the Product Owner showing and explaining the updated Product Backlog to the rest of the team. The team then decides, based on the knowledge of their own capacity, which items should be included in the next Sprint. After this is done, the selected items are moved from the Product Backlog to the Sprint Backlog. This clearly shows how the Product Backlog quite literally represents the foundation of a Scrum project.
What does Product Backlog management generally include?
We have spoken about what the Product Backlog is and who is responsible for managing it, but we can imagine if the actual management part still sounds a bit abstract. That's why we figured it would be useful to dissect this task a bit to find out in more detail what the management of the Product Backlog entails for the Product Owner.
As we wrote earlier, it's of the utmost importance that the Product Backlog remains neatly prioritised and easy to understand for everyone involved in the project, especially the members of the development who need to work based on this backlog. Before every new Sprint, the Product Owner, often in close collaboration with the Scrum Master, needs to groom the list to make sure that it contains only relevant items and no clutter.
Some of the principal tasks during this grooming process are reviewing the priorities attached to each item on the Product Backlog and re-arranging them if needed. In general, the items with the highest priority are placed at the top of the list, waiting to be included in the next Sprint. In this phase, the development team determines which tasks can be included.
The user stories are another important element of the Product Backlog. These user stories are descriptions of the features in the backlog and they can be adapted according to changing conditions, such as market fluctuations or changing needs of the end customer, just to name a few examples. One part of Product Backlog management is to delete the stories that are no longer relevant and creating new ones if necessary. User stories also need to be ranked according to priority by the Product Owner.
The final important task we would like to mention in regard to Product Backlog management is the definition and re-definition of the project's and the product's acceptance criteria. These are the criteria that define when a certain increment or product is ready for delivery. Seeing as these can vary considerably per Sprint and per increment, it's essential for the Product Owner to make sure that they are understandable, attainable, and in line with the expectations of the final customer. Failing to define these criteria correctly can lead to Scrum teams delivering sub-par increments and products, which completely undermines the very purpose and added value of the Scrum framework.