Skip to content

Product Backlog and Refinement

The Product Backlog is a list of problems to solve or solutions to build. This section will cover the creation of a product backlog, how to evaluate a backlog and backlog item, and the concept of Definition of Ready and how to create Ready PBIs.

Outcomes

  • Learners will understand the Product Backlog
  • Learners will understand Backlog Refinement

Activities

  • DEEP Backlog
  • INVEST Criteria
  • Determine if PBIs are ready for a sprint
  • Travel Agency breakout
  • Homework-Estimation in the CAVU platform

Outline

Product Backlog

The Product Backlog serves as a collection of work to be done by the team, know as Product Backlog Items (PBIs), ordered generally by business value.

The Product Backlog should also be seen as a list of problems to be solved (Problem Backlog). The team should look to build solutions, rather than output.

While anyone can add items to the Product Backlog, the Product Owner is the final authority on ordering the Product Backlog (not the CEO, shareholders, nor the team).

Who can add things to your backlog?

  • Customers
  • Stakeholders
  • Team Members
  • Other Teams

Customers may add features to the backlog.

Stakeholders may add items to increase the profit.

Team Members may add items to pay down tech debt.

Tech Debt is the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

Example: As an example, purchasing a car using a loan (debt) is not bad. However, if you do not pay down the debt, you'll default on the loan and run into issues, like the bank repossessing your car. A little debt is fine, but a lot of debt is bad.

In the same way that you have to pay down personal debt, you have to pay down tech debt, and a good Product Owner will prioritize PBIs to pay down tech debt.

Other Teams my add items that are dependencies for their teams.

The best way to get PBIs on the Product Backlog is to have a conversation with the Product Owner.

Most Value, Least Effort-The Product Owner is going to prioritize PBIs that create the most value for the least effort.

Product Backlog - Product Backlog Items

Product Backlog Items (PBIs) should convey context needed for the team to deliver an outcome aligned with the value requested.

PBIs should contain the following information:

  • Value proposition-Why is this solution valuable?
  • Recipient of value-Who receives the value of the solution?
  • Action needed-What action is needed to be done?
  • Constraints-What are the constraints of the work to be done?
  • Test criteria-What are the test criteria of the work?

PBIs can be any size.

Product Backlog - Communicates Visually

The Product Backlog should start with really big ideas, but over time thos big ideas are broken down into smaller, strategic, tactical, and actionable goals.

Refinement-Large to Small: Refinement is the act of breaking the large ideas down and making them smaller--small enough to bring into a sprint.

Your backlog should be prioritized in a way that people can look and immediately understand what your organizational priorities are, letting people know what to expect in the future.

DEEP

  • Detailed Appropriately
  • Estimated
  • Emergent
  • Prioritized

The Product Backlog should be evaluated to see if it is DEEP.

If the Product Backlog is not DEEP, it needs to be refined.

INVEST in Product Backlog Items

Definition of Ready The Backlog Item (user story) meets the INVEST criteria:

  • Independent-The Backlog Item is not dependent on any other Backlog Items.
  • Negotiable-The Backlog Item can be clarified or re-negotiated during the sprint.
  • Valuable-The Backlog Item brings value to the stakeholders.
  • Estimated & Estimable-The Backlog Item is able to be estimated.
  • Small enough-The Backlog Item is small enough to fit into a sprint.
  • Testable-The Backlog Item can be tested.

Is this PBI Ready for a Sprint?

Use these slides to have the learners decide if PBIs are ready for a Sprint.

How do you know you've done it?

The Acceptance Criteria are the predefined requirements that must be met to mark a user story complete.

Using the Acceptance Criteria, decide if the PBI is done.

Identify the Good story

Identify the Good Story board
Send your learners to a breakout and have them review the Identify the Good Story board. Have them identify a good story, and a bad story. Recap by coaching your learners through identifying a good and bad story using INVEST.

Team Agility Scale - Refinement

Explain to yhour learners what an Agility Scale is and Have your learners view the scale for refinement. Ask them to identify something in underperforming that they would like to work on with their team, and have them write down something they are going to do with their team to work on that.

Notes from the Past