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.
Differences between specifications and product backlog
Who is responsible for the product backlog?
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.
What are the characteristics of a product backlog?
The product backlog has some remarkable characteristics. Claude Aubry has provided the “proven” acronym to highlight them:
- Public: the whole organisation must have access to this product backlog, it is a question of visibility
- Reduced: the product backlog must be fairly short, generally between 40 and 60 items
- Ordered: 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: only one product backlog per product!
- Living: the POr may re-order the product backlog as he/she sees fit according to the emerging needs of the product
- Emergent: the backlog is never complete, it is dynamic, it changes constantly and it is always possible to add new items or features
How to create a backlog? What are the different stages?
Source : Eden tech labs
The product backlog is an important artifact 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 requirements
- Write the user stories
- Prioritise the product backlog
- Check the quality of the user stories
- Add acceptance criteria
Identify the requirements
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.
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?
To learn more about how to write a user story, read our article!
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”.
But what does EPIC mean?
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
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.
Check the quality of the user stories
Product Backlog Refinement, also known as, 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.
Add 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.
What tools can be used to manage a product backlog?
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 Projectboard.
Source: La Minute Agile, Scrum Life, Le Guide du Scrum Product Owner – Nutcache
Read more:
Roles and responsibilities in Scrum
The 5 rules for a flawless Agile stand-up meeting
Do you want to deepen these concepts and learn how to use the Scrum framework to its full potential? QRP International organizes Scrum Master and Product Owner courses. If you have any questions, write to us!
Skip to content
