Scrum Artifacts #1 Product Backlog

August 16, 2020 • 7 min to read

The first post in the Scrum Artifacts series that will help you to understand better Product Backlog and its role in the Scrum.

Table of Contents

Introduction

There are multiple reasons why I created this blog. One of them is to help you to get the most important information about the Scrum. Of course, you can do it by reading Scrum Guide, but you will not find there real-life examples.

In my last two series I described all Scrum events and Scrum roles. It’s time to explain Scrum artifacts. I’ve already mentioned them in my previous posts, but I would like to tell you more about them.

Let’s start from the king of the Scrum artifacts - Product Backlog. FYI - this post has been updated as per Scrum Guide2020.

What is the Product Backlog?

Product Backlog is really the king, because none of these Scrum-related actions couldn’t happen without it. Imagine that you are baking a cake. You can do it without the recipe, but at least you need to know what ingredients are required for the cake. The Product Backlog is for the product, like a list of ingredients for a cake.

Based on the Scrum Guide:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Single source of requirements

Why Product Backlog - the ordered list with all “ingredients” is such an important part of Scrum?

First of all, it is one source of truth that will tell you what is required for a product. Have you ever experienced a situation when multiple people ask you for the same thing, but all of them have different requirements? Product Backlog as a list of items helps to gather all the requirements in one place and order them. It minimizes mistakes caused by conflicting requirements or lack of visibility of changes.

What is more, having a well-managed Product Backlog, supports transparency - one of three pillars of empiricism which is the foundation of theScrum.

Who should manage the Product Backlog

There is one role in Scrum responsible for Product Backlog management - Product Owner. She or he should decide about the content, availability and order of the Product Backlog Items. Product Owner needs to make sure that Product Backlog is visible and clear for everyone in the Scrum Team.

Fixed requirements vs Product Backlog

In traditional project management all requirements are listed in the scope of work at the beginning of the project and they remain fixed.

Agile approach promotes different ways of working with the client and their needs. Initial requirements are listed in the Product Backlog, but the list evolves as the product and market situation evolves. It means that Product Backlog is a living artifact that is never complete.

Responding to change is more important in Scrum than following the plan. Why? Because everything related to the product can change: users, market situation, company strategy, even worldwide health issues like COVID19 can totally change the usability of the product. That’s why Product Backlog is dynamic and it exists as long as the product exists.

Product Backlog - what does it contain?

We have this magic list - Product Backlog, but what can we find inside? The answer is: everything related to the product.

Based on the [Scrum Guide] 2017](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf):

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

It is not included in the latest version of the guide. It helps to avoid narrowing down interpretation of Product Backlog.

There are multiple ways of expressing the Product Backlog. I will share with you the way I experienced it. In the list that one of my Scrum Team was using, below items were included:

• Epic - piece of functionality which can be done within multiple Sprints. It is the high level idea of the elements of a product.

Before I will jump in to describe others, I would like to mention that Epics (sometimes also features which I didn’t mention here) can be used to create “Sprint Roadmap” to have the high-level idea of the development of the product.

• User Story - it is the Product Backlog item which describes the specific need of the user. It should be large/small enough to be able to do it within one Sprint. It should contain:

  • Information about the user - who they are
  • Description of what the user would like to do, what are their needs
  • Explanation what is the purpose of their action Example of the above: As a (user), I want to (what user would like to do), so that I can (the purpose of the action).
  • Acceptance Criteria : everything that is required from the functionality from the user’s perspective.E.g. Given (context), When (action), Then (outcome). This is just an example. The most important is that criteria should explain what is specifically required in the story.
  • Size - estimated by the Developers on the Sprint Planning.
• Bug - work item created, when there is some issue recognized in functionality.
• Task - There is possibility that there are some technical actions required for the product that do not fit into stories. There are teams who use tasks this way.
• Sub-task - User stories can contain multiple smaller sub-tasks which need to be actioned , so that the story is “Done”. That’s the “How” created by Developers. They decide about everything that is required to make the story “Done”. Definition of "Done" is defined and used by them to recognize the status of the user story.

Above I gave you examples how you can describe the Product Backlog. But there are multiple ways to do it. Below I also added a few other Product Backlog items used by some teams. Remember that your Product Owner & the whole Scrum Team decide what the Product backlog will look like. The most important thing is that it will help in delivering the value.

Product Backlog Refinement

Once there are any changes required to the Product Backlog, the Product Owner and Development Team meet to refine it. What does it mean? They can update some details, estimates or priority. They analyze user stories, collaborate and make all required changes.

As per Scrum Guide 2017:

Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

I0% is not mentioned in the latest version of the Scrum Guide. There is only information about treating refinement as an ongoing activity.

Product Backlog order

The items at the top of the Product Backlog should be the most detailed. The lower item is in order, the less detail is required. It means that Product Backlog doesn’t need to be fully specified, detailed to start the first Sprint. The only things that matter at that stage are the highest ordered items.

As per Scrum Guide 2020:

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

By "Ready" - they mean detailed enough for the Developers to work on them.

Summary

The most important information that you should remember from this post about Product Backlog:

• It is the ordered list that is the single source of everything that is needed for the product.
• It is the living artifact that is updated wherever changes occur and it exists as long as the product exists.
• Product Owner is responsible for managing the Product Backlog: content, order, priority etc.
• Product Backlog is not fixed - it is never complete.
• Product Backlog can contain for example: Epic, User Story, Task, Bug.
• Product Backlog refinement is done to update some details of the Product Backlog.
• The highest ordered items in the Product Backlog should be more detailed to be "Ready" for the Developers to start working on them.