backlog-refinement

What this skill does

# Backlog Refinement Expert

## Overview

Refinement is the most under-invested ritual in agile teams. Stories arrive at sprint planning oversized, ambiguous, or strategically disconnected, and the team spends planning meetings doing what should have happened the week before. This skill is the refinement playbook: how to grade stories against INVEST, how to split stories vertically (so each slice ships value end-to-end), and how to keep a working Definition of Ready and Definition of Done that prevent half-baked work from entering or leaving a sprint.

The skill includes a Python scorer (`refinement_scorer.py`) that grades each story in a JSON backlog file against the six INVEST criteria and outputs a readiness score (0-6) per story. Stories scoring 5-6 are sprint-ready; 3-4 need targeted refinement; below 3 need to be reworked or returned to discovery.

This is a complement to `wwas/` (the Why-What-Acceptance format) and `job-stories/` (the JTBD format). Either format produces stories; this skill grades them and gets them sprint-ready.

### When to Use

- **Weekly refinement session** -- Standard ritual: grade next-sprint candidates against INVEST and split anything too large.
- **Backlog hygiene sweep** -- Quarterly: re-grade the top 30 backlog items and retire what no longer connects to current strategy.
- **Sprint planning input** -- Before planning: confirm all candidates pass DoR.
- **New team onboarding** -- A new team needs a shared definition of "ready" and "done" to ship predictably.
- **Velocity diagnosis** -- If sprint completion is erratic, refinement quality is usually the cause; this skill is the diagnostic.

### When NOT to Use

- For pure technical task lists with no user-facing outcome -- INVEST applies loosely; use a simpler checklist.
- For ad-hoc bug triage -- bugs follow a different lifecycle (triage > prioritize > fix) than feature stories.
- When the work has not been scoped yet -- send it back to `discovery/` skills before refining.

## The INVEST Criteria

Bill Wake's INVEST acronym (2003) defines the six properties of a high-quality story:

| Letter | Property | What it means | Quick test |
|--------|----------|---------------|------------|
| **I** | **Independent** | Can be delivered without waiting for another story | "Can this ship alone? If no, what is the dependency?" |
| **N** | **Negotiable** | Implementation is open to discussion | "Does this prescribe HOW, or only WHAT and WHY?" |
| **V** | **Valuable** | Delivers value to a user or business | "If we built only this and nothing else, who benefits?" |
| **E** | **Estimable** | The team can size effort with reasonable confidence | "Can two engineers independently estimate within ~2x?" |
| **S** | **Small** | Fits within one sprint (typically 1-5 days of effort) | "Can a pair finish this in <5 days?" |
| **T** | **Testable** | Acceptance criteria are observable and verifiable | "How would QA prove this is done?" |

A story scoring 6/6 is sprint-ready. A story scoring 5/6 with a soft fail on one criterion is usually safe to admit if the team agrees on the gap. Anything 4 or below needs a refinement pass.

## Vertical Slicing and Story Splitting

The most common refinement failure is **horizontal slicing** -- splitting a story by layer (DB, API, UI, infra) rather than by user outcome. Horizontal slices fail INVEST-V (no slice delivers user value alone) and INVEST-I (every slice depends on the others).

**Vertical slices** cut through every layer to deliver an end-to-end thin sliver of user value. Each slice is independently shippable and independently valuable.

### The 9 splitting recipes (Richard Lawrence)

Richard Lawrence's Story Splitting Flowchart enumerates 9 reliable patterns. Use them in this priority order:

| # | Pattern | Use when | Example |
|---|---------|----------|---------|
| 1 | **Workflow steps** | The story spans a multi-step process | "Checkout" → "Add to cart" / "Pay" / "Confirm" |
| 2 | **Business rule variations** | The story covers many rules | "Discount" → "Loyalty discount" / "Volume discount" / "Promo code" |
| 3 | **Happy / unhappy paths** | Error handling adds complexity | "Submit form" → "Submit valid form" / "Handle validation errors" |
| 4 | **Input options / platforms** | Multiple inputs or platforms | "Search" → "Search via keyword" / "Search via filters" / "Search via voice" |
| 5 | **Data types or parameters** | Multiple data variations | "Export report" → "Export CSV" / "Export PDF" / "Export XLSX" |
| 6 | **Operations (CRUD)** | The story covers multiple ops | "Manage users" → "Create user" / "Edit user" / "Delete user" |
| 7 | **Test scenarios / cases** | Test plan reveals natural splits | "Login" → "Login with email" / "Login with SSO" / "Login with MFA" |
| 8 | **Defer performance** | The simple version works | "Search 1M records" → "Search basic" (v1) / "Optimize search" (v2) |
| 9 | **Spike (last resort)** | The team cannot estimate | A time-boxed investigation, then re-split |

### The SPIDR alternative (Mike Cohn)

Mike Cohn's SPIDR mnemonic covers a similar space with five buckets: **S**pikes, **P**aths, **I**nterfaces, **D**ata, **R**ules. Use whichever taxonomy your team finds memorable; the patterns overlap.

### Splitting anti-patterns to avoid

- **Splitting by layer.** "Backend API" / "Frontend UI" / "Database migration" are tasks, not stories. They violate INVEST-V.
- **Splitting by team.** If only "the backend team" can deliver a slice, the slice is not independently valuable.
- **Splitting by sprint.** Forcing a 10-day story into "Sprint 1 part" and "Sprint 2 part" is scheduling, not splitting.
- **Splitting too thin.** A 2-hour story is not a story; it is a task. Roll it back up.

## Definition of Ready (DoR)

The DoR is the team's agreement on what a story must satisfy before it can enter a sprint. It is the **input quality gate**.

### Recommended DoR template

A story is Ready when:

- [ ] Title is descriptive and specific (no "Implement X")
- [ ] Why statement references a specific objective, OKR, or customer outcome
- [ ] Description is 1-2 paragraphs and serves as a reminder of the refinement discussion
- [ ] Acceptance criteria: at least 4, each describing an observable user-facing outcome
- [ ] INVEST score >= 5/6 (verified by `refinement_scorer.py` or facilitated review)
- [ ] Dependencies on other stories or teams are identified and noted
- [ ] Design assets linked (or marked "TBD by [date]" with owner)
- [ ] Estimated by the team using their preferred unit (story points, t-shirt, days)
- [ ] No open blocker questions
- [ ] Tagged with sprint goal it contributes to

### DoR anti-patterns

- **Too strict** -- a 20-item DoR creates a backlog of "almost ready" stories. Cap at 10.
- **Unenforced** -- a DoR that planning ignores is theater. Enforce: stories that fail DoR are removed from the sprint candidate list, not "negotiated in."
- **One-size-fits-all** -- spikes, bugs, and feature stories have different DoRs. Keep three short checklists rather than one long one.

## Definition of Done (DoD)

The DoD is the team's agreement on what a story must satisfy before it can be called complete. It is the **output quality gate** and is typically uniform across all stories.

### Recommended DoD template

A story is Done when:

- [ ] All acceptance criteria pass in the deployed environment
- [ ] Code merged to main branch (or release branch per release process)
- [ ] Automated tests written and passing (unit + integration for changed paths)
- [ ] Code reviewed and approved by at least one other engineer
- [ ] Manual QA pass (or QA sign-off if separate QA exists)
- [ ] Documentation updated (help center, internal runbook, API docs, as applicable)
- [ ] Feature flag wired (if behind a flag) or release-notes entry drafted
- [ ] Analytics or telemetry events instrumented (so we can measure the outcome)
- [ ] Accessibility check pass (WCAG AA for user-facing UI)
- [ ] Product owner has accepted the story

### DoD anti-