Backlog Estimation Assistant

Estimation is where backlogs earn trust. This skill assigns each story three things — effort, priority, and complexity — using consistent, defensible rules so the numbers mean the same thing across the whole backlog.

Instructions

Step 1: Take the epics and stories as input

Ideally the JSON from user-story-generator. Estimate stories, not epics; an epic's size is the sum of its stories.

Step 2: Assign story points (Fibonacci)

Use the scale 1, 2, 3, 5, 8, 13, 21. Points are relative effort, blending complexity, uncertainty, and volume of work — not hours. Anchor the backlog: pick one small, well-understood story as your "3" and size everything else against it. A story at 13+ is a signal it should probably be split. See references/estimation-guide.md for the reference scale with examples.

Step 3: Assign priority (MoSCoW → P-level)

Classify each story Must / Should / Could / Won't-this-release, then map:

• Must → P0 — the release fails without it.
• Should → P1 — important, but the release can ship without it if forced.
• Could → P2 — nice to have.
• Won't (this release) — drop from this backlog; note it as future scope.

Step 4: Rate complexity

Low / Medium / High, based on technical risk and unknowns — distinct from effort. A story can be small (2 points) but High complexity (for example, a tricky third-party integration with little documentation). Complexity flags where the team needs its most experienced people or a spike.

Step 5: Justify every number

One short line per story explaining the point value and any High complexity. Unjustified estimates get overridden in planning; justified ones start a useful conversation.

Output format

Present a backlog table AND augment each story object with three fields:

{
  "id": "US-01",
  "story_points": 5,
  "priority": "P0",
  "complexity": "Medium",
  "justification": "Standard reorder flow; medium because it touches the cart and stock check."
}

Also report the totals: total story points, points per epic, and the count of P0 stories — these drive the first sprint plan.

Example

Troubleshooting

• Everything is a Must / P0. Force ranking: if the client had to cut one story to hit the deadline, which goes first? Repeat until priorities spread out.
• A story is 13+ points. Recommend splitting it (send it back to user-story-generator) rather than committing a giant story to a sprint.
• Effort and complexity keep collapsing into one number. Re-read Step 4: effort is "how much work," complexity is "how likely we are to be wrong." Keep them separate.