Redacta historias de usuario y criterios de aceptación verificables
Autor: AILesson9 min de preparaciónProbado con:ChatGPTRevisado el: 2026-08-28
Respuesta rápida
Convierte las necesidades confirmadas de usuarios y negocio en historias delimitadas y comportamientos observables sin inventar decisiones de producto. Proporciona: Necesidad y pruebas, Decisiones de producto aprobadas, Entrega y validación. Resultado esperado: Un conjunto de historias con pruebas, límites, situaciones, criterios de aceptación, necesidades no funcionales, dependencias y decisiones pendientes.
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
Redacta historias de usuario y criterios de aceptación verificables a partir de necesidades confirmadas y decisiones de producto aprobadas.
Situaciones, funciones, objetivos y comportamientos de usuarios, pruebas, motivo comercial, límites de la investigación y casos negativos:
[evidence]
Alcance, flujo de trabajo, estados, reglas, permisos, datos, integraciones, plataformas, necesidades no funcionales y exclusiones elegidos:
[product]
Versión, equipos, dependencias, analítica, accesibilidad, privacidad, seguridad, entornos, definición de terminado y decisiones pendientes:
[delivery]
Separa la necesidad respaldada por pruebas, la hipótesis de producto, la decisión aprobada, el supuesto de implementación y la opción pendiente. Divide las historias por persona actora y resultado independiente, no por capa técnica ni como una epopeya sobredimensionada. Usa la frase de historia de usuario únicamente como resumen; añade contexto, ubicación de las pruebas, elementos dentro y fuera del alcance, condiciones previas, desencadenante, flujo principal, flujos alternativos y de error, permisos, tratamiento de datos, reglas de negocio y dependencias. Redacta los criterios de aceptación como situaciones observables Dado/Cuando/Entonces o equivalentes, cubriendo la vía correcta, los límites, los datos ausentes o no válidos, el permiso denegado, la acción simultánea o repetida, la recuperación, la accesibilidad, la privacidad y seguridad, la analítica y la compatibilidad solo cuando estén aprobadas. No inventes textos de interfaz, estados, umbrales, integraciones, funciones, conservación de datos, objetivos de rendimiento, notificaciones, comportamientos ante errores ni métricas. Señala las decisiones pendientes como preguntas que bloquean los criterios afectados. No incluyas ideas de solución cuando no haya una solución aprobada. Termina con la trazabilidad desde las pruebas hasta la historia y el criterio, y una auditoría de capacidad de prueba, alcance, conflictos y preparación.
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
Necesidad y pruebas
Pruebas de investigación de las sesiones de experiencia de usuario P01/P03: cuando un traspaso en estado Ready carecía de una responsabilidad de aceptación visible, las personas responsables buscaron entre varias personas o no vieron una mención esperada. Los casos negativos P02/P04 muestran que algunas esperas son intencionadas o corresponden a una aprobación conocida. Motivo comercial aprobado: reducir la incertidumbre evitable sin añadir carga de notificaciones. Las pruebas no establecen la prevalencia ni una demanda de correo electrónico.
Decisiones de producto aprobadas
Solución aprobada en fase de descubrimiento para un prototipo: mostrar un campo opcional de accepter en un traspaso; solo requester o workspace coordinator pueden establecerlo o cambiarlo; owner y accepter pueden verlo. Se mantienen los estados existentes Draft, Active, Ready y Accepted. Si no se establece accepter, se muestra el estado sin asignar mediante el design token aprobado; el texto exacto de la interfaz está pendiente. Sin notificaciones por correo electrónico ni push. Accepter debe ser un active workspace member. El audit log registra la persona actora, el accepter anterior y nuevo, y la hora. Solo se admite la aplicación web. No se ha aprobado ningún cambio en la conservación.
Entrega y validación
Versión prototipo para una prueba de usabilidad, no para producción. Diseño es responsable del texto; Ingeniería valida la pertenencia y el audit event; Accesibilidad exige operación mediante teclado, una etiqueta programática y un estado que no dependa únicamente del color. Se ha completado la revisión de privacidad para usar los member IDs existentes. Los nombres de analytics events y el umbral de rendimiento están pendientes. Definición de terminado: diseño revisado, prototipo funcional, pruebas unitarias, comprobación de accesibilidad y guion de investigación. No redactes un SLA de producción.
Ejemplo de salida
Historia 1 — establecer la responsabilidad de aceptación
Como requester o workspace coordinator, necesito asignar un active workspace member como accepter de un traspaso para que las personas implicadas puedan ver quién está autorizado para aceptarlo. Pruebas: P01/P03; el alcance es una hipótesis de prototipo, no una demanda validada.
Criterios de aceptación
• Dado un traspaso web y un requester o coordinator autorizado, cuando selecciona un active workspace member y confirma, entonces esa persona queda guardada como accepter y es visible para requester, owner y accepter. La interfaz exacta de confirmación está pendiente y debe proceder del diseño aprobado.
• Dada una persona que no es requester ni coordinator, cuando consulta el traspaso, entonces puede ver el accepter, pero no cambiarlo. Falta el comportamiento aprobado para la acción denegada, lo que bloquea su criterio exacto.
• Dada una cuenta inactiva o ajena al espacio de trabajo, cuando se proporciona como accepter, entonces el sistema no la guarda. El texto exacto del error está pendiente de Diseño; no lo inventes.
• Dado un accepter existente, cuando una persona actora autorizada lo cambia o lo elimina, entonces los datos de auditoría registran la persona actora, el valor anterior, el valor nuevo y la hora. La conservación sigue la política vigente; no se especifica ningún periodo nuevo.
Historia 2 — entender un traspaso sin asignar
Como owner o requester, necesito percibir cuándo no hay ningún accepter asignado para poder decidir si identifico uno o continúo intencionadamente sin él. Esta redacción conserva los casos negativos P02/P04 y no implica que toda espera sea un error.
Criterios: cuando no hay accepter, aparece el visual token aprobado de elemento sin asignar; el estado sigue siendo Ready en vez de crear uno nuevo. El indicador cuenta con una etiqueta programática y puede distinguirse sin color. Quienes usan el teclado pueden llegar al campo y realizar todas las acciones permitidas en un orden lógico. Los textos visible y accesible exactos están pendientes de Diseño y bloquean las afirmaciones definitivas sobre el texto.
Fuera del alcance: correo electrónico y push, lanzamiento en producción, nueva conservación, afirmaciones sobre prevalencia o resultados, asignación automática y SLA de producción. El criterio de analítica sigue bloqueado hasta que se aprueben los nombres y el propósito de los eventos. La trazabilidad vincula P01/P03 con las historias de visibilidad, mientras que P02/P04 exigen asignación opcional y ausencia de avisos automáticos.
Por qué funciona
1
La trazabilidad evita que una frase concisa de historia oculte un comportamiento de producto sin respaldo.
2
Las situaciones límite y de fallo hacen que los criterios de aceptación sean útiles más allá de la vía correcta de una demostración.
Comprueba el resultado
¿Se corresponde cada historia con pruebas de una necesidad confirmada y una decisión de producto aprobada?
¿Son los criterios observables, inequívocos y libres de interfaces o umbrales inventados?
¿Se cubren, cuando proceda, los límites, permisos, errores, recuperación, accesibilidad, privacidad y decisiones pendientes?
Ú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
¿Qué debo preparar antes de usar «Redacta historias de usuario y criterios de aceptación verificables»?
Para usar «Redacta historias de usuario y criterios de aceptación verificables», prepara la necesidad y las pruebas, las decisiones de producto aprobadas, y la entrega y validación. Sustituye los marcadores solo con información que puedas verificar. Si desconoces algún detalle, conserva explícitamente esa incertidumbre en vez de pedir al modelo que lo deduzca.
¿Cuándo no está listo para usarse el resultado de «Redacta historias de usuario y criterios de aceptación verificables»?
El resultado no está listo si aún no ofrece, a partir de las pruebas proporcionadas, el resultado indicado —un conjunto de historias con pruebas, límites, situaciones, criterios de aceptación, necesidades no funcionales, dependencias y decisiones pendientes— o si depende de supuestos sin resolver, aprobaciones ausentes o detalles inventados. Usa las comprobaciones como criterios de autorización: revisa las fuentes de entrada o asigna una persona revisora identificada y autorizada en vez de pulir un resultado sin respaldo.
¿Qué herramientas de IA tienen pruebas registradas para «Redacta historias de usuario y criterios de aceptación verificables»?
El registro de pruebas publicado para «Redacta historias de usuario y criterios de aceptación verificables» incluye ChatGPT a fecha de 2026-08-28. Esto confirma ejecuciones registradas, no garantiza la compatibilidad ni resultados idénticos en versiones posteriores del producto. Si usas otra herramienta o versión, mantén visibles todas las restricciones y repite las comprobaciones del resultado antes de utilizarlo.
Convierte las observaciones de las sesiones en problemas de usabilidad cuantificados mediante pruebas, sin culpar a los participantes ni exagerar la prevalencia
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
