Nw Leanux Methodology

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", "[email protected]"
• Problem: Lacks real-world context, harder to validate
• Bad: "Given user123 logs in with password123"
• Good: "Given Maria Santos ([email protected]) 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:

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