Skip to main content

Backlog Refinement

Backlog Refinement prepares stories for future sprints by adding detail, estimating effort, and ensuring the team understands upcoming work.

Overview​

Backlog Refinement (formerly called "Grooming") is an ongoing process where the team collaboratively prepares backlog items for upcoming sprints. Refinement bridges the gap between high-level product vision and executable sprint work, transforming vague ideas into well-understood, estimated stories.

Without refinement, sprint planning becomes inefficient and frustrating. Teams spend hours debating requirements, clarifying acceptance criteria, and discussing technical approaches - work that should happen beforehand. Poor planning leads to mid-sprint requirement changes, scope creep, and missed commitments. Refinement prevents this by front-loading the analysis and discussion when there's time to think carefully.

Refinement also enables team autonomy. When stories arrive in sprint planning already refined with clear acceptance criteria and estimates, the team can focus on commitment and task breakdown rather than requirements archaeology. This shifts sprint planning from a lengthy negotiation to a quick confirmation and commitment ceremony.

Refinement Goal

The goal is to have at least 2 sprints worth of refined, estimated stories ready at all times. This buffer enables smooth sprint planning and reduces uncertainty. The two-sprint horizon balances preparation with flexibility - far enough ahead to enable planning, near enough that requirements remain stable. Planning further ahead wastes effort on stories that may change; planning less creates sprint planning bottlenecks.

Core Principles​

  • Ongoing: Refinement happens throughout sprint, not just once
  • Collaborative: Team and Product Owner work together
  • Preparatory: Stories ready before sprint planning
  • Time-Boxed: Maximum 10% of sprint capacity (4 hours per 2-week sprint)
  • Iterative: Stories refined multiple times as understanding grows

Refinement Structure​

Duration and Frequency​

  • Duration: 1-2 hours per session
  • Frequency: 1-2 times per sprint (mid-sprint)
  • Total Time: ~10% of sprint capacity

Participants​

  • Development Team (required)
  • Product Owner (required)
  • Scrum Master (facilitator)
  • Subject Matter Experts (as needed)

Session Agenda (90 minutes)​

Part 1: Review Priorities (5 minutes)​

Product Owner Presents:

  • Top priority stories for upcoming sprints
  • Any changes in priorities since last refinement
  • Business context and urgency

Team Reviews:

  • Current sprint progress (affects next sprint capacity)
  • Upcoming technical dependencies
  • Questions or concerns about priorities

Part 2: Story Discussion (60 minutes)​

Story-by-Story Walkthrough​

For Each Story (10-15 minutes):

  1. Product Owner Explains (3 min)

    • User story and business value
    • Success criteria
    • User personas and scenarios
    • Any constraints or dependencies

  2. Team Asks Questions (5 min)

    • Clarify requirements
    • Identify technical approaches
    • Uncover edge cases
    • Understand acceptance criteria

  3. Define Acceptance Criteria (4 min)

    • Specific, testable criteria
    • Edge cases and error scenarios
    • Performance requirements
    • Security/compliance needs

  4. Identify Technical Tasks (3 min)

    • High-level technical approach
    • Key components to build
    • Integration points
    • Testing strategy

Story Discussion Example​

Story: As a customer, I want to cancel scheduled payments so I can change my plans.

Product Owner Context:

Business Value: Customers frequently request payment cancellation
Success Criteria: Allow cancellation up to 1 hour before scheduled time
User Persona: Busy parent who schedules bill payments in advance
Constraint: Must maintain audit trail for compliance

Team Questions:

Q: Can customers cancel payments already in process?
A: No, only scheduled (not yet processing)

Q: What happens to cancelled payment?
A: Status changes to CANCELLED, remains in history

Q: Any notification required?
A: Yes, email confirmation of cancellation

Q: Can cancelled payments be rescheduled?
A: Yes, creates new scheduled payment

Acceptance Criteria Defined:

Given a scheduled payment at least 1 hour in future
When customer clicks "Cancel Payment"
Then payment status changes to CANCELLED
And audit log entry created
And email confirmation sent
And payment remains in payment history
And customer can create new payment with same details

Given a scheduled payment less than 1 hour away
When customer attempts to cancel
Then error message shown "Cannot cancel - payment processing soon"
And payment status unchanged

Part 3: Story Estimation (20 minutes)​

