LeanUX Backlog Management Methodology

"A backlog is not a todo list. It's a collection of validated hypotheses waiting to become working software."

Story States

State	Meaning	Entry Criteria
Draft	Idea captured, not validated	Has problem statement
Ready	Validated, has UAT, ready to build	All DoR items complete
In Progress	Actively being built	UAT test written (RED)
In Review	Code complete, awaiting review	All tests green
Done	Merged, deployed, validated	UAT passes in production
Blocked	Cannot proceed	Blocker documented

Story Sizing Criteria

Right-Sized

Completable in 1-3 days | 3-7 UAT scenarios | Delivers demonstrable value | Explainable in 2 minutes

Oversized Indicators

7 UAT scenarios | >3 days effort | Multiple distinct user outcomes | Cannot demonstrate in single session

Splitting Strategy

Split by user outcome, not technical layer. Each resulting story delivers independently demonstrable value.

Example: "User Management" (20 scenarios) splits into:

"Quick Login" (5 scenarios) -- returning customer on trusted device
"New Registration" (4 scenarios) -- first-time customer sign-up
"Password Recovery" (3 scenarios) -- customer who forgot credentials
"Profile Settings" (4 scenarios) -- customer updating preferences

Definition of Ready (DoR) - Hard Gate

Stories pass ALL 8 items before proceeding to DESIGN wave.

Checklist with Pass/Fail Examples

1. Problem statement clear and in domain language

Pass: "Maria wastes 30 seconds typing credentials on every visit"
Fail: "Users need authentication"

2. User/persona identified with specific characteristics

Pass: "Returning customer (2+ orders) on trusted personal device"
Fail: "User" or "Customer"

3. At least 3 domain examples with real data

Pass: "Maria on her MacBook, last login 5 days ago, goes directly to dashboard"
Fail: "User logs in successfully"

4. UAT scenarios in Given/When/Then (3-7 scenarios)

Pass: "Given Maria authenticated 5 days ago on 'MacBook-Home'..."
Fail: "Test login functionality"

5. Acceptance criteria derived from UAT

Pass: "Sessions older than 30 days require re-authentication"
Fail: "System should work correctly"

6. Story right-sized (1-3 days, 3-7 scenarios)

Pass: "2 days effort, 5 scenarios, single demo-able feature"
Fail: "Epic with 20 scenarios"

7. Technical notes identify constraints

Pass: "Requires JWT token storage, GDPR cookie consent"
Fail: "No technical considerations"

8. Dependencies resolved or tracked

Pass: "Depends on US-041 (completed) and Auth service API (available)"
Fail: "Unspecified external dependencies"

Validation Output Format

## Definition of Ready Validation

### Story: {story-id}

| DoR Item | Status | Evidence/Issue |
|----------|--------|----------------|
| Problem statement clear | PASS/FAIL | {evidence or issue} |
| User/persona identified | PASS/FAIL | {evidence or issue} |
| 3+ domain examples | PASS/FAIL | {evidence or issue} |
| UAT scenarios (3-7) | PASS/FAIL | {evidence or issue} |
| AC derived from UAT | PASS/FAIL | {evidence or issue} |
| Right-sized | PASS/FAIL | {evidence or issue} |
| Technical notes | PASS/FAIL | {evidence or issue} |
| Dependencies tracked | PASS/FAIL | {evidence or issue} |

### DoR Status: PASSED / BLOCKED

Failure Recovery

When DoR fails:

Display specific failures with remediation guidance
Do not proceed to peer review or handoff
Return to user with action items
Re-validate after fixes applied

Definition of Done (DoD) - Completion Criteria

DoD validation owned by acceptance-designer during DISTILL->DELIVER transition. Product-owner defines checklist, acceptance-designer enforces.

Checklist:

All UAT scenarios pass (green) | All supporting tests pass (unit, integration, component)
Code refactored, no obvious debt | Code reviewed and approved
Merged to main branch | Deployed to staging/production
Story can be demoed to user

Anti-Pattern Detection and Remediation

Implement-X

Signal: Task starts with "Implement X" or "Add X"
Problem: No user context, technical focus, vague completion
Bad: "Implement user authentication"
Good: "Returning Customer Quick Login -- Maria wastes 30 seconds..."
Fix: Start with user pain point, rewrite as problem statement

Generic Data

Signal: Examples use "user123", "test@test.com"
Problem: Lacks real-world context, harder to validate
Bad: "Given user123 logs in with password123"
Good: "Given Maria Santos (maria.santos@email.com) on her MacBook"
Fix: Replace all generic data with real names and realistic values

Technical Acceptance Criteria

Signal: AC describes implementation ("Use JWT tokens")
Problem: Prescribes solution, not testable outcome
Bad: "Use JWT tokens for session management"
Good: "Session persists for 30 days on trusted device"
Fix: Focus on observable user outcome, move tech choices to DESIGN

Oversized Stories

Signal: >7 scenarios or >3 days effort
Problem: Too large to track, deliver, or demo meaningfully
Bad: "Complete user management (20 scenarios)"
Good: "Quick Login (5 scenarios), Password Reset (4 scenarios)"
Fix: Split into focused stories by user outcome

No Examples

Signal: Abstract requirements without concrete examples
Problem: Ambiguous, untestable, different interpretations
Bad: "Users should be able to manage their settings"
Good: "Maria changes notification frequency from daily to weekly"
Fix: Add 3+ concrete narratives with real data

Tests After Code

Signal: Tests written after implementation
Problem: Technical debt, test coverage gaps
Fix: UAT scenarios defined in DISCUSS wave, tests written RED first in DELIVER wave

UAT-First Development Flow

Flow from Ready story to Done story follows double-loop TDD:

Write UAT test from scenario: Translate first Gherkin scenario to executable test. Run -> RED (correct).
Build outside-in: What does UAT need? Integration -> RED -> code -> GREEN. What does integration need? Unit -> RED -> code -> GREEN.
Refactor: All tests green, safe to refactor.
Next scenario: Repeat for each UAT scenario. All scenarios green -> Story is DONE.

Story Prioritization

MoSCoW Classification

Category	Meaning	Guideline
Must Have	Required for MVP	Without this, release has no value
Should Have	Important for full product value	Significant value, workaround exists
Could Have	Nice-to-have for enhanced experience	Desirable if time/budget allows
Won't Have	Deferred to future releases	Acknowledged, explicitly out of scope

Assign MoSCoW during Phase 2 (CRAFT) when multiple stories emerge from same requirements conversation.

Value/Effort Matrix

	Low Effort	High Effort
High Value	Quick wins -- do first	Strategic investments -- plan carefully
Low Value	Fill-ins -- do if time allows	Eliminate or defer

Quick wins build momentum and stakeholder confidence. Strategic investments need baseline measurement and roadmap planning (see jtbd-workflow-selection skill).

Risk Identification Checklist

During Phase 4 (HANDOFF), include brief risk assessment. Categorize:

For each risk: probability (low/medium/high) | impact (low/medium/high) | mitigation approach (avoid, mitigate, transfer, accept). Detailed risk management belongs to downstream waves -- product-owner surfaces risks, does not manage them.

Wave Handoff Package

When handing off to DESIGN wave (solution-architect), include:

Structured requirements document with business context
User stories with detailed acceptance criteria
Stakeholder analysis and engagement plan
Business rules and domain model
Risk assessment with categorized risks (see checklist above)
Non-functional requirements and quality attributes
DoR validation results (all PASSED)
Peer review approval

nw-leanux-methodology