What is a Backlog? Definition, Stages and Tools

Date: 18/04/2024| Category: Best Practices Glossary|

Product backlog: definition

The product backlog is defined by the scrum guide as “an ordered and emergent list of what is needed to improve the product“. Xavier Koma adds that it is an ordered list of all the features/items, regardless of their form or format. This can be a user story, a specification, a brief or a mock-up with a powerpoint. As long as the team agrees on the format, they can keep the same communication and understanding.

Product backlog vs Specification: main differences

Specifications vs backlog

Who is responsible for the product backlog? The Product Owner or the developers?

The Product Owner (PO) is responsible for the backlog and generally refines it together with the whole team. This will influence the user stories so that they are ready to be taken over by the developers. The development team may write the technical user stories, but it is always the Product Owner who prioritises all the items.

Product backlog: characteristics

The product backlog has some remarkable characteristics. Claude Aubry has provided the acronym “prouvé (French for “proven”) to highlight them:

  • Public (publique): the whole organisation must have access to this product backlog, it is a question of visibility
  • Reduced (réduit): the product backlog must be fairly short, generally between 40 and 60 items
  • Ordered (ordonné): the items are ordered by decreasing value, i.e. the item that represents the highest value, comes first. The PO can use various agile techniques to order the backlog (see below)
  • Unique (unique): only one product backlog per product!
  • Living (vivant): the PO may re-order the product backlog as they see fit according to the emerging needs of the product
  • Emergent (émergent): the backlog is never complete, it is dynamic, it changes constantly and it is always possible to add new items or features

Scrum product backlog: stages and how to

Scrum Process
Source : Eden tech labs

The product backlog is an important artefact of scrum and is the main working tool of the product owner. To effectively manage a backlog, here are the 5 most important steps:

  • Identify the vision of the project
  • How to write user stories
  • Grouping user stories in Scrum and SAFe: definition of EPIC
  • Prioritise the product backlog: techniques and how to
  • User stories: quality check
  • DoD: acceptance criteria

Identify the vision of the project

First of all, it is necessary to establish the vision of the project, in other words to clearly define the objective that the project must achieve and to list the different actors. It is important that this vision is accepted and understood by all. It must be a consensus since the team will have to join after the PO in order to carry out the project according to its objective.

How to write user stories

Then it’s time to write the user stories, keeping in mind the questions: what features will be created? In what order should they be delivered? For whom are they intended?
You can organise your product backlog by:

  • Themes
  • Features
  • User story
  • Subtask
  • Theme: logical grouping of a number of topics defined by the Product Owner. There is no absolute rule as long as the organisation is optimal. Themes are then broken down by feature.
  • Feature: grouping of user stories. Each feature will represent a large functional block, i.e. a large functionality on the product. These functionalities will be broken down into items, also called user stories.
  • User story: user stories – items – tasks or backlog items are different names that represent improvements, evolutions, fixes, functionalities, functions or bugs.
  • Subtask: the development team, in scrum for example, will break down all the items into technical subtasks during the sprint planning, or even into “bug subtasks”.

Grouping user stories in Scrum and SAFe: definition of EPIC

There are several definitions. The EPIC can be at the same level as the feature or the theme. The initial definition of the EPIC is a big story, a need, with little visibility. This famous EPIC will be broken down into several user stories. We then talk about the maturation of the EPIC to become a user story. In a SAFe environment, the EPIC is the first level, before the theme, and therefore the most macro.

There are several possible meanings of the term EPIC, but the most important thing is that the team determines its own definition, and that everyone is aligned.

Prioritise the product backlog: techniques and how to

When prioritising the product backlog, the PO often encounters a common problem: a vague and inconsistent prioritisation process. As a Product Owner, you receive daily feedback, new ideas and feature requests from many stakeholders and you can’t say yes to everyone. Your stakeholders may be confused as to why you chose to prioritise one item over another and may feel that they do not have enough influence on your prioritisation process. An important step in addressing these issues is to standardise the prioritisation process. There are various techniques for doing this:

  • MoSCoW
  • Value vs Effort
  • ICE
  • RICE
  • WSJF

These techniques create a repeatable, more transparent and less random approach to your prioritisation.

User stories: quality check

Product Backlog Refinement, also known as Backlog grooming, is a Scrum practice that has the role of refining the content of the product backlog. It is an ideal moment to check the quality of a user story with the whole team and to question them. Thanks to everyone’s input, the Product Owner can refine the user stories selected for the sprint. Before launching an iteration (cycle of 1 to 4 weeks), the Product Owner and the team must ensure that the user stories are achievable by one person and in one iteration.

DoD: acceptance criteria

In order to optimise the user stories, the team must define together, during the Backlog Refinement Meeting, the acceptance criteria for a user story. This will make it possible to check whether the user story can be considered as “done”.

As a reminder: the “Definition of Done (DoD)” is the quality of the product delivered. It is the list of criteria that allow us to decide that a feature is “finished”, and that it can be delivered at the end of a sprint. It is applicable to all backlog items.

The velocity of a team is based on the “finished” features. It is a contract between the team and the Product Owner (who represents the stakeholders and is the voice of the customer). It clearly defines the criteria to be met for a user story, iteration, or release to be finished and delivered.

A first version of the backlog must be defined before the first sprint in order to orchestrate developments, as the product backlog also serves as a planning tool. Depending on the team’s velocity (calculated in the story point), sprints are created and loaded with US estimated in the story point. As the sprints progress, the backlog is expanded with new EPICS corresponding to a new identified need, new US to complete a feature already developed, bugs or technical tasks to prevent the product’s technical debt.

Manage a product backlog: tools and softwares

The product backlog can be created on a simple Excel file, but certain tools facilitate the monitoring of user stories, such as JIRA, Trello or Project board.

Source: La Minute Agile, Scrum Life, Le Guide du Scrum Product Owner – Nutcache

Share this post, choose Your platform!

Newsletter

Subscribe to the QRP International neswletter and get all the news on trends, useful contents and invitations to our upcoming events.

QRP International will use the information you provide on this form to be in touch with you. We'd like to continue keeping you up-to-date with all our latest news and exclusive content that's designed to help you to be more effective in your role, and keep your professional skills current.

You can change your mind at any time by clicking the unsubscribe link in the footer of any email you receive from us, or by contacting us at marketing@qrpinternational.com. We will treat your information with respect. For more information about our privacy practices please visit our website. By clicking below, you agree that we may process your information in accordance with these terms.

We use Mailchimp as our marketing platform. By clicking below to subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp's privacy practices here.