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:

1. Display specific failures with remediation guidance
2. Do not proceed to peer review or handoff
3. Return to user with action items
4. 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:

1. Write UAT test from scenario: Translate first Gherkin scenario to executable test. Run -> RED (correct).
2. Build outside-in: What does UAT need? Integration -> RED -> code -> GREEN. What does integration need? Unit -> RED -> code -> GREEN.
3. Refactor: All tests green, safe to refactor.
4. 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:

Business Risks: market changes | regulatory changes | stakeholder availability | budget/timeline constraints Technical Risks: integration complexity | technology uncertainty | data migration | performance/security unknowns Project Risks: resource availability | scope creep potential | communication challenges | testing coverage gaps

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