Draft user stories and verifiable acceptance criteria
Author: AILesson9 min setupTested with:ChatGPTReviewed: 2026-08-28
Quick answer
Translate confirmed user and business needs into scoped stories and observable behavior without inventing product decisions. Provide: Need and evidence, Approved product decisions, Delivery and validation. Expected result: A story set with evidence, boundaries, scenarios, acceptance criteria, nonfunctional needs, dependencies, and open decisions.
1
Add your context
Your text stays in this browser. AILesson Prompts does not send it to a model or server.
2
Your prompt
Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt
Draft user stories and verifiable acceptance criteria from confirmed needs and approved product decisions.
User situations, roles, goals, behaviors, evidence, business reason, research limits, and negative cases:
[evidence]
Chosen scope, workflow, states, rules, permissions, data, integrations, platforms, nonfunctional needs, and exclusions:
[product]
Release, teams, dependencies, analytics, accessibility, privacy, security, environments, done, and open decisions:
[delivery]
Separate evidence-backed need, product hypothesis, approved decision, implementation assumption, and unresolved choice. Split stories by actor and independent outcome, not technical layer or oversized epic. Use the user-story sentence only as a summary; add context, evidence locator, in/out scope, preconditions, trigger, main flow, alternate and error flows, permissions, data handling, business rules, and dependencies. Write acceptance criteria as observable Given/When/Then scenarios or equivalent, covering happy path, boundaries, missing/invalid data, denied permission, concurrency or repeat action, recovery, accessibility, privacy/security, analytics, and compatibility only where approved. Do not invent UI copy, state, threshold, integration, role, data retention, performance target, notification, error behavior, or metric. Mark unresolved decisions as questions that block affected criteria. Keep solution ideas out when no solution has been approved. End with traceability from evidence to story to criterion and a testability, scope, conflict, and readiness audit.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.
From input to outcome
A worked example
See how concrete context turns this recipe into a usable result
Actual input
Need and evidence
Research evidence UX sessions P01/P03: when a Ready handoff lacks visible acceptance responsibility, owners searched across people or missed an expected mention. Negative cases P02/P04 show some waits are intentional or for known approval. Approved business reason: reduce avoidable uncertainty without adding notification burden. Evidence does not establish prevalence or demand for email.
Approved product decisions
Approved discovery-stage solution for prototype: show an optional accepter field on a handoff; only requester or workspace coordinator can set/change it; owner and accepter can view it. Existing states Draft, Active, Ready, Accepted remain. If no accepter is set, display state as unassigned using approved design token, exact UI copy pending. No email or push notification. Accepter must be an active workspace member. Audit log records actor, old/new accepter, and time. Supported web app only. No retention change approved.
Delivery and validation
Prototype release for usability test, not production. Design owns copy; Engineering validates membership and audit event; Accessibility requires keyboard operation, programmatic label, and non-color-only status. Privacy review complete for using existing member IDs. Analytics event names and performance threshold unresolved. Definition of done: reviewed design, working prototype, unit tests, accessibility check, research script. Do not write production SLA.
Example output
Story 1 — set acceptance responsibility
As a requester or workspace coordinator, I need to assign an active workspace member as accepter for a handoff so the people involved can see who is authorized to accept it. Evidence: P01/P03; scope is a prototype hypothesis, not validated demand.
Acceptance criteria
• Given a web handoff and an eligible requester/coordinator, when they choose an active workspace member and confirm, then that member is stored as accepter and is visible to requester, owner, and accepter. Exact confirmation UI is unresolved and must come from approved design.
• Given a person who is not requester/coordinator, when they view the handoff, then they can see the accepter but cannot change it. The approved denied-action behavior is missing and blocks its exact criterion.
• Given an inactive or non-member account, when it is supplied as accepter, then the system does not save it. Exact error copy is pending Design; do not invent it.
• Given an existing accepter, when an authorized actor changes or clears it, then audit data records actor, old value, new value, and time. Retention follows existing policy; no new period is specified.
Story 2 — understand an unassigned handoff
As an owner or requester, I need to perceive when no accepter is assigned so I can decide whether to identify one or intentionally continue without one. This wording preserves P02/P04 negative cases and does not imply every wait is an error.
Criteria: when accepter is absent, the approved unassigned visual token appears; status remains Ready rather than creating a new state. The indicator has a programmatic label and is distinguishable without color. Keyboard users can reach the field and perform every permitted action in logical order. Exact visible and accessible copy is pending Design and blocks final text assertions.
Out of scope: email/push, production rollout, new retention, prevalence or outcome claim, automatic assignment, production SLA. Analytics criterion remains blocked until event names and purpose are approved. Traceability links P01/P03 to visibility stories, while P02/P04 require optional assignment and no automatic alert.
Why this works
1
Traceability prevents a concise story sentence from hiding unsupported product behavior.
2
Boundary and failure scenarios make acceptance criteria useful beyond a demo happy path.
Check the result
Does every story map to confirmed need evidence and an approved product decision?
Are criteria observable, unambiguous, and free of invented UI or thresholds?
Are boundaries, permissions, errors, recovery, accessibility, privacy, and open decisions covered where relevant?
Use it with confidence
Frequently asked questions
Practical answers about when to use this recipe, what to provide, and where human review still matters
What should I prepare before using “Draft user stories and verifiable acceptance criteria”?
For “Draft user stories and verifiable acceptance criteria,” prepare Need and evidence, Approved product decisions, and Delivery and validation. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.
When is the “Draft user stories and verifiable acceptance criteria” result not ready to use?
The result is not ready if it does not yet deliver the stated outcome—A story set with evidence, boundaries, scenarios, acceptance criteria, nonfunctional needs, dependencies, and open decisions—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.
Which AI tools have recorded tests for “Draft user stories and verifiable acceptance criteria”?
The published test record for “Draft user stories and verifiable acceptance criteria” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.
ChatGPT