Planning Poker​

Planning Poker leverages collective intelligence through structured estimation. The simultaneous reveal prevents anchoring bias (where early estimates influence later ones), and the discussion of divergent estimates surfaces different understandings of the work. When one developer estimates 2 points and another estimates 8, they're not both right - they're understanding different stories. The discussion reconciles these perspectives into shared understanding.

Process:

  1. Team members select estimate cards privately (1, 2, 3, 5, 8, 13, 21)
  2. Everyone reveals simultaneously (prevents anchoring)
  3. Discuss differences - especially highest and lowest estimates
  4. High estimator explains why complex; low estimator explains why simple
  5. Team clarifies understanding, then re-estimates if needed
  6. Reach consensus (not averaging, but shared understanding)

Estimation Scale (Fibonacci):

1 point:  Trivial change, < 2 hours
2 points: Simple story, ~4 hours
3 points: Straightforward story, ~1 day
5 points: Standard story, ~2 days
8 points: Complex story, ~3-4 days
13 points: Very complex, consider splitting
21+ points: Too large, must split

The Fibonacci sequence (1, 2, 3, 5, 8, 13...) reflects increasing uncertainty at larger sizes. The difference between 1 and 2 points is clear (double the effort), but distinguishing between 12 and 13 points is meaningless - both represent high uncertainty. The sequence forces larger stories into buckets that acknowledge this uncertainty rather than pretending precision exists.

Story points measure relative complexity, not absolute time. A 5-point story isn't guaranteed to take 2 days - it's roughly 5× the effort of a 1-point story. This abstraction makes estimation faster and more stable across teams. Time estimates require detailed task breakdown; relative sizing works with limited information.

Estimation Example​

Story: Cancel Scheduled Payment

Round 1 Estimates: 2, 3, 3, 5, 8

Discussion:
- 8: "We need to handle edge cases, add audit logging, send emails"
- 2: "We already have similar cancel logic for regular payments"
- 5: "Email template might be tricky, need audit logging"

Team discusses:
- Can reuse existing cancel payment logic: Reduces effort
- Email template exists, just needs customization: Reduces effort
- Audit logging pattern established: Minimal effort

Round 2 Estimates: 3, 3, 3, 5, 3

Consensus: 3 story points

Relative Sizing​

Compare to Known Stories:

Story A: Add new field to form (2 points)
Story B: This story (? points)
Story C: Implement OAuth2 integration (8 points)

Team: "This is more complex than adding a field but much simpler than OAuth2"
Estimate: 5 points

Splitting Large Stories​

Large stories (>8 points) represent too much uncertainty and complexity for a single sprint commitment. They also prevent incremental value delivery - the team delivers nothing until the entire story completes. Splitting enables faster feedback and reduces risk.

Story Too Large (>8 points):

Original: Implement payment notification system (13 points)

Split Into:

  • Email notification service (5 points)
  • SMS notification service (5 points)
  • In-app notification (3 points)
  • Notification preferences UI (3 points)

Total: 16 points across 4 stories (allows incremental delivery)

Notice the split enables the team to deliver email notifications first (likely highest value), get user feedback, then build SMS and in-app notifications. The monolithic 13-point story would deliver everything at once with no opportunity for course correction. Smaller stories also fit sprint capacity better - it's easier to commit to 5-point stories than betting an entire sprint on a 13-point unknown.

Part 4: Definition of Ready Check (5 minutes)​

Definition of Ready Criteria​

For story to be ready for sprint planning:

  • User story format complete (As a... I want... So that...)
  • Acceptance criteria defined and testable
  • Dependencies identified and documented
  • Estimated by team (story points assigned)
  • Technical approach discussed
  • No blocking questions remain
  • Small enough to complete in sprint (<8 points)
  • Product Owner available for questions
  • Test strategy identified

See full Definition of Ready →

Moving Stories to "Ready"​

If Story Meets Criteria:

  • Move to "Ready for Sprint" column in Jira
  • Available for sprint planning
  • Fully refined and estimated

If Story Not Ready:

  • Document what's missing
  • Assign follow-up actions
  • Re-refine in next session
  • Keep in "Needs Refinement" column

Refinement Best Practices​

Focus on Upcoming Work​

Prioritize Refinement:

