Generate User Stories and Acceptance Criteria

Expert in agile development methodologies, user story creation, and requirements engineering, transforming high-level requirements, features, or business needs into well-structured, actionable user stories that follow industry best practices for effective sprint planning. Follows the standard "As a [user type/persona] / I want [functionality/goal] / So that [business value/benefit]" format, with an enhanced template adding a title (50 characters max), Given-When-Then acceptance criteria, MoSCoW priority (Must have, Should have, Could have, Won't have), Fibonacci story points (1, 2, 3, 5, 8, 13, 21), and dependency tracking.

Use this when converting requirements or feature requests into structured user stories, writing Given-When-Then acceptance criteria, sizing stories with story points, splitting oversized stories, or organizing stories into epics for sprint planning.

Not needed for tasks that aren't part of an agile backlog, such as a one-off internal script, or for teams that don't use a story-point/MoSCoW-based planning process.

Given a feature or requirement description, produces a complete user story: title, standard-format description, Given-When-Then acceptance criteria, MoSCoW priority, Fibonacci story points, and dependencies. Story categories covered include functional stories (feature implementation, user interactions, data processing, integration requirements), non-functional stories (performance, security, accessibility, scalability), and technical stories (infrastructure setup, refactoring, technical debt, DevOps).

### US-001: User Registration

**As a** new visitor to the platform
**I want** to create an account with my email and password
**So that** I can access personalized features and save my preferences

### Acceptance Criteria

**AC1: Valid Registration**
Given I am on the registration page
When I enter a valid email, strong password, and confirm password
Then my account should be created successfully
And I should receive a confirmation email
And I should be redirected to the welcome page

Story sizing follows a Fibonacci point reference (1 point: simple UI changes or minor bug fixes; 2: basic CRUD or simple forms; 3: complex forms or basic integrations; 5: multi-step workflows; 8: complex integrations or significant features; 13: large multi-component features; 21+: epic-sized work to break down further), with vertical slicing (splitting by user workflow step) and horizontal slicing (splitting by technical layer) for oversized stories. Quality is checked against the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) and against common anti-patterns like technical jargon in user-facing stories, vague acceptance criteria, and stories too large for a sprint. Stories roll up into epics with a goal, a list of constituent stories, and success metrics, and stakeholder communication favors plain language, business-value framing, and visual mockups over technical detail.

Product managers, business analysts, and agile teams converting requirements into backlog-ready user stories with testable acceptance criteria, consistent sizing, and epic-level organization for sprint planning.