Backlog Refiner

Purpose

Transform raw backlog items into sprint-ready User Stories that meet INVEST criteria, with clear Acceptance Criteria and reliable estimates.

When to use

• mid-sprint refinement sessions (preparing items for the next sprint)
• when backlog items are vague, oversized, or lack acceptance criteria
• when the team needs help decomposing epics into estimable stories
• when onboarding a new Product Owner who needs story-writing structure

When not to use

• prioritizing backlog order (Product Owner responsibility)
• strategic roadmap discussions or feature discovery
• items already refined and ready for sprint planning

Inputs

• raw backlog items (titles, rough descriptions, business context)
• product goal or current product increment theme
• team's story point calibration reference (what does 1 point mean?)
• known technical constraints or dependencies
• Definition of Done for the product

Procedure

1. Review each item against INVEST checklist:
   • I — Independent: not blocked by other stories
   • N — Negotiable: details can be discussed with PO
   • V — Valuable: delivers clear value to user or business
   • E — Estimable: team can estimate the effort
   • S — Small: completable within one sprint
   • T — Testable: has verifiable acceptance criteria
2. Write User Story using 3C template:
   • Card: "As a [persona], I want [action] so that [benefit]"
   • Conversation: context, questions for clarification
   • Confirmation: Acceptance Criteria in Given/When/Then
3. Estimate effort using Planning Poker reference scale:
   • 1 pt ≈ 4h | 2 pt ≈ 1 day | 3 pt ≈ 1.5 days | 5 pt ≈ 3 days
   • 8 pt = needs breakdown | 13+ pt = Epic, must split
4. Flag items that are too large — recommend split strategies.
5. Identify dependencies on other teams, services, or external parties.
6. Document risks or unknowns that could block the story.

Output

• refined User Stories with INVEST checklist scores
• Acceptance Criteria (3–5 per story, Given/When/Then format)
• Story Point estimates with rationale
• split recommendations for oversized items
• dependency and risk flags

Definition of done

• every story passes all 6 INVEST criteria
• every story has at least 3 Acceptance Criteria in Given/When/Then
• no story exceeds 8 story points without a split recommendation
• dependencies are explicitly documented

Examples

• "Refine these 8 raw feature requests into sprint-ready user stories."
• "This epic 'User Authentication' is too big — help me split it into stories."
• "Write acceptance criteria for the 'Password Reset' story."

Quality Criteria

• Feedback is specific and references exact locations in the reviewed material
• Each critique includes a concrete improvement suggestion
• Severity is categorized (critical / important / nice-to-have)
• Positive aspects are acknowledged alongside areas for improvement

Verification (4C)

Check	Question
Correctness	Is the feedback technically accurate and properly contextualized?
Completeness	Were all major sections of the reviewed material addressed?
Context-fit	Is the review granularity appropriate for the material's maturity level?
Consequence	If the author implemented all feedback literally, what could go wrong?

Edge Cases

• Material is too early-stage for detailed review — Provide structural feedback only. Note that content review is deferred until it matures.
• Reviewer lacks domain expertise — Focus on structure, clarity, and consistency. Flag domain-specific claims as 'Needs SME verification'.
• Author is defensive or resistant to feedback — Lead with what works well. Frame changes as questions rather than mandates.

Changelog

• v1.0.0 — Initial release