Generador de historias de usuario

Resumen: una historia de usuario es un requisito de una sola frase, escrito desde el lado del usuario: quién necesita algo, qué quiere hacer y para qué. Si le añades dos o tres criterios de aceptación con Dado que / cuando / entonces, una estimación y una prioridad MoSCoW, el equipo puede empezar sin otra reunión. Este generador te da la plantilla, cinco conjuntos de ejemplo, una revisión INVEST y un CSV que Jira importa como incidencias de tipo Story.

Está pensada para fundadores, product owners y analistas que necesitan un backlog claro antes de hablar con un proveedor. Unas historias bien escritas son también la base más rápida para presupuestar: si estás planificando el desarrollo de un MVP o una colaboración más larga de product engineering, envíanos el backlog y te devolveremos una estimación en un día laborable.

El generador funciona en cuatro pasos y todo se queda en tu navegador:

1. Producto. Pon nombre al producto o a la versión, elige story points o tallas de camiseta y escribe una Definition of Done común.
2. Conjunto. Elige un punto de partida: tienda online, reparto de comida, aplicación de fitness, cuenta SaaS o marketplace, ocho historias cada uno. O empieza con una lista vacía.
3. Historias. Ajusta roles, acciones, valores, criterios, estimaciones, prioridades y épicas.
4. Revisión. Repasa los avisos INVEST y exporta a CSV para Jira, DOCX, Markdown o PDF.

Esta versión no redacta con IA: reescribes una plantilla o un conjunto de ejemplo, y así las historias describen tu producto.

¿Cómo es una buena historia de usuario?

Una buena historia de usuario nombra un rol concreto, una sola acción y un valor defendible ante quien aprueba el presupuesto: «Como [rol], quiero [acción] para [valor]». Un ejemplo completo para una tienda online:

Historia: Como clienta habitual, quiero repetir un pedido anterior con un clic para no tener que montar el carrito desde cero.

• Dado que he iniciado sesión y tengo un pedido entregado, cuando pulso «Repetir pedido», entonces todos los artículos disponibles se añaden al carrito con las mismas cantidades.
• Dado que un artículo de ese pedido está agotado, cuando pulso «Repetir pedido», entonces se añaden los demás y veo cuál se ha quedado fuera.
• Dado que mi carrito ya tiene artículos, cuando repito el pedido, entonces los nuevos se suman sin sustituir los que había.

Estimación: 3 story points (M). Prioridad: Should. Épica: Pedidos.

Si no consigues escribir la parte «para», pregúntate si de verdad hace falta la funcionalidad.

¿Cómo se escriben criterios de aceptación con Dado que / cuando / entonces?

Cada criterio cubre un escenario: Dado que describe el estado antes de la acción, cuando es la acción y entonces es un resultado que cualquiera puede comprobar sin preguntarte. Es el formato Given / When / Then de BDD. Empieza por el camino principal y añade lo que suele fallar en producción: datos vacíos, errores, falta de permisos, pérdida de conexión. Entre tres y cinco criterios es una cifra razonable; si necesitas más de seis, seguramente tienes dos historias en una.

Los criterios de aceptación no son la Definition of Done. Los criterios pertenecen a una historia; la Definition of Done vale para todas («revisión de código hecha, pruebas en verde, desplegado en preproducción»). QA puede convertir cada línea en un caso de prueba.

¿Qué significa INVEST y qué revisa el generador?

INVEST es una comprobación de calidad en seis puntos. El generador marca lo que puede detectar solo; el resto se aclara con el equipo.

¿Cómo se estiman y priorizan las historias de usuario?

La escala 1, 2, 3, 5, 8 compara historias entre sí; no son horas. Las tallas de camiseta son más rápidas para una primera vuelta y el generador las guarda como puntos (XS = 1, S = 2, M = 3, L = 5, XL = 8), así que la columna de Jira sigue siendo numérica.

MoSCoW reparte el backlog en Must, Should, Could y Won’t (esta vez no). En la primera versión, el grupo Must debe ser tan pequeño que por sí solo entregue algo usable. Won’t deja constancia de lo que habéis decidido dejar fuera.

¿Cómo se importan las historias de usuario en Jira?

Descarga «CSV para Jira» y en Jira abre Sistema → Importación de sistema externo → CSV para asociar las columnas. Cada fila es una historia:

• Summary: la acción, lo bastante corta para una tarjeta del tablero;
• Description: la frase «Como… quiero… para…» con los criterios numerados;
• Issue Type: siempre Story;
• Story Points: de 1 a 8;
• Epic Link: el nombre de la épica; crea antes las épicas o usa claves existentes;
• Labels: la prioridad MoSCoW (moscow-must, moscow-should…) y, con tallas de camiseta, la talla.

En proyectos gestionados por el equipo, asocia la épica al campo Parent en lugar de Epic Link.

¿Dónde encajan las historias de usuario junto al PRD y la RFP?

Las historias describen el comportamiento; los documentos de alrededor dan el contexto. Objetivos, alcance, riesgos y requisitos no funcionales van en el documento de requisitos de producto, que puedes preparar con la plantilla PRD. Ahí indicas también el cumplimiento del RGPD y la LOPDGDD que esperas del proveedor, porque no es una historia suelta. Si externalizas el desarrollo, adjunta el backlog a una plantilla RFP para pedir ofertas y compara las respuestas en la evaluación de proveedores. Las ofertas sobre las mismas historias se comparan mucho mejor que las hechas sobre un briefing vago.

Preguntas frecuentes

Herramientas relacionadas