Written by: Alexander Dvorzsák, PSM II., PSPO, PMI-DASSM
The Product Backlog is a prioritised, evolving list of what is needed to improve and perfect the product. It is the sole source of a Scrum team's work. Its role is to make the remaining improvements transparent to the people involved in the development. But what is a good Product Backlog? What are its elements? How to create one? We can help.
What is Product Backlog?
In simple terms, the Product Backlog can be thought of as a "What we wish our product could do" wish list, compiled by the Product Owner based on the needs of stakeholders and users. This list and the needs on the list are then detailed and prioritised by the Product Owner according to a number of criteria, and then presented to the team to jointly interpret the most valuable elements that the team will work on implementing in the next period.
More specifically, the Product Backlog is a tool, a product from the Scrum framework. Its contents can be recorded and tracked using a tool designed for this purpose, such as JIRA, but a simple excel spreadsheet can also be used to create a Product Backlog. Scrum defines the Product Backlog in general terms, leaving the concrete implementation to the user, describing only principles. More concrete criteria for a good use of Product Backlog are given by the DEEP model developed in agile practice.
Accordingly, a good Product Backlog
- Detailed - Appropriately detailed. For complex, uncertain developments, lower priority Product Backlog items are less likely to be detailed, as their content may change until we start developing them, so planning them may be unnecessary work for the team.
- Estimated - Product Backlog items include estimates. It is very difficult to schedule the delivery of Product Backlog items that cannot be estimated, so they don't get there very often.
- Emergent - Constantly evolving, changing. The content of the Product Backlog is never fixed, but changes as more and more feedback is received from the increments already on the market.
- Prioritized - Prioritised by business value. By business value, the most important items are placed at the top of the Product Backlog.
What is a Product Backlog item (PBi)?
Items in the Product Backlog list are called PBi (Product Backlog item). PBi's that can be implemented during a Sprint are considered to be processable in Sprint planning. This state is achieved by detailing the PBi's, increasing the common understanding of them in the Scrum team. This is an ongoing activity where we can add details to PBi's such as description, size and sequence. These details are dependent on the type of work, so there is no set type of PBi's to be used in development. The goal would be to have a Product Backlog that contains everything that is or may be needed to develop the product to the best of our current knowledge in a clear and transparent way.
What are the types of Product Backlog items?
There are many, there are many types: user needs, defects, non-functional requirements, quality requirements, studies, etc. there is no limitation, there are as many PBi as there are organisations.
There are PBi whose names are used in many places, and we will look at three of them. No original and precise definition can be given for these PBi types, as there is no dictionary or set of rules where they are collected, they are used in many different ways in the world. Here we describe their origins and common characteristics. It is worth looking critically at the PBi used in your work, always being aware of the context in which you are using PBi and how you are defining them (with those you are working with).
There are several approaches to understanding Epic. The most important of these are:
- Jira: Epic is a larger-scale task that we can break down into smaller-scale stories.
- SAFe: Epic is a product development initiative that is large enough to require analysis, Minimum Viable Product (MVP) definition and business approval before it is developed.
- Mike Cohn: If a User Story is too big, we call it Epic. That's the way we use it most of the time.
The use and criteria of the User Story have been influenced by many people throughout history. The first to use the term was Kent Beck during the Chrysler C3 project. Alistair Cockburn, Ron Jeffries and an XP team at Connextra also developed User Stories in the following years, and Bill Wake invented the INVEST criterion for describing a good User Story.
It is most often used in this written form: "I, as , do in order to "
A good User Story meets the INVEST criteria:
- Independent: I can deliver User Stories in any order.
- Negotiable (open): the content of the User Story can change until it is closed.
- Valuable: Contain value for users.
- Estimable: Have a reasonable, realistic estimate.
- Small: Can be done in a short time (fits in a Sprint)
- Testable: to be able to prove that the User Story works well.
Spike
Spike is a task that is designed to gather information or answer questions, not to produce something that can be delivered. A common case is that a Spike is a study on an unpredictable PBi, the output of which will be predictability.
Kent Beck, XP: "A very simple program that explores larger solutions."
Summary
There are many ways in which Product Backlog and PBi's are used in the world, the most important thing is that there is a purpose, meaning and value in using them. Jira is not the only way to implement Product Backlogs, it is not what platform you use, but how you use it and how you use it that matters, and to enable dialogue between different actors. In many cases, as already mentioned, a table with post-its or an excel sheet can be enough to make your Product Backlog transparent. For new teams, new developments, it is worth talking through what we mean by PB, PBi, how we use them and what purpose they serve.
f you also think it is important for you to be able to manage your team more successfully and to achieve your project goals effectively, choose from our current training courses for project managers!
Designabc