The Product Owner's Role in Product Backlog Refinement

Product backlog refinement is valuable for achieving productive Sprints. According to the Scrum guide, it is not a new event, but a recurring activity to be conducted with the development team.

Since the framework is not very prescriptive, it falls to the empiricism of each Scrum team to define the frequency and manner of conducting the activity. This openness in Scrum is precisely what generates so much debate about what to do with it — something the article Mindset or Framework: What Comes First? addresses directly.

So we need to move beyond theoretical models and observe its practical application to get these answers. In the real world, refinement has been used to prepare the team for planning for upcoming sprints.

Inputs (and Timing)

Ideally, backlog refinement should occur a few times per week and should take no more than a few minutes of the team’s time. It should have sufficient cadence to allow the team to reflect, study, and propose solutions to technical difficulties they will face in upcoming sprints.

As inputs, the product owner should bring the product backlog represented through wireframes, prototypes, drawings, decision flows, user journeys, personas, and acceptance criteria. Always with a preview of the next 2-3 Sprints.

The Activity

The product owner begins presenting the artifacts that will serve as the basis for product development. The Scrum Master should encourage the team to make the following reflections:

· How complex it is; how much risk it carries; how much uncertainty it contains; what are the satisfaction conditions; and if a certain event occurs, what happens to the application — (meaning: digging into acceptance criteria in detail);

Outputs

As outputs, based on what was presented by the PO, the Scrum Team will produce the requirements needed for product development in the Sprints (Sprint Backlog). This includes, but is not limited to: user stories, BDDs, acceptance criteria, decision flows. With the PO’s help, new situations will be identified and new acceptance criteria for user stories will be produced.

In summary, while the PO takes care of product conception in the world of ideas, the Scrum Team works to materialize those expectations.

Refinement also serves as preparation for planning events such as release planning. Therefore, the PO should bring a prioritization idea for the backlog and work with the Scrum Team to estimate size and plan fits within Sprints. At this point, simpler estimation strategies can be used, such as: S/M/L.

Here a delicate point:

When the Scrum Team does the backlog ordering, it already carries a perception about the progress of the current sprint. So upcoming sprints can be “more or less loaded” according to this “feeling.”

Separate discussions aside, the current sprint goal is NON-NEGOTIABLE and all agreed work must be delivered to the review.

THIS IS SCRUM!!!

… if a Scrum team — on a recurring basis — is not managing to deliver the sprint goals, we have another problem that could fill an article of its own. In many cases, the problem begins with lack of clarity about roles — Agile Coach and Scrum Master are frequently confused, and this confusion directly impacts the quality of refinement.

Participants

Here, the Scrum core team (Ken Schwaber, Mike Cohn) position themselves as follows: refinement cannot consume more than 10% of the team’s time. As for participants, they recommend that 50% of the Scrum team participate in this activity.

There are suspicions that this activity increases muri, so care must be taken not to involve the entire team for too long. Ideally, again, refinement should be done in just a few minutes per day.

Finally, specialists with very specific skills can occasionally be invited to clarify topics that need to be addressed.