---

name: manage-backlog locale: caveman source_locale: en source_commit: 82c77053 fence_basis_commit: 82c77053 translator: "Julius Brussee homage — caveman" translation_date: "2026-04-24" description: > Create and maintain a product or project backlog with prioritized items, acceptance criteria, and estimates. Covers user story writing, MoSCoW prioritization, backlog grooming, item splitting, and status tracking. Use when starting a new project and converting scope into actionable items, during ongoing grooming before sprint planning, re-prioritizing after stakeholder feedback or scope changes, or splitting oversized items into implementable pieces. license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: project-management complexity: intermediate language: multi tags: project-management, backlog, user-stories, prioritization, grooming, moscow

Manage Product Backlog

Create, prioritize, maintain backlog of work items serving as single source of truth for what needs to be done. Applies to both agile and classic project methodologies.

When Use

• Starting new project, converting scope into actionable items
• Ongoing backlog grooming before sprint planning
• Re-prioritizing work after stakeholder feedback or scope changes
• Splitting oversized items into implementable pieces
• Reviewing and archiving completed or cancelled items

Inputs

• Required: Project scope (from charter, WBS, or stakeholder input)
• Optional: Existing backlog file (BACKLOG.md) to update
• Optional: Prioritization framework preference (MoSCoW, value/effort, WSJF)
• Optional: Estimation scale (story points, T-shirt sizes, person-days)
• Optional: Sprint or iteration feedback requiring backlog updates

Steps

Step 1: Create or Load Backlog Structure

No backlog exists? Create BACKLOG.md with standard columns. Exists? Read and validate structure.

# Product Backlog: [Project Name]
## Last Updated: [YYYY-MM-DD]

### Summary
- **Total Items**: [N]
- **Ready for Sprint**: [N]
- **In Progress**: [N]
- **Done**: [N]
- **Cancelled**: [N]

### Backlog Items
| ID | Title | Type | Priority | Estimate | Status | Sprint |
|----|-------|------|----------|----------|--------|--------|
| B-001 | [Title] | Feature | Must | 5 | Ready | — |
| B-002 | [Title] | Bug | Should | 2 | Ready | — |
| B-003 | [Title] | Task | Could | 3 | New | — |

### Item Details

#### B-001: [Title]
- **Type**: Feature | Bug | Task | Spike | Tech Debt
- **Priority**: Must | Should | Could | Won't
- **Estimate**: [Points or size]
- **Status**: New | Ready | In Progress | Done | Cancelled
- **Acceptance Criteria**:
  - [ ] [Criterion 1]
  - [ ] [Criterion 2]
- **Notes**: [Context, links, dependencies]

#### B-002: [Title]
...

Got: BACKLOG.md exists with valid structure and summary statistics.

If fail: File malformed? Restructure preserving existing item data.

Step 2: Write or Refine Items

For each new item, write as user story or requirement:

• User story format: "As a [role], I want [capability] so that [benefit]"
• Requirement format: "[System/Component] shall [behavior] when [condition]"

Each item must have:

• Unique ID (B-NNN, incrementing)
• Clear title (imperative verb form)
• Type classification
• At least 2 acceptance criteria (testable, binary pass/fail)

Example:

#### B-005: Enable User Login with OAuth
- **Type**: Feature
- **Priority**: Must
- **Estimate**: 5
- **Status**: Ready
- **Acceptance Criteria**:
  - [ ] User can log in using GitHub OAuth
  - [ ] User session persists for 24 hours
  - [ ] Failed login shows clear error message
- **Notes**: Requires OAuth app registration in GitHub

Got: All items have titles, types, acceptance criteria.

If fail: Items without acceptance criteria marked Status: New (not Ready). Cannot enter sprint.

Step 3: Prioritize Using MoSCoW or Value/Effort

Apply chosen prioritization framework:

MoSCoW (default):