Sprint N (current):     Don't refine (already planned)
Sprint N+1:             Top priority for refinement
Sprint N+2:             High priority for refinement
Sprint N+3 and beyond:  Low priority, rough estimates only

Keep Pipeline Full:

  • Always have 2 sprints worth of refined stories
  • Allows flexibility in sprint planning
  • Reduces uncertainty and delays

Involve Right People​

Core Team: Always present Specialists: Invite as needed

  • Security expert for security stories
  • UX designer for UI-heavy stories
  • Database expert for data migration stories
  • DevOps for infrastructure stories

Document Decisions​

Capture in Story:

  • Key discussion points
  • Technical approach agreed
  • Edge cases identified
  • Open questions and answers
  • Links to related stories or documentation

Example Jira Comment:

## Refinement Notes - 2025-01-28

**Approach Agreed**:
- Reuse existing cancel payment logic
- Add audit logging using standard pattern
- Email template: customize existing "payment-confirmation" template

**Edge Cases Discussed**:
- Payment within 1 hour of scheduled time: Show error, don't allow
- Payment already processing: Return 409 Conflict error
- Multiple cancel requests: Idempotent, return success if already cancelled

**Dependencies**:
- None

**Technical Decisions**:
- Backend endpoint: PATCH /api/v1/payments/{id}/cancel
- Response: 204 No Content on success
- Audit log event: PAYMENT_CANCELLED

**Estimate**: 3 story points
**Ready for Sprint**: Yes

Anti-Patterns​

Over-Refinement​

Problem: Spending too much time on distant backlog items Solution: Focus on next 2 sprints, keep distant items roughly estimated

Design Sessions​

Problem: Refinement becomes detailed design/architecture session Solution: High-level understanding only; defer detailed design to sprint

Acceptance Criteria Overload​

Problem: 20+ acceptance criteria, story becomes unwieldy Solution: If too many criteria, split the story

No Product Owner​

Problem: Refinement without Product Owner present Solution: Product Owner must attend; reschedule if unavailable

Estimation Debates​

Problem: Spending 30 minutes arguing over 3 vs 5 points Solution: Timebox discussions (5 min max), go with majority

Refinement Metrics​

Backlog Health​

Track These Metrics:

Ready Stories:

Target: 2 sprints worth of refined stories
Current: 18 stories (team velocity 25 points, 2 sprints = 50 points)
Status: Needs more refinement

Estimation Accuracy:

Compare estimated vs actual story points over last 3 sprints
Sprint 10: 95% accuracy
Sprint 11: 87% accuracy
Sprint 12: 92% accuracy
Average: 91% (good accuracy)

Re-Estimation Rate:

Stories re-estimated during sprint planning
Target: <10%
Current: 15% (needs improvement in refinement)

Remote Refinement​

Tools​

Video Conferencing: Camera on, screen share Digital Board: Jira board visible Planning Poker: Use digital tool (PlanITPoker, Scrum Poker) Whiteboard: Miro/Mural for sketching

Engagement​

Timebox Strictly: More critical remotely Use Polls: Quick consensus checks Breakout Rooms: Smaller discussions if needed Async Follow-Up: Document questions, answer async

Refinement Checklist​

Before Refinement​

  • Product Owner prioritized backlog
  • Top stories identified for refinement
  • Previous refinement action items completed
  • Specialists invited if needed
  • Digital poker tool ready (remote)

During Refinement​

  • Each story discussed thoroughly
  • Acceptance criteria defined
  • Team questions answered
  • Stories estimated
  • Definition of Ready verified
  • Decisions documented in story

After Refinement​

  • Refined stories moved to "Ready" column
  • Incomplete stories documented
  • Follow-up actions assigned
  • Next refinement scheduled

Further Reading​

Summary​

Key Takeaways:

  1. Ongoing Process: Refinement happens throughout sprint, not just once
  2. Two Sprints Ahead: Always have 2 sprints worth of refined stories ready
  3. Collaborative: Team and Product Owner refine together
  4. Time-Boxed: Maximum 10% of sprint capacity (4 hours per 2-week sprint)
  5. Definition of Ready: Stories must meet criteria before sprint planning
  6. Planning Poker: Use relative estimation for accuracy and team alignment
  7. Split Large Stories: Stories >8 points should be split into smaller stories
  8. Document Decisions: Capture technical approach, edge cases, and dependencies in story