This year I’ve run over 25 Scrum refinement meetings; here’s what I’ve learned.

This post will cover:

  • What is refinement, and why does it matter?
  • Two counterarguments, refuted!
  • My step-by-step approach
  • Notes on pointing bugs

Let’s dive in.

What is Refinement?

(Backlog) Refinement is a process of improving tickets so they are understood by the whole team and ready for work.

Refinement turns chaff like this:

“Design for error on download screen”

Into wheat like this:

Given my server isn’t configured for downloading assets And I’m viewing the “Download Assets” screen Then I see the download button disabled And I see “Configuration required” And I see “Please contact your support engineer”

This is done in a Refinement Meeting. And since meetings have to justify their existence, I think, let me dispatch two counterarguments right away.

Two Counterarguments

“Isn’t the ‘chaff’ version good enough?” Maybe. When you’re the founding engineer working alone, or working with a small group of people who are aligned, perhaps. Beyond that, it doesn’t scale.

“Can’t I run refinement by myself?” Running refinement helps the team by showing how you turn vague tickets into clear work. Everyone learns. Everyone buys in. Use the team and let them be part of the process.

On teams I’ve worked on, we do an hour of refinement on the last day of the sprint.

My Step-by-Step Process

Here’s the process:

  • Open the backlogs
  • Refine the tickets
  • Assign points

Let’s look at each.

Opening the Backlogs

Before the meeting, the process owner opens each backlog that the team maintains.

This reduces browser fumbling during the meeting. If the tickets can be prioritized, now’s a good time to do a quick pass.

Sometimes tickets that are already in a sprint or even— gasp— in progress are not refined. It happens. Refine them now, when changes are cheap.

Refining the Tickets

The goal of refinement itself is to produce small, quality tickets that every person on the team understands and could work on.

I’ve found it helpful to have someone read each ticket aloud; it slows things down. Open up each artifact, image, server log, and look at them together.

Then, clarify and simplify. No hand-waving. No unfamiliar jargon or acronyms. No side conversations. Clarify and simplify.

For bugs, we’re looking for a great bug report. For features, try Given/When/Then. For tasks or chores, a clear summary of the task and subtasks.

A management hack is to notice who’s being quiet. They’ll often be the newer people on the team. Engage them with questions:

  • “What do you think?”
  • “What’s not clear?”
  • Or my favorite: “What’s wrong with this ticket?” 🔥

Refinement is not problem-solving. As a programmer, the urge to “solve it” is going to be strong; resist! You will frequently fail, and that context-switching can be distracting. We’re not fighting the battle; we’re evaluating the plan.

Assigning Points

Pointing is a quick, collaborative discussion about complexity.

Note the word complexity, not time. We want “medium complexity” rather than “half a day.” That distinction matters because it helps reveal hidden complexity, which is the goal of this entire process.

On my teams, we chose points using a doubling system: 1, 2, 4, 8. Eight-point stories are too big and get broken up.

As for assigning the points, I prefer planning poker: we count to three and everyone shows their number. Outlier votes, such as someone who voted four when everyone else voted two, have the floor to explain their rationale. They usually have something interesting to say.

What About Pointing Bugs?

As I’ve written before, I don’t point bugs, only refine them. Why not?

First, estimating the complexity of a bug is hard. It’s like asking: “How complex is it to fix a cracked foundation in a house?” No one truly knows until you start digging.

Also, bug points contribute to bad metrics. We get velocity from points, and so pointing bugs makes them organizationally comparable to features. They aren’t, and are more like overhead, so we keep them out of the metric.

Summary

Over time, the backlog becomes a kind of boring thing that we’ve revisited a bunch, and tickets tend to get resolved quickly or even occasionally declined.

How do you do this process? I’d love to hear.