Backlog Refinement
An ongoing activity where the Scrum Team reviews, estimates, and orders Product Backlog items to ensure they are well-understood and ready for future sprints.
What it is
Backlog Refinement (formerly called grooming) is the continuous process of keeping the Product Backlog in good shape. The Scrum Guide states that refinement is an ongoing activity, not a formal event with a mandated timebox.
- The team may spend up to 10% of its capacity on refinement.
- Items are broken down, clarified, and defined just-in-time for upcoming sprints.
- The team asks questions, identifies dependencies, and assigns estimates.
- Good refinement prevents Sprint Planning from becoming a requirements marathon.
When to use it
Refinement happens continuously. Most teams schedule 1–2 dedicated sessions per week (often 30–60 minutes each) to keep the top of the backlog sharp, with ad-hoc conversations as needed.
Key concepts
| Concept | What it means |
|---|---|
| Definition of Ready | A shared understanding of the information a Product Backlog item needs before the team can pull it into a sprint. |
| Story Splitting | Breaking large, vague items into smaller, independently deliverable pieces that still provide user value. |
| Estimation | Assigning relative size (story points, t-shirt sizes, etc.) to reflect effort, complexity, and uncertainty. |
| Dependency Mapping | Identifying external teams, systems, or approvals that could block delivery and surfacing them early. |
Common pitfalls
- PO refining alone: Without developer input, estimates and feasibility assumptions will be wrong.
- Spending too much time on low-priority items: Focus refinement effort on the top of the backlog; distant items can stay coarse.
- Turning it into solution design: The goal is understanding and readiness, not a full technical design session.
- Refusing to split large stories: If an item is too big to complete in a sprint, split it. There is always a way.
- Neglecting technical debt: Refinement is not just for features. Allocate capacity to refining bugs, refactoring, and infrastructure work.
NZ context
New Zealand business stakeholders often have limited availability due to smaller team sizes and flatter organisational structures. Thorough refinement ensures that when stakeholders are present, the conversation is focused and productive. It also reduces the risk of discovering late-stage blockers that are harder to resolve across NZ's geographically distributed teams.
Industry Reality
- Most teams treat refinement as a single weekly meeting rather than a continuous activity — and Sprint Planning suffers for it. Expect to see the last 20 minutes of planning spent re-explaining stories that should have been refined days earlier.
- The "10% capacity" guideline is rarely tracked. High-performing teams do it naturally; struggling teams either skip refinement entirely or let it balloon into two-hour sessions that drain morale.
- Product Owners frequently refine in isolation and then present "finished" backlog items to the team. Experienced practitioners push back on this and insist on collaborative sessions — they know the assumptions are almost always wrong.
- In NZ SMEs with small teams wearing multiple hats, refinement often doubles as a design discussion, stakeholder call, and tech-debt negotiation rolled into one. Senior testers learn to structure these sessions to stay focused.
- Estimation debates consume disproportionate time. Seasoned teams timebox estimates aggressively (2–3 minutes per item) and treat them as forecasting tools, not commitments.
Context guide
How the right level of Backlog Refinement effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| NZ public-sector digital transformation (e.g. TransitNZ TransitNZ replacing legacy permit systems) | Essential | Regulatory obligations (Privacy Act 2020, WCAG 2.2 AA, NZISM security controls) must be written into acceptance criteria before a story enters a sprint — retrospective fixes cost significantly more under government procurement rules. |
| Financial services (Harbour Bank or Pacific Bank core banking feature delivery) | Essential | RBNZ prudential requirements and PCI-DSS controls mean undiscovered security or compliance gaps discovered mid-sprint trigger formal change management processes that cannot be resolved within a two-week timebox. |
| Cross-agency integration (Benefits NZ income support systems interacting with Revenue NZ income data) | Essential | API contracts between agencies move slowly; discovering a missing data field mid-sprint stalls the entire feature. Refinement must include dependency mapping with named contacts from each agency before the sprint starts. |
| NZ SME SaaS team (10–25 staff, shipping a single product with monthly release cycles) | Medium | Smaller teams often wear multiple roles; formal refinement sessions can feel heavy. Lightweight Three Amigos conversations (15–20 minutes per story) deliver most of the value without the overhead of a full ceremony. |
| Early-stage startup with a single founding developer and a product-owner founder | Low | At this scale, the developer and founder share full context continuously. Formal refinement adds ceremony without reducing ambiguity — prioritise rapid shipping and course-correct on user feedback instead. |
| Distributed Aotearoa/Australia trans-Tasman product team with offshore development (e.g. TeleNZ product + Indian development centre) | High | Time-zone gaps mean that ambiguous stories arriving at the offshore team at 9 am cannot be clarified until NZ business hours — half the sprint day is lost. Written acceptance criteria and recorded refinement decisions are the substitute for real-time conversation. |
Trade-offs
What you gain and what you give up when you adopt Backlog Refinement.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Sprint Planning becomes selection, not discovery — the team walks in knowing what they are building and why. | Requires consistent participation from developers, testers, and a Product Owner who is genuinely available — hard to sustain in organisations where team members are shared across projects. | The team is so small and co-located that continuous hallway conversations already keep stories clear; formal sessions add overhead without adding clarity. |
| Testers can influence acceptance criteria before development starts, shifting quality effort left and reducing late-sprint rework. | Refining too far ahead wastes effort — requirements change, and stories groomed three months in advance often need re-refining before they are actually built. | The domain is so novel or unstable that no story can be meaningfully specified until a spike or prototype has been built — in that case, run a discovery sprint first. |
| Dependency and integration risks surface before a sprint starts, giving the team time to negotiate, unblock, or re-sequence work. | Poorly facilitated refinement drifts into solution design — developers propose architecture, estimating becomes irrelevant, and the session overruns without producing actionable outcomes. | A technical spike or Architecture Decision Record (ADR) session is needed first — bring the story back to refinement once the technical approach is settled. |
| Non-functional requirements (performance, security, accessibility) are assigned ownership before development starts, not discovered during UAT. | Teams can develop a false sense of security from a well-refined backlog — if the refinement process is shallow, stories appear ready but carry hidden assumptions that detonate mid-sprint. | The product requires a formal requirements traceability matrix (e.g. safety-critical systems); in that case, structured requirements management replaces agile refinement. |
Enterprise reality
How backlog refinement changes at 200–300-developer scale — banks, government agencies, and telcos across Aotearoa New Zealand.
- Refinement tooling is automated at scale: Jira-native scripts, Confluence templates, and AI-assisted story linting flag missing acceptance criteria, unlinked epics, and stories without test coverage before they reach a human session. At Pacific Bank, squads working under RBNZ prudential requirements use mandatory Jira field validation — a story cannot transition to "Ready for Refinement" unless a security classification and data-sensitivity tag are populated, eliminating a whole class of compliance gap that small teams catch (or miss) manually.
- Governance overhead is substantial: every backlog item touching customer data must demonstrate Privacy Act 2020 consideration before entering a sprint, and items that affect payment flows require a PCI DSS impact assessment signed off by an architect. At this scale, a single story approved without that sign-off can trigger a formal change-management rollback costing tens of thousands of dollars in audit remediation — far more than the original development effort.
- Coordinating across 10–15 squads means refinement operates in tiers: individual squads refine their own stories, a cross-squad "refinement guild" meets fortnightly to resolve inter-squad dependencies, and a programme-level backlog review happens monthly to re-sequence epics blocked by shared-platform releases. Without this structure, squad A builds to an API contract that squad B has already changed, and the integration test environment becomes a collision zone for four teams simultaneously.
- Multi-timezone coordination compounds ambiguity cost: at TeleNZ and similar telcos with offshore development centres, an under-specified story arriving at the Indian development team at 9 am NZ time cannot be clarified until NZ business hours resume — effectively losing half a working day. Enterprise refinement playbooks mandate that every "Ready" story includes a recorded three-amigos summary video or a written decision log, so offshore developers have enough context to start without a synchronous check-in.
◆ What I would do
Professional judgement — when to adopt Backlog Refinement, when to adapt it, and what to watch for.
The bottom line: Refinement is only as valuable as the quality of the questions asked in the room — one tester asking "can we actually test this on our staging environment before sprint end?" is worth more than three hours of acceptance criteria polishing.
Best Practices
- ✓ Refine just-in-time, not all-at-once. Keep two or three sprints' worth of backlog items in a "ready" state. Items beyond that should stay coarse — refining them too early wastes effort as context changes.
- ✓ Bring testability into every item. Before marking a story ready, confirm the team can state concrete acceptance criteria and at least one test scenario. Stories without testability signals are a test lead's red flag.
- ✓ Split on the dependency boundary. When a story touches multiple systems or teams, split it so each piece can be deployed and tested independently. This exposes integration risk early.
- ✓ Timebox estimation, not discussion. Spend time understanding what you're building, not debating whether it's a 5 or an 8. Use relative sizing against known reference stories.
- ✓ Track refinement debt. Items that get skipped, deferred, or half-refined should be flagged — they tend to cluster and cause sprint failures. Name them explicitly in your board's "needs refinement" column.
- ✓ Include non-functional items. Performance targets, security controls, accessibility requirements, and data retention rules all need refinement. In NZ public-sector work, privacy and Te Tiriti considerations may require their own acceptance criteria.
- ✓ Record decisions, not just outcomes. Capture the rationale for splits, scope changes, and deprioritisations in the item's description. Context that lives only in someone's head becomes a sprint blocker when they're on leave.
- ✓ Rotate facilitation. A refinement session always run by the same person creates a single point of knowledge. Senior team members who take turns facilitating build shared ownership of backlog quality.
Common Misconceptions
❌ Myth: Backlog refinement is the Product Owner's job and testers just attend.
Reality: Testers are among the most valuable contributors in refinement. They surface ambiguity, challenge vague acceptance criteria, identify missing edge cases, and flag items that cannot be meaningfully tested. A tester who stays quiet in refinement will deal with the consequences at the end of the sprint.
❌ Myth: If an item has acceptance criteria, it's ready to go into a sprint.
Reality: Acceptance criteria are necessary but not sufficient. A truly "ready" item also has an estimated size the team agrees with, known dependencies resolved or flagged, a clear Definition of Ready met, and no open technical questions that would block development from starting. Checklist-ticking produces surprises mid-sprint.
❌ Myth: Refinement is a planning ceremony — once refined, items are locked.
Reality: Refinement is a living process. A story can re-enter refinement if new information emerges, scope changes, or dependencies shift. Teams that treat refined items as frozen resist necessary course-corrections and accumulate hidden risk. The backlog should always reflect the team's current best understanding, not a snapshot from three weeks ago.
Career level guidance
| Level | Focus |
|---|---|
| Junior | Ask clarifying questions, learn the team's estimation baseline, and practice splitting stories with guidance from seniors. |
| Senior | Lead splitting discussions, flag dependencies and architectural concerns, and mentor juniors on writing good backlog items. |
| Test Lead | Define testability criteria for each item, identify quality risks early, and ensure non-functional requirements are captured before sprint start. |
Senior engineer insight
The teams who get the most out of refinement are the ones who treat it as a testing conversation first, not a sizing exercise. When the tester drives the session by asking “how would we know this works?” before any estimate is given, vague stories surface immediately and the whole team's understanding sharpens fast. Teams who struggle typically let refinement drift into a Product Owner monologue with nodding developers — and then wonder why stories fall apart mid-sprint. The pattern that actually works: open every item with a concrete test scenario before touching complexity or points.
The most common mistake: teams refine stories to the point where they sound ready — acceptance criteria written, estimate agreed — but nobody has actually asked whether the criteria are testable within the sprint's tooling and data. That gap surfaces at day three of development, not day one.
From the field
A Wellington-based team delivering a digital case management system for a central government agency had a disciplined refinement cadence: one-hour sessions twice a week, backlog kept three sprints deep, every story estimated. What they didn't do was validate that acceptance criteria were actually testable in their staging environment. A story for “display uploaded documents with correct metadata” sailed through four refinement sessions and into a sprint — only to stall on day two when the team discovered the staging document store was read-only by policy and no test fixture data had been loaded. The sprint goal slipped by three days. After that, they added a single mandatory checkpoint to their Definition of Ready: “Can a tester run at least one acceptance scenario on staging today?” It sounds obvious in hindsight, but that one question caught six broken-environment blockers in the next quarter before they ever hit a sprint.
Self-Check
Click each question to reveal the answer.
Q1: Your team is refining a backlog for a new Benefits NZ income-support portal. The Product Owner has pre-written acceptance criteria for 12 stories but none have been seen by developers or testers before today's refinement session. Sprint Planning is tomorrow. What do you do, and why is presenting pre-written stories a refinement anti-pattern?
A: Push back on pulling any of the 12 stories into tomorrow's sprint without at minimum a group read-through, feasibility check, and testability review. Pre-written acceptance criteria bypass the collaborative intent of refinement — they lock in assumptions about technical approach, scope, and edge cases before the people who will build and test the work have had any input. In a government portal context, stories almost certainly need explicit acceptance criteria covering privacy (Privacy Act 2020), accessibility (WCAG 2.2 AA), and edge cases around eligibility rules. Surface those gaps now, not mid-sprint.
Q2: What is the key difference between backlog refinement and sprint planning, and why does confusing the two cause recurring sprint failures?
A: Refinement is a continuous activity focused on understanding, splitting, and estimating items so they reach a "ready" state before sprint planning. Sprint planning is a time-boxed event where the team selects from already-ready items and commits to a sprint goal. When teams confuse the two, sprint planning becomes a requirements workshop — stories are analysed, split, and debated in real time, the timebox blows out, and the team starts the sprint with incomplete understanding. The fix is keeping two to three sprints of ready backlog items at all times so planning can focus on selection and tasking, not discovery.
Q3: A developer on your Revenue NZ tax-filing project says "we don't need refinement sessions — I read the Jira ticket, I know what to build, and the tester can figure out the tests when it lands in their column." What is wrong with this view and how would you respond?
A: This approach treats testing as a downstream checkpoint rather than a quality activity woven through delivery. Without refinement, the tester has no input on acceptance criteria, no early warning of ambiguous scope, and no chance to flag untestable stories before development starts. On an Revenue NZ project, missing refinement is especially costly: tax rules have edge cases (provisional tax thresholds, filing extensions, income types) that are invisible in a short Jira summary but obvious the moment a tester or developer with domain knowledge reads the story aloud. The result is rework, sprint failures, and bugs caught in UAT or production. The developer's confidence is not evidence the story is well-understood — it is evidence of undiscovered assumptions.
Q4: When is backlog refinement NOT the right technique to use, and what should you do instead?
A: Refinement is unsuitable when a backlog item is so large or strategically uncertain that the team does not yet have enough context to split or estimate it meaningfully — for example, a vague epic like "integrate with RealMe for identity verification" before anyone has read the API documentation or spoken to the Department of Internal Affairs integration team. Refining prematurely produces false estimates and shallow acceptance criteria that have to be redone. The right approach is to first run a spike (a time-boxed investigation story) to gather facts, or to hold a product discovery workshop with stakeholders. Only once sufficient context exists should the resulting stories enter the refinement pipeline.
Why teams fail here
- Treating refinement as a Product Owner solo activity. When the PO pre-writes acceptance criteria and presents finished stories, the team validates nothing — they rubber-stamp assumptions and carry hidden risk into the sprint.
- Refusing to split stories that won’t fit. Teams confuse “this is one user journey” with “this must be one story.” Any story that can’t be completed, tested, and demoed within a sprint is a delivery risk dressed as a backlog item.
- Letting estimation debates swallow discussion time. A 45-minute refinement session where 30 minutes go on whether a story is a 5 or an 8 is a waste. Points are a forecasting signal, not a contract — timebox them to two minutes and move on.
- Not including non-functional acceptance criteria. Performance thresholds, WCAG 2.2 AA compliance, Privacy Act obligations, and data retention rules are testable requirements — if they’re not in the story before the sprint starts, nobody owns them and they get discovered in UAT.
Key takeaway
Backlog Refinement done well is not a meeting about tasks — it is the team’s shared act of turning ambiguity into shared understanding, so that when Sprint Planning arrives, everyone already knows what “done” looks like.
How this has changed
The field moved. Here is how Backlog Refinement evolved from its origins to current practice.
Product backlog grooming is informal — teams review and discuss stories as needed. No formal ceremony exists. Teams discover mid-sprint that stories are not ready to develop.
Ken Schwaber and Jeff Sutherland acknowledge backlog refinement as an ongoing activity consuming up to 10% of sprint capacity. Not yet a named Scrum event but recognised as essential.
The Scrum Guide renames "grooming" to "backlog refinement" and formalises it as a collaborative activity where the team adds detail, estimates, and order to backlog items before sprint planning.
Three Amigos sessions — developer, tester, and BA jointly reviewing stories before sprint — become best practice. Testers contribute acceptance criteria, edge cases, and testability concerns before stories are committed.
AI tools assist refinement by analysing stories for completeness, suggesting missing acceptance criteria, flagging ambiguous language, and estimating relative complexity from historical data. The tester asking "what could go wrong?" remains the highest-value human input.