Draft user stories and verifiable acceptance criteria
Autor: AILesson9 min de preparaciónProbado con:ChatGPTRevisado el: 2026-08-28
Respuesta rápida
Translate confirmed user and business needs into scoped stories and observable behavior without inventing product decisions. Proporciona: Need and evidence, Approved product decisions, Delivery and validation. Resultado esperado: A story set with evidence, boundaries, scenarios, acceptance criteria, nonfunctional needs, dependencies, and open decisions.
1
Añade tu contexto
Tu texto permanece en este navegador. AILesson Prompts no lo envía a un modelo ni a un servidor.
2
Tu prompt
Los campos sin rellenar permanecen visibles como marcadores de posición, para que puedas copiar y editar el 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.
Privado de forma predeterminadaLa preparación del prompt se realiza localmente en tu navegador. Evita introducir información confidencial en cualquier servicio de IA, a menos que tu organización lo permita.
De la entrada al resultado
Un ejemplo completo
Mira cómo un contexto concreto convierte esta receta en un resultado que puedes usar
Entrada real
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.
Ejemplo de salida
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.
Por qué funciona
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.
Comprueba el resultado
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?
Úsalo con confianza
Preguntas frecuentes
Respuestas prácticas sobre cuándo usar esta receta, qué debes proporcionar y en qué casos la revisión humana sigue siendo importante
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.
Pasa de entender la IA a poner manos a la obra. Practica cómo dar instrucciones, revisar y mejorar resultados con lecciones interactivas para el trabajo y la vida cotidiana.
ChatGPT
