product-backlog

Read the full spec first, then group requirements into epics by business value, write user stories in the 'as a / I want / so that' format, and link every story back to its source FR or NFR. This Skill enforces that traceability automatically and flags stories with no spec origin as out-of-scope proposals.

Write each criterion as Given (initial state), When (action), Then (verifiable outcome). Cover three cases per story: a happy path, an error path, and a boundary or business-rule case. A story with only one acceptance criterion usually means edge cases were not considered.

MoSCoW classifies stories as Must, Should, Could, or Won't for this release. Must items should stay under roughly 60 percent of total effort, and every priority needs a short written justification. If everything is Must, the backlog has not actually been prioritized.

Split any story estimated at 13 points or more, since it is too large or unclear for one sprint. Split by workflow steps, business rules, CRUD operations, or happy path versus error cases — never by technical layer like frontend versus backend.

Definition of Ready gates a story entering a sprint: complete acceptance criteria, estimate under 13 points, cleared dependencies, and no blocking open questions. Definition of Done gates closing it: all criteria pass, tests exist and pass, code review is complete, and documentation is updated.