top of page

The Product Backlog Explained

Updated: Jan 11, 2021

The Product Backlog is one of the three artifacts of Scrum. The artifact is the responsibility of the Product Owner to maintain. The Product Backlog is the single source of truth for work that is needed to achieve the product goal. This includes items relating to new features, bug fixes and maintenance. To put it another way, the Product Backlog contains all the work necessary to create and achieve the product goal.

We begin the process recognizing that there will be a lot of discovery to achieve the product goal. This creates the mindset that we are going to observe and adapt. Therefore, the Product Backlog is a living artifact and evolves over time.

· Its initial creation lays out what is the best-understood set of requirements.

· Its content emerges and evolves as the product evolves.

· The Product Backlog is never complete, and it should be considered a dynamic document.

· As long as there is a product, there is a Product Backlog.

No one should tell the Development Team to work from another source. Instead, the Product Backlog items are listed in their preferred order (prioritized) and this order determines the next item that the Development Team should focus on.

As a member of the Scrum Team, the Product Owner is responsible for:

· Prioritizing the content of the Product Backlog.

· Making the Product Backlog available and visible.

· Ensuring that the items are understood by the rest of the team.

· Having enough Product backlog items ready for 2-4 sprints worth of work.

What it means for a Product Backlog item to be ready for development, depends on the needs of the product and the team. Therefore, it recommended that the team agrees on what is to be considered a state of ready for any PB items. We normally refer to this agreement as the Definition of Ready. At minimum, a Definition of Ready should contain:

· A short description of the Product Backlog Item.

· The item has been placed in the preferred order to receive it (prioritized).

· It contains a form sizing estimation as provided by the developers.

· Some form of value has been provided about the item.

· It is useful if the item also contains a test description to prove its completeness when it’s “done” (acceptance criteria).

Product Backlog refinement is not a Scrum event. Instead, it is an ongoing activity. The Product Backlog is refined as needed throughout the Sprint.

o Refinement is the continuous act of breaking down, adding detail, estimates, and order to the Product Backlog items.

o The higher the order of the PBI, the more refined it should be

o Items that are deemed necessary to achieve the product goal may be deleted by the Product Owner at any time.

o Developers may assist the Product Owner in the refinement process as needed.

o It is recommended that refinement should not take up more than 10% of the developer’s time to allow them to focus on the achieving the Sprint Goal.

o Although not required, it is helpful to schedule parts of the refinement process with the developers on cadence.



Thanks for submitting!

bottom of page