• Must: Project fails without this. Non-negotiable.
• Should: Important but project can succeed without it. Include if capacity allows.
• Could: Nice to have. Include only if no impact on Must/Should items.
• Won't: Explicitly excluded from current scope. Documented for future consideration.

Value/Effort Matrix (alternative):

	Low Effort	High Effort
High Value	Do First (Quick Wins)	Do Second (Big Bets)
Low Value	Do Third (Fill-ins)	Don't Do (Money Pits)

Sort backlog table: Must items first (by value within Must), then Should, then Could.

Got: Every item has priority. Backlog sorted by priority.

If fail: Stakeholders disagree on priorities? Escalate Must vs Should decisions to project sponsor.

Step 4: Groom — Split, Estimate, Refine

Review items for sprint-readiness. For each item:

1. Split if estimate > 8 points (or > 1 week effort): decompose into 2-4 smaller items
2. Estimate using project's chosen scale
3. Refine vague acceptance criteria into testable conditions
4. Mark Ready when item has title, acceptance criteria, estimate, no blockers

Document splitting:

**Split**: B-003 split into B-003a, B-003b, B-003c (original archived)

#### B-003a: Set Up Database Schema
- **Type**: Task
- **Priority**: Must
- **Estimate**: 3
- **Status**: Ready
- **Acceptance Criteria**:
  - [ ] Users table created with email, name fields
  - [ ] Migrations run successfully on dev environment

#### B-003b: Implement User CRUD Operations
- **Type**: Task
- **Priority**: Must
- **Estimate**: 5
- **Status**: Ready
- **Acceptance Criteria**:
  - [ ] Create user endpoint returns 201 with user object
  - [ ] Update user endpoint validates required fields

Got: All Must and Should items in Ready status.

If fail: Items that can't be estimated need Spike (time-boxed research task) added to backlog.

Step 5: Update Summary and Archive

Update summary statistics. Move Done and Cancelled items to archive section:

### Archive
| ID | Title | Status | Sprint | Completed |
|----|-------|--------|--------|-----------|
| B-001 | Enable User Login with OAuth | Done | S-003 | 2025-03-15 |
| B-004 | Add Dark Mode Theme | Cancelled | — | 2025-03-10 |

Update summary by counting items in each status:

# Count Ready items
grep "| Ready |" BACKLOG.md | wc -l

# Count In Progress items
grep "| In Progress |" BACKLOG.md | wc -l

# Count Done items
grep "| Done |" BACKLOG.md | wc -l

Got: Summary statistics match actual item counts. Archive section contains all closed items.

If fail: Counts don't match? Recount by grepping Status values, update summary manually.

Checks

• BACKLOG.md exists with standard structure
• Every item has unique ID, title, type, priority, status
• All Must and Should items have acceptance criteria
• Items sorted by priority (Must first, then Should, then Could)
• No item estimated at > 8 points without being split
• Summary statistics accurate
• Done/Cancelled items archived

Pitfalls

• No acceptance criteria: Items without criteria can't be verified as done. Every item needs at least 2 testable criteria.
• Everything is Must priority: >50% of items Must? Priorities not real. Force-rank within Must.
• Zombie items: Items sitting in backlog for months without progress should be re-evaluated or cancelled.
• Estimates without context: Story points relative — team must have reference item (e.g., "B-001 is our 3-point reference").
• Splitting creates fragments: When splitting, ensure each child item independently deliverable and valuable.
• Backlog as dumping ground: Backlog not wish list. Regularly prune items no longer aligning with project goals.
• Missing dependencies: Note blocking items in Notes field. Blocked item should not be marked Ready.

See Also

• draft-project-charter — charter scope feeds initial backlog creation
• create-work-breakdown-structure — WBS work packages can become backlog items
• plan-sprint — sprint planning selects from top of backlog
• generate-status-report — backlog burn-down feeds status reports
• conduct-retrospective — retrospective improvement items feed back into backlog