↓ Skip to main content
Romano Roth
What is a Product Backlog Item (PBI)?
  1. Blogs/

What is a Product Backlog Item (PBI)?

·4 mins
Agile Scrum Product Backlog Product Owner User Stories Backlog Management
Author
Romano Roth
I believe the next competitive edge isn’t AI itself, it’s the organisation around it. As Chief AI Officer at Zühlke, I work with C-level leaders to build enterprises that sense, decide, and adapt continuously. 20+ years turning this conviction into practice.
Table of Contents
Ask AI about this article

In my previous video, we explored what a backlog is. We learned that a backlog consists of Product Backlog Items, short PBI. In this video, we go one level deeper and look at what exactly a PBI is, how it evolves over time, and how it relates to the product backlog, the sprint backlog, and the product owner.

What is a Product Backlog Item?
#

A Product Backlog Item is a single element of work that exists on the product backlog. Such a PBI can take different forms: an epic, a feature, a user story, or a task. Each of these types serves a different purpose and operates at a different level of granularity. In my follow-up videos, I go through each one of these types in detail.

The Lifecycle of a PBI
#

Every Product Backlog Item follows a lifecycle. It starts when stakeholders, such as the business, clients, or the product owner, have new ideas. The new PBI is then created at the bottom of the backlog. After that, the product owner picks it up and orders it according to business value, risks, and other criteria. Together with the team, the PBI is refined step by step until it is ready for implementation. Once implemented, it becomes part of the incremental product.

“A Product Backlog Item starts as a simple two-word title and evolves over weeks and months through discussions, estimations, and acceptance criteria until it is ready for implementation.”

How the Product Owner Orders the Backlog
#

The product owner orders PBIs according to several criteria: business risk, technical risk, business value, customer satisfaction, time criticality, implementation strategy, dependencies, infrastructure work, and reduction of technical debt.

One thing I see far too often is product owners who only want features, features, features, and completely ignore technical debt, infrastructure work, and technical risks. This is a dangerous pattern. You should always maintain a healthy balance between technical work and business work. If you neglect the technical side, your product will eventually reach a state where you spend all your time bug fixing and can no longer deliver new features.

How a PBI Evolves Over Time
#

Let me give you a rough example of how a PBI evolves as it moves up in the product backlog:

  1. Entry: A simple two-word title
  2. Two months later: A discussion summarized in three sentences
  3. One week later: The team provides a first estimation
  4. Two weeks later: Three acceptance criteria are added
  5. Another week later: A user interface sketch is added
  6. Next day: The team re-estimates the PBI

Notice that at no point have I mentioned whether this PBI is an epic, a feature, a user story, or a task. That classification is something the team decides based on the estimations.

The Mental Model: Connecting PBIs to the Backlog
#

Here is a mental model that connects the different concepts:

  • An epic is realized by one or many features
  • A feature is realized by one or many user stories
  • A user story is implemented by one or many tasks
  • Epics, features, and user stories belong to the product backlog
  • The sprint backlog is a subset of the product backlog and contains the user stories to be implemented during a sprint
  • The product backlog is owned by the product owner
  • The sprint backlog is owned by the development team

“A bug is only a special user story. Features are fixed by fixing a bug, and the bug is fixed by implementing tasks.”

There is one PBI type I left out of this visualization to keep it simple: the bug. Bugs occur when a feature is not working as expected. A bug is essentially a special user story. Features are fixed by fixing bugs, and bugs are fixed by implementing tasks.

Key Takeaways
#

  1. A PBI is a single unit of work on the product backlog. It can be an epic, feature, user story, or task.

  2. PBIs evolve over time through refinement, moving from vague ideas to implementation-ready items.

  3. The product owner orders the backlog based on risk, business value, customer satisfaction, and other criteria.

  4. Balance technical and business work. Ignoring technical debt, infrastructure, and risks will slow down your product in the long run.

  5. The mental model is simple. Epics break into features, features into user stories, and user stories into tasks. Understanding these relationships makes backlog management straightforward.