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
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
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
