Scrum Artifacts #1 Product Backlog

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.

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 ordered list of everything that is known to be needed in the product.

SINGLE SOURCE OF REQUIREMENTS

Why is the ordered list with all “ingredients” that you need for the products (Product Backlog) important part of the 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 the Scrum.

WHO SHOULD MANAGE THE PRODUCT BACKLOG?

There is one role in Scrum - Product Owner who is responsible for Product Backlog management. She or he should decide about the content, availability and order of the Product Backlog Items. Product Owner needs also 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 in Scrum more important 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:

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

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

• Epic - piece of work, functionality that can be done in months. This is a really high level idea.
• Feature - Epics are divided into features. Feature is still a big chunk of work that can be done in weeks.

Before I will jump in to describe others, I would like to mention that Epics and Features can be used to show the Sprint Roadmap and high level idea of the work to be done.

• User Story - Features are divided into smaller pieces - user stories which can be also called Product Backlog Items. User story should describe feature, functionality that can be done in days. It should include:

  • Information - who is the user of the functionality
  • Description of what the user would like to do
  • Explanation what is the purpose of the 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)
  • Priority
  • Size - estimated by the Development Team on the Sprint Planning
• Bug - work item created, when there is some issue recognized in functionality, code.
• Task - User stories can contain multiple tasks. Tasks are created by the Development Team and they include all actions required to complete the user story, to make it “Done”. Definition of “Done” is defined by the Development Team and used to recognize the status of the user story.

There can be much more items included in the Product Backlog. Above list is created based on my experiences.

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:

Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog can be updated by the Product Owner at any time and it doesn’t always require the Development Team attendance.

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:

Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. By “Ready” - they mean detailed enough for the Development Team 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: Epic, Feature, User Story, Task, Bug.
• Product Backlog refinement is done to update some details of the Product Backlog. It should not take more than 10% of the Development Team’s capacity.
• The highest ordered items in the Product Backlog should be more detailed to be “Ready” for the Development Team to start working on them.