Backlog Refinement

A product backlog is a list of everything a team might build, kept in priority order. Left alone, it does not stay readable. Items get added mid-meeting, during a support call, or right after a bug report, one line at a time. Whoever writes the line already knows the context, so they write a title and move on. Two months later, the person who opens that line doesn't have the context.

All of that debt comes due in sprint planning. In a one-hour meeting meant to decide what the team does next, someone opens a line that says "improve checkout" and the first question is who asked for it. Finding the requester, agreeing on what "done" means, and guessing how big the work is — doing all of that on the spot pushes the meeting past two hours, and it usually ends with "let's look at this again next time."

While that repeats, the list keeps growing. After six months it holds 300 items, half of which were already solved another way or no longer match where the product is going. At that size nobody reads from the top any more. People show up to planning with whichever items they happen to remember, which means the list has stopped doing the one job it had.

Backlog refinement pulls both problems out of the planning meeting. Tidying the list gets its own session a few days earlier, so planning only has to pick from items that are already readable.

The hour splits into six steps, in order, because each step consumes the output of the one before it. Sizing needs a completion condition; ordering needs a size.

1. Cut the scope. Look at the top twenty or thirty items only. Anything below that will be re-ordered within a month, so refining it now just means refining it again.
2. Read each item and fill in the background. One line like "three customers raised this in last month's renewal calls" covers who asked and why.
3. Add the completion condition, usually written as acceptance criteria. It has to be a sentence that settles the question in one pass — "a customer who saved a card does not retype the number at the next payment." An empty box here shakes both remaining steps.
4. Split the big items. An epic runs for weeks and won't fit in a single cycle, so it gets broken into user stories — one-sentence requests written from the user's side. Items that need a longer explanation get a separate product requirements document (PRD), and the backlog keeps only a link to it.
5. Size the items using story points, a relative unit rather than hours. The team fixes one reference item at 3 and scores the rest against it with values like 1, 2, 3, 5, 8. Anything above 8 goes back to step 4.
6. Re-order, then delete. Items registered more than six months ago that nobody has mentioned since are the candidates. Keeping them out of sentiment only piles them up at the bottom.

If the hour runs out, cut from the top down and push the rest to the next session.

One person who owns the final order plus two or three people who build the thing. Five attendees is the ceiling.

1. The person who sets the order. On a scrum team that's the product owner; elsewhere it's the product manager. If that seat is empty, nothing decided in the session sticks.
2. One or two engineers. They hold the evidence for sizing, so step 5 depends on them.
3. One designer, on sessions where an item involves a new screen. Sessions without one skip the invite.

The whole team doesn't attend because the cost multiplies. Ten people in a one-hour meeting spends ten hours, and eight of them are listening until their item comes up. The decisions go straight into the list instead and get posted to the team channel.

Timing is once every week or two, around an hour, placed in the middle of the cycle. Attach it to the day before planning and refinement and planning merge back into one two-hour meeting. In the middle of the cycle, a question like "this one needs legal sign-off" still has a few days to get an answer. On a two-week cycle, that's around the Tuesday of the second week.

"Let's only cover the top fifteen this time. Everything below that gets re-ordered next month anyway."

A proposal to cut the scope up front so the session fits in an hour.

"This one has no completion condition, so I can't size it. I'll fill it in before the next session."

Estimating now would produce an arbitrary number, so it waits one round.

"Nobody has touched this in six months. Should we delete it?"

A proposal to shorten the list until it can be read from the top again.

At Pagedeck, Mia books an hour every other Wednesday at 4pm. Theo and Noa join, and Mia opens items from the top one at a time. Empty backgrounds get filled in on the spot, and when Theo says an item carries a data migration that won't fit in one cycle, it gets split in two. Noa flags the items that need a new screen.

The last ten minutes are for deleting. Mia reads out the items that have sat untouched for over six months, and anything nobody defends comes off the list. Twelve went last time. By the end of the session, the top twenty items can be picked in the next planning meeting without explanation.

The most common assumption is that the person who owns the order can just do this alone beforehand. Writing items and setting priority is their job, so pulling three people into an hour-long meeting looks wasteful. But the evidence for sizing sits with the people who build. Whether something is one more screen or a change to the data structure is knowable only to someone who reads the code. A number set alone is a guess, and a plan built on that guess collapses the moment someone says "that's not the size of it" — which sends the refinement back into the planning meeting anyway, an hour saved and two hours spent.

The other frequent mistake is thinking the whole list has to be covered. The word refinement sounds like it applies to everything. Reviewing 300 items in an hour leaves 12 seconds each, which is enough to read titles and nothing more. The part worth touching is the top section that will actually start in the next cycle or two.