HKSM

Create User Stories is the process of turning customer needs into small, value-focused backlog items that clearly state who wants what and why, along with testable acceptance criteria.

Purpose & When to Use

The purpose of Create User Stories is to capture customer and business needs as concise, value-oriented items in the Product Backlog. This process is used early in the project after vision, themes, and epics are known, and continues throughout the project during ongoing backlog refinement as new insights, risks, and stakeholder requests emerge.

Use it whenever the Product Owner and stakeholders need to express a requirement in a way the team can later estimate, split, and implement within a Sprint.

Mini Flow (How It’s Done)

• Prepare context: bring the Product Vision, epics/themes, personas, constraints, and any regulatory or nonfunctional needs.
• Facilitate a story-writing workshop with Product Owner, customers/users, SMEs, and the Scrum Team.
• Write stories in plain language to express value: As a [persona], I want [capability], so that [benefit/outcome].
• Add acceptance criteria as clear, testable conditions (e.g., bullet points or Given-When-Then).
• Capture nonfunctional requirements, assumptions, and constraints relevant to the story.
• Split large items (epics) into thin, end-to-end slices that deliver user-visible value.
• Tag and link: epic/theme, persona, business objective, dependencies, and risk notes.
• Check readiness (e.g., INVEST) so the story can move forward to estimation in a later process.
• Place stories in the Product Backlog; prioritization and estimation happen in subsequent processes.

Quality & Acceptance Checklist

• Value-focused: clearly states the user/role, capability, and benefit.
• Testable: has specific acceptance criteria that can be verified.
• Small and sliceable: can be completed within a Sprint after estimation; not a broad epic.
• Independent and negotiable: avoids tight coupling with other stories where possible.
• Clear, simple language: avoids design or technical prescriptions unless essential.
• NFRs considered: performance, security, usability, accessibility, and compliance aspects noted.
• Linked context: mapped to epic/theme, persona, and business objective.
• Ready to estimate: information is sufficient for the team to size later (estimation itself is not done here).

Common Mistakes & Exam Traps

• Confusing acceptance criteria with Definition of Done: criteria are specific to the story; DoD is a general quality bar for all work.
• Estimating now: assigning story points belongs to the estimation process, not during initial creation.
• Writing tasks as stories: technical steps (e.g., "build API endpoint") without user value should be tasks under a story, or reframed as enablers with clear outcome.
• Solution-first wording: locking in design prematurely reduces flexibility; focus on outcomes.
• Stories too big: carrying epics into a Sprint leads to rollover and unclear acceptance.
• Ignoring NFRs: missing performance/security requirements causes rework later.
• No persona or business benefit: weak traceability to value makes prioritization difficult.

PMP/SCRUM Example Question

The team is running a Create User Stories workshop. Which action best aligns with this process?

1. Assign story points to each new story to speed up release planning.
2. Create the Sprint Task Board and break stories into tasks.
3. Capture acceptance criteria for each story to make them testable.
4. Lock the scope baseline to prevent further changes to the backlog.

Correct Answer: C — Acceptance criteria make stories testable and ready for later estimation and planning. Story points (A) and task breakdown (B) occur in later processes, and locking scope (D) conflicts with adaptive backlog management.