Product Backlog Refinement: the valve cap and 5 anti-patterns

Product Backlog Refinement is a continuous activity for the Scrum Team, not a separate event on the agenda. But it's the activity that makes the difference between a team that consistently stalls halfway and a team that predictably delivers sprint after sprint. This article isn't about the theory from the Scrum Guide. It's about what we've seen work in fifteen years of coaching, with the valve cap as compass for INVEST and five anti-patterns you'll likely recognize.

TL;DR. Refinement is the act of breaking down requirements into manageable pieces that the development team can both pick up and deliver. Goal: smaller variance on deliverables through better planning, clearer expectations, and earlier visibility on risks. Nominally up to 10% of team capacity; in practice often 2 x 2 hours per two-week sprint. The PO leads, the whole team contributes, and the Scrum Master steps in when the timebox is exceeded.

What is Product Backlog Refinement?

Product Backlog Refinement is the continuous process in which the Scrum Team refines items in the Product Backlog: splitting into smaller pieces, reformulating with sharper acceptance criteria, estimating, and reprioritizing. Not a separate Scrum event, but an ongoing activity. In practice, teams usually schedule two moments per sprint for it.

The older term "backlog grooming" is increasingly being dropped. The current Scrum Guide uses "refinement", which is shorter and avoids the uncomfortable connotations "grooming" has picked up since the 2010s.

Who does what: the Product Owner is responsible for the content of the backlog and leads the conversation about what should be built. The whole team (Developers + Scrum Master) contributes to how items can be split, estimated, and what risks are at play. The Scrum Master guards the process and steps in when the timebox is exceeded or one person becomes too dominant.

When items are "ready": a refinement session ideally ends with items that meet the team's Definition of Ready. That means: clear enough to estimate, small enough to finish in one sprint, and with agreements on how you'll know it's done. See the INVEST criteria section below.

What refinement actually delivers

Many teams see refinement as 'making time for the PO'. That's a very narrow view. Good refinement creates value for the team across three dimensions:

1. Better work planning

The better the refinement, the smaller the variance on deliverables. Items are clear, broken down into pieces that fit in a sprint, and estimated with an understanding of the complexity. Sprint planning goes faster because the thinking has already been done. The team can commit with more confidence to what they'll deliver next sprint.

2. Clearer expectations

By having the conversation during refinement, the PO (and through them, the customer) gets much more detail about what's actually possible. Not just "can this be done?", but also "what does this cost relative to something else, and what are the dependencies?" Stakeholders who join later in the process get consistent information because the team has built up shared understanding together.

3. Risk management

Refinement is where dependencies, technical debt, and ambiguities come on the table early. An item that initially looked "small" turns out to touch three external systems when probed. You'd rather discover that during refinement than mid-sprint after you've already committed. Making risks visible isn't slowdown - it's preventing much greater slowdown later.

As a team matures in refinement, predictability increases. That's the real return on investment: not a velocity number going up, but a team that delivers what it promises, sprint after sprint.

What you do during refinement

Concretely, there are five activities that can take place in a refinement session. Not all for every item, and not in a fixed order:

1. Split items. Break overly large stories into smaller ones that fit in a single sprint. Often the most important work.
2. Reformulate items. Sharpen acceptance criteria. Answer questions like "what does 'done' actually mean here?" and "who is this valuable for?"
3. Estimate items. Story points, T-shirt sizing, or another relative scale. The whole team estimates, not just the seniors.
4. Prioritize items. The PO orders by value, with input from the team about technical sequencing and dependencies.
5. Identify risks and dependencies. Which items touch other teams, external systems, or unavailable expertise?

INVEST: the valve cap and the two pitfalls

The most-used checklist for good backlog items is INVEST, coined by Bill Wake. An item is INVEST-compliant if it is: Independent, Negotiable, Valuable, Estimable, Small, and Testable.

Explaining INVEST in a training works best with an example everyone can immediately visualize. We use the automobile valve cap.

The valve cap as compass

Imagine: a team is given the assignment "build a car". That's a huge epic, no way that fits in a sprint. Breaking down a whole car starts with large chunks: engine, body, wheels. The wheel alone, with all its components, still isn't realizable in one sprint. But the valve cap of the wheel, the little black cap covering the valve stem, that's something everyone can immediately picture. What does it look like? What does it do? What needs testing? A valve cap can be made in a day.

Run INVEST over it:

• I - Independent. The valve cap can be made and delivered separately from the rest. ✓
• N - Negotiable. The shape, the material (plastic or metal), the color, the thread: all still up for discussion. ✓
• V - Valuable. Modestly valuable on its own, but without a valve cap you lose air pressure, so functionally needed. ✓
• E - Estimable. The smaller an item, the better the estimate. A valve cap is well-estimable. ✓
• S - Small. Easily fits in a sprint - in fact, many valve caps fit in a sprint. ✓
• T - Testable. Clearly testable: does it fit the valve, does it keep air in, does it look as agreed? ✓

