Crear Historias de Usuario
Convierte una especificación en historias a partir de las cuales los ingenieros puedan construir.
Tienes un PRD o una descripción de funcionalidad y necesitas dividirla en historias de usuario que sean lo suficientemente pequeñas para implementar en un sprint, lo suficientemente claras para que los ingenieros no tengan que adivinar, y lo suficientemente verificables para que QA sepa cuándo está terminado.
Plantilla de Prompt
Eres un product manager experimentado desglosando una funcionalidad en historias de usuario para ingeniería.
Aquí está la funcionalidad o especificación a desglosar:
<contexto>
$ARGUMENTS
</contexto>
> Si lo anterior está vacío, pregunta al usuario: "{{PEGA AQUÍ TU PRD, DESCRIPCIÓN DE FUNCIONALIDAD, ENLACES DE DISEÑO O REQUISITOS PRELIMINARES}}"
Desglosa esto en historias de usuario usando la siguiente estructura para cada una:
**Título:** Nombre corto y descriptivo para la historia
**Historia:** Como [rol de usuario específico], quiero [acción], para [beneficio/resultado].
**Criterios de Aceptación:**
- [ ] Dado [precondición], cuando [acción], entonces [resultado esperado]
- [ ] Incluye casos extremos, estados de error y condiciones límite
- [ ] 4-6 criterios por historia — suficientes para ser claros, no tantos que sea una mini-especificación
**Prioridad:** P0 (imprescindible para el lanzamiento), P1 (debería tener) o P2 (deseable / futuro)
**Notas:** Dependencias, referencias de diseño, consideraciones técnicas o preguntas abiertas.
Aplica estos principios:
- Cada historia debe ser completable en un solo sprint. Si es demasiado grande, divídela.
- Las historias deben ser independientes — evita cadenas donde la historia B no pueda empezar hasta que la historia A esté lista.
- Escribe los criterios de aceptación como comportamientos verificables, no descripciones vagas. "El usuario ve un mensaje de éxito" no es "el usuario tiene una buena experiencia".
- Incluye los caminos infelices. ¿Qué sucede cuando la API falla? ¿Cuando el usuario no tiene datos? ¿Cuando alcanza un límite de tasa?
- Agrupa las historias por flujo de trabajo del usuario, no por componente técnico.
- Marca cualquier historia que requiera aportes de diseño, cambios en la API o dependencias entre equipos.
Consejos
- Alimenta esto con la salida de craft-spec para tener un pipeline limpio de PRD → historias de usuario.
- Si las historias siguen saliendo demasiado grandes, probablemente la especificación tiene un alcance que debería dividirse primero en fases.
- Los mejores criterios de aceptación se leen como un script de prueba — un ingeniero de QA debería poder verificar cada uno sin hacer preguntas.
- No olvides la historia de "estado cero" — ¿qué ve el usuario antes de tener datos? Esto casi siempre se pasa por alto.