codexkit-backlog-refiner

# 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