What This Template Is For
Backlog grooming (also called backlog refinement) is the recurring session where the team reviews, estimates, and clarifies upcoming user stories. The goal is to ensure that stories entering the next sprint are clear, estimated, and ready to build. Without regular grooming, sprint planning becomes a 3-hour marathon of clarification questions, and stories carry over because nobody understood the requirements.
This template provides a structured agenda for a 45-60 minute weekly grooming session. It includes pre-meeting preparation, a timed discussion format, and an output checklist. Pair it with the Definition of Ready template to define what "ready" means for your team. For the full sprint lifecycle, see the guide to running sprint planning.
When to Use This Template
- Weekly, mid-sprint: Hold grooming midweek so stories are ready for next sprint planning.
- Before quarterly planning: Groom the roadmap-level backlog to estimate larger initiatives.
- After a strategy shift: When priorities change, groom the backlog to reorder and cut obsolete items.
- When sprint planning runs long: Long planning sessions signal that refinement is not happening often enough.
Step-by-Step Instructions
Step 1: Prepare the Session (15 minutes, PM pre-work)
The product manager selects 5-8 stories for discussion and prepares each one with enough context for the team to evaluate.
- ☐ Select 5-8 stories from the top of the backlog
- ☐ Write or update acceptance criteria for each story
- ☐ Attach mockups or wireframes (if UI work)
- ☐ Identify open questions and dependencies
- ☐ Prioritize the list (most important stories first)
Step 2: Run the Grooming Session (45-60 minutes)
Walk through each story. For each one, the team discusses requirements, raises questions, and estimates effort.
- ☐ PM presents the story context and acceptance criteria (3 min per story)
- ☐ Team asks clarifying questions (3 min per story)
- ☐ Team estimates using planning poker or t-shirt sizing (2 min per story)
- ☐ Mark the story as "Ready" if it passes the Definition of Ready
- ☐ Park stories that need more research or design work
Step 3: Update the Backlog (10 minutes, PM post-work)
After the session, update story status and move ready items to the top of the backlog.
- ☐ Update story estimates in the project tool
- ☐ Move "Ready" stories to the ready column
- ☐ Create follow-up tasks for unresolved questions
- ☐ Archive or remove stories that are no longer relevant
The Backlog Grooming Template
Session Date: [Date]
Facilitator: [PM name]
Attendees: [Team members]
Duration: 45-60 minutes
Pre-Session Checklist (PM)
- ☐ 5-8 stories selected and prioritized
- ☐ Acceptance criteria written for each story
- ☐ Mockups attached (for UI stories)
- ☐ Open questions listed per story
- ☐ Session agenda shared with team
Session Agenda
| Time | Activity | Notes |
|---|---|---|
| 0-5 min | Review previous action items | Close or carry forward |
| 5-45 min | Story-by-story review (5-8 stories, ~5 min each) | Discuss, clarify, estimate |
| 45-55 min | Prioritize and reorder backlog | Based on new information |
| 55-60 min | Capture action items and close | Assign owners, set deadlines |
Story Review Log
| # | Story Title | Estimate | Status | Questions / Notes |
|---|---|---|---|---|
| 1 | [Title] | [X pts] | [Ready / Needs work] | [Notes] |
| 2 | [Title] | [X pts] | [Ready / Needs work] | [Notes] |
| 3 | [Title] | [X pts] | [Ready / Needs work] | [Notes] |
| 4 | [Title] | [X pts] | [Ready / Needs work] | [Notes] |
| 5 | [Title] | [X pts] | [Ready / Needs work] | [Notes] |
Action Items
| Action | Owner | Due Date |
|---|---|---|
| [Action description] | [Name] | [Date] |
| [Action description] | [Name] | [Date] |
Backlog Health Check
| Metric | Value | Target |
|---|---|---|
| Stories in "Ready" status | [X] | 1.5-2x sprint capacity |
| Stories discussed this session | [X] | 5-8 |
| Stories blocked | [X] | 0-2 |
| Average story age in backlog | [X weeks] | < 8 weeks |
Example
Session Date: Mar 4, 2026 | Facilitator: Alex (PM)
Attendees: Alex, Dana (Eng), Raj (Eng), Kim (Design), Priya (QA)
Story Review Log
| # | Story Title | Estimate | Status | Notes |
|---|---|---|---|---|
| 1 | Add team member invite flow | 8 pts | Ready | Figma mockup approved. API endpoint exists. |
| 2 | Bulk export dashboard data as CSV | 5 pts | Ready | Edge case: export >10K rows handled via async job. |
| 3 | Notification preferences page | 5 pts | Needs work | Design not started. Kim to deliver mockup by Friday. |
| 4 | Webhook retry logic for failed deliveries | 3 pts | Ready | Tech approach: exponential backoff, max 5 retries. |
| 5 | Admin role permissions audit log | 8 pts | Needs work | Open question: what events to log? Alex to get requirements from compliance team. |
| 6 | Fix timezone display bug in activity feed | 2 pts | Ready | Root cause identified. Raj to fix. |
Action Items
| Action | Owner | Due Date |
|---|---|---|
| Deliver notification preferences mockup | Kim | Mar 7 |
| Get audit log event requirements from compliance | Alex | Mar 6 |
| Spike on async export job architecture | Dana | Mar 6 |
Backlog Health Check
| Metric | Value | Target |
|---|---|---|
| Stories in "Ready" status | 12 | 10-14 (1.5x capacity of ~34 pts) |
| Stories discussed this session | 6 | 5-8 |
| Stories blocked | 1 (audit log) | 0-2 |
| Average story age | 3.2 weeks | < 8 weeks |
Tips
- Groom one sprint ahead. By the time sprint planning starts, you should have 1.5-2x your sprint capacity in "Ready" stories. This gives the team options during planning without forcing unrefined stories into the sprint.
- Time-box each story to 5 minutes. If a story needs more than 5 minutes of discussion, it is not ready for estimation. Park it and schedule a separate spike or design session. Do not let one story consume the entire session.
- Kill stale stories. If a story has been in the backlog for more than 8 weeks without being groomed, it is likely no longer relevant. Archive it. You can always recreate it if the need returns. The RICE framework can help you decide which stories to keep and which to cut.
- Separate grooming from planning. Grooming is about understanding and estimating stories. Sprint planning is about committing to a sprint goal. Teams that combine them end up with 3-hour planning meetings and exhausted engineers.
- Include QA and design. Grooming is not just for PMs and engineers. QA catches missing test cases. Designers flag UX gaps. Including them early prevents rework during the sprint.