The valve cap satisfies all INVEST criteria. It's a tangible example of "small enough" to count as one good user story.

The Small pitfall: "it fits in a sprint"

Many trainees think "Small" means a user story has to fit inside a sprint. That's an underestimate. Our rule of thumb: multiple user stories should comfortably fit in a sprint. One user story isn't a sprint's worth of work; it's a self-contained piece within a sprint.

If your item is so big that you're thinking "this is my sprint", it's probably an epic that needs splitting. The valve cap isn't a sprint's worth of work; it's a day's work within a two-week sprint.

The Negotiable pitfall: the HOW in acceptance criteria

The Achilles' heel of many Product Owners is that they don't just specify WHAT, but quietly also dictate HOW. Often that happens through acceptance criteria so detailed that the team has no design choices left. "The valve cap must be black, made of polyacrylate, with M8 thread, and the seal must be a rubber O-ring at position 2.3mm."

What we tell POs: let go as much as possible. Acceptance criteria describe what's done (the outside: it keeps air in), not how it's built (the inside: M8 thread and O-ring). Negotiable is about giving the team room to make the best technical choices themselves. A PO who fixes all design choices in acceptance criteria effectively takes over the design work.

5 anti-patterns that make refinement fail

Like every Scrum event, there are patterns that recur with teams just starting on refinement, or with teams where it has gone stale. The five we see most often:

1. The PO talks 80% of the time, devs sit back

The PO is excited about a feature and tells the whole story. Devs listen, nod, don't ask questions. Refinement isn't a presentation, it's a conversation where the team thinks along. More than that: refinement is an excellent opportunity for the PO to hand off some of the work. The devs have the technical knowledge to see what's feasible, where dependencies are, and how to split.

What we tell POs: sit back as much as possible. Ask a question, wait for an answer. Let the team propose the split. If you're talking more than any individual dev, something's wrong.

2. Items get too little detail ("I'll pick that up")

A senior team member says during refinement "I'll pick that up" and the item moves on to the next. Four sprints later it turns out: only that senior knows what needed to happen, the details never came to the table, and the rest of the team can't pick it up.

What we recommend to teams: every item should have enough detail that another team member could also pick it up. "I'll pick that up" isn't an acceptable end to a refinement discussion - it's the signal to probe further.

3. Items not granular enough → sprint planning gets stuck

Items are estimated as "fairly large, M or L". At sprint planning those items turn out to still be too big - fewer fit than expected, or they don't fit at all. Result: planning runs 4 hours instead of 1, and the team commits to too much work they can't deliver in the sprint.

What we recommend to teams: if an item is still "L" or larger after refinement, split it further. If splitting is hard, the discussion is probably that the concept isn't clear enough yet. Stop estimating and reformulate.

4. Not all devs estimate

During Planning Poker, only the seniors actively vote. The juniors don't vote, or they vote with whatever the seniors say. The insight that estimates provide - where team members disagree, and why - is then lost.

What we recommend to teams: everyone estimates, including those who probably won't do the work themselves. If estimates differ significantly (one gives 2, another 8), that is the conversation. Maybe there's an unspoken assumption that should be brought to light.

5. The PO doesn't watch the timebox → asymmetric items

The first item gets 30 minutes of attention, the next five each get 2 minutes. The list looks "done" but most items are barely refined. Next sprint those items turn out not to be "ready".

What we recommend to teams: agree in advance on how much time per item, for instance 15-20 minutes per item in a one-hour session. If you go over, that's a signal: either the item is bigger than thought (park it, handle in next refinement), or there's a more fundamental conversation needed that doesn't fit in refinement. In both cases: call in the Scrum Master to help guard the time.

Story points, T-shirt sizing, and bias

Story points are a stumbling block for many teams. The biggest mistake: not understanding that story points indicate relative size, not absolute time. A story of 5 points isn't "5 hours" or "5 days" - it's "bigger than 3, roughly like 5". Story points are initially meant to give the team a sense of Relative Size across all user stories and epics, so the team can later, at sprint planning, make a better preliminary selection.

T-shirt sizing as an alternative

In the refinement phase itself we often use T-shirt sizing instead of story points: S(1), M(2), L(3). Or the classic Likert scale: XS, S, M, L, XL. That provides enough distinction to prioritize without the false precision of numbers. At sprint planning you can later translate to points for velocity tracking, if the team finds that useful.

Bias in beginning teams

With teams that are new to estimating, we often see bias from senior team members. The senior votes 3, and suddenly everyone votes 3. So: vote blind at first, like Planning Poker. Everyone puts their estimate down, and then reveal simultaneously. That removes the group pressure.

