Improving your Backlog Refinement with Acceptance Criteria

Let’s treat Scrum Events like Product Backlog Items. A good PBI has a clear Outcome, Who it is for, and Acceptance Criteria. 

PRODUCT BACKLOG REFINEMENT

Note: Backlog Refinement is not one of the Scrum Events. It is “an ongoing activity to add details.” A common good practice is to hold regular meetings to conduct this activity. 

Outcome: We are aligned on the work needed to turn a product backlog item(s) into usable value

Who is it for?: The Product Owner and the Developers

Acceptance Criteria:

  • Are the Product Owner and the Developers aligned on what success looks like? 
  • Are the developers aligned on how they will approach the work? 
  • Are we focused on the Product Goal and Sprint Goals with our refinement?

It’s not an Event: Backlog Refinement is not one of the Scrum Events. The Scrum Guide mentions refinement as “an ongoing activity to add details.” While it is not a formal event, a common good practice is to hold regular meetings to conduct this activity. 

Outcome: Transparency starts with alignment. If you think we’re meeting in Seattle, and I think we’re meeting in San Francisco, we will be greatly disappointed. We can’t expect a Product Owner to write perfect backlog items, and there will be no need for conversation before the developers start building. Refinement meetings are a time to dig into the details and sort it all out before we’re elbow-deep into fixing the engine, only to find we don’t have the tools to finish the job.

Who is it for? The primary audience is the Product Owner and the Developers. The Product Owner owns the meeting, schedules it, and sets the agenda. The Developers decide who needs to be in a given meeting based on the skills needed to complete the PBIs being refined in that meeting.

Acceptance Criteria: Are the Product Owner and the Developers aligned on what success looks like? 

  • It is not enough to create something usable; it also must be valuable. The Product Owner is responsible for aligning the individual work to the overall purpose, Product Goal, and potential Sprint Goals. They also own the specific definition of what will make the PBI valuable to the customer or user. If the Developers complete, a PBI and the PO says, “That’s not what I wanted,” that is the PO’s fault, not the Developer’s.

Acceptance Criteria: Are the developers aligned on how they will approach the work?

  • The goal is to deliver a usable increment of value, not individual components. This almost always requires the cross-functional skills of more than one person to deliver. If we expect them to do this in the middle of the Sprint, that’s like asking a race car team to redesign the engine while the driver is racing around the track.

Acceptance Criteria: Are we focused on the Product Goal and Sprint Goals with our refinement?

  • We need to focus our refinement efforts to support the longer goals. If you have a loose collection of refined items with no theme, you could be producing work that ultimately does not contribute to the overall goals and ends up costing your organization instead of benefiting it.

Make your Backlog Refinement better by treating it like a Product Backlog Item.

This has been a 🦍 Gorilla Coach 🦍 Scrumdementals moment. Have a nice day.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top