With genuinely new teams, it can help to bring in the Scrum Master as facilitator. Not to estimate, but to observe the dynamics and call out patterns - for instance, that the same junior keeps voting with the same senior.

Cadence: the 10% rule and our Thursday/Wednesday schedule

The Scrum norm is that the PO can use up to 10% of the team's capacity for refinement. At a 40-hour week that comes to 4 hours per team member per week. In practice that's a lot. For a team of 6 devs that would be 24 hours of refinement per week.

We work with a different schedule in most teams: 2 hours in week 1 + 2 hours in week 2 (for a two-week sprint). That's 4 hours per team member per sprint, well within the norm. Which days?

Week 1: preferably Thursday afternoon

In the first week the team has just started the sprint. Monday and Tuesday are for getting started and gaining traction on the committed items. Refinement on Monday or Tuesday pulls the team out of that rhythm. Thursday is usually the best moment: the team is well into the sprint, has mental space, and can look ahead with attention without losing the current sprint.

Week 2: preferably Wednesday

In the second week the team is working toward the Sprint Review on Friday. Scheduling refinement on Thursday or Friday is pointless - the team is then focused on the review. Wednesday is a good compromise: not too close to the review, and late enough that the first week's refinement has been digested.

This schedule isn't a law. For teams with different rhythms it can be different. But the principle stands: schedule refinement at the moments it costs the team the least focus, and not as a daily interruption.

A refinement agenda that works

For those looking for a concrete agenda: this is what works well in our trainings for a one-hour refinement session:

Section	Time	What happens
Check-in + actions from last refinement	5 min	What happened since last refinement? Which items are now ready?
High-prio item 1	15 min	Split, sharpen acceptance criteria, estimate
High-prio item 2	15 min	Same
High-prio item 3	15 min	Same
Risks & dependencies	5 min	Which items touch other teams or external systems?
Top-of-backlog check	5 min	How many items are now 'ready' for upcoming sprints? What's still needed?

Total: 60 minutes. For 2 sessions per sprint (Thursday + Wednesday) you'll average about 4 well-refined items per sprint, plus time for risk discussions. For teams working with larger or more complex items you can extend the item blocks or reduce the number of items per session.

Refinement in remote and hybrid teams

Refinement in remote teams works differently from a retrospective, it's much more tool-driven. The substantive discussion sits largely in the backlog tool (Jira, Azure DevOps), not on a sticky board. But the social aspect remains important: a refinement where one person shares their screen and the rest types away delivers little.

• Everyone on camera. No listen-only mode. Refinement requires active thinking along; without faces you lose sight of that.
• Backlog tool shared on one screen. Jira or Azure DevOps on screen, the same view for everyone. Not each in their own browser, because then people look away.
• Planning Poker tool for estimating. Use a separate tool (PlanningPokerOnline, Scrum Poker, etc.) for blind voting. That prevents the bias that's even stronger in remote environments than in person.
• Keep the meeting short. An hour is enough for remote refinement; after that everyone loses sharpness. Better two sessions of one hour than one of two hours.

Frequently asked questions

What's the difference between refinement and grooming?

Same activity, different term. "Grooming" was the common term in the 2010s but is increasingly being dropped due to uncomfortable connotations. The current Scrum Guide uses "refinement". Substantively nothing changes.

How often do you do refinement?

No fixed rule. The norm is that the PO uses at most 10% of team capacity for refinement. In practice, for two-week sprints, 2 sessions of 1 hour per sprint usually works, on Thursday (week 1) and Wednesday (week 2).

Who organizes refinement?

The Product Owner is responsible for content and schedules the sessions. The Scrum Master can help with facilitation, especially for beginning teams or when the timebox is exceeded. The Developers participate actively.

How many items should be 'ready' for sprint planning?

Rule of thumb: at least one and a half to two sprints' worth of ready items at the top of the backlog. That gives the team flexibility if something changes during the sprint, and the PO room to prioritize without the team hitting something unfinished.

Can the Scrum Master lead refinement?

The Scrum Master can facilitate refinement, especially with teams just starting. Substantive responsibility for the backlog stays with the Product Owner. In more mature teams the Scrum Master often pulls back and the PO takes the lead.

What if the PO has no time for refinement?

Then that's a fundamental problem the team needs to address. Refinement isn't an optional time investment - without refinement the team gets stuck in sprints. Discuss this in a retrospective. A PO who structurally has too little time for the team isn't supporting the Scrum role as intended.

Learning to facilitate refinement

Effective refinement facilitation is a craft that touches both the PO and Scrum Master. The PO has to learn to hand off work; the Scrum Master learns to recognize the patterns that make the event fail. Our Product Owner Training dedicates extensive attention to refinement facilitation, including the anti-patterns and INVEST application from this article.

Want to read more first? Read about the role of the Product Owner who leads refinement, or see how refinement fits into the broader Scrum framework via What is Scrum?