Plantilla de historia de usuario con criterios de aceptación (Gratis)

Una plantilla de historia de usuario cumple dos funciones. Hace que cada historia responda a las mismas tres preguntas (quién, qué, por qué) y le da al equipo un lugar fijo para anotar cómo sabrán que la historia está terminada. Esta página te ofrece ambas: el formato de historia de una línea, una plantilla de tarjeta completa que puedes copiar, criterios de aceptación en tres formatos, una definición de listo y hecho, y ejemplos prácticos.

Si eres nuevo en las historias de usuario, comienza con nuestra guía sobre cómo escribir historias de usuario, y luego vuelve aquí para la plantilla.

La plantilla de historia de usuario de una línea

La mayoría de los equipos usan el formato que surgió del equipo Connextra en Londres en 2001 y fue popularizado por el libro de Mike Cohn, User Stories Applied (su resumen de historias de usuario es una buena introducción):

Como [tipo de usuario], quiero [una acción o capacidad], para que [un beneficio o resultado].

Cada parte cumple una función específica:

• “Como” nombra un tipo real de usuario, como un comprador por primera vez, un administrador de cuenta o un paciente recurrente. “Como usuario” no le dice nada al equipo. Si tienes personas, usa sus nombres.
• “Quiero” describe lo que el usuario hace o obtiene, en sus propias palabras. No debe describir la solución (“un menú desplegable”, “una caché de Redis”); deja espacio para que el equipo encuentre la mejor opción.
• “Para que” establece el valor. Esta es la parte que más a menudo se omite y la que más importa: es cómo el equipo puede proponer una opción más simple que entregue el mismo resultado, y cómo el propietario del producto decide la prioridad.

Ten en cuenta que la oración no es el requisito. Ron Jeffries describió una historia como tres cosas: la tarjeta, la conversación y la confirmación (los 3 Cs). Una plantilla ayuda con la tarjeta y la confirmación (los criterios de aceptación); nada reemplaza la conversación.

La plantilla completa de tarjeta de historia de usuario

La frase de una línea es suficiente para una nota adhesiva. En una herramienta de backlog, normalmente necesitas unos pocos campos más para que la historia pueda ser clasificada, estimada y probada. Estos son los campos que encontramos útiles; elimina cualquiera que tu equipo nunca lea.

Mantén “Contexto y notas” breve: si se convierte en una página de especificación, la historia probablemente es una épica y necesita dividirse (nuestra guía de mapeo de historias muestra cómo).

Plantilla de historia de usuario lista para copiar

Pega esto en el campo de descripción de un problema de Jira o Linear, una plantilla de base de datos de Notion o la fila de encabezado de una hoja de cálculo. Reemplaza el texto entre corchetes y elimina las líneas que no uses.

• ID: [PROJECT-000]
• Título: [Verbo + objeto, por ejemplo “Exportar facturas a CSV”]
• Historia: Como [tipo de usuario], quiero [acción o capacidad], para que [beneficio].
• Contexto: [Por qué es importante ahora; enlace a investigación, tickets de soporte o métricas]
• Criterios de aceptación: [3 a 7 condiciones probables, en formato de lista de verificación o Given/When/Then]
• Fuera de alcance: [Lo que esta historia no cubre deliberadamente]
• Diseños: [Enlace al frame o prototipo]
• Dependencias: [Otras historias, servicios o decisiones]
• Prioridad: [Must / Should / Could, o posición en el backlog]
• Estimación: [Puntos o tamaño, completado por el equipo]
• Preguntas abiertas: [Cualquier cosa que deba resolverse antes de que comience el sprint]

La línea “Fuera de alcance” evita discusiones: escribir “no incluye restablecimiento por SMS” en la tarjeta es mejor que descubrir en la revisión del sprint que alguien asumió que sí lo incluía.

Qué son los criterios de aceptación y quién los escribe

Los criterios de aceptación son las condiciones que una historia debe cumplir para ser aceptada por el product owner. Describen el comportamiento observable desde el punto de vista del usuario, no cómo funciona el código. Los buenos criterios son:

• Probables: alguien puede decir sí o no sin interpretar. “Rápido” no es probable; “los resultados aparecen en dos segundos” sí lo es.
• Específicos para esta historia: las reglas que aplican a todas las historias (código revisado, desplegado en staging) pertenecen a la definición de hecho, no aquí.
• Libres de detalles de implementación: di qué sucede, no qué componente o tabla lo hace posible.
• Honestos ante el fallo: al menos un criterio debe cubrir entrada inválida, falta de red o permisos ausentes.
• Pocos: tres a siete criterios es un rango saludable. Más de diez suele significar que la historia debe dividirse.

El product owner es responsable de los criterios, pero no debe escribirlos solo. El patrón más fiable es una breve conversación de refinamiento entre producto, un desarrollador y un probador (a menudo llamado “three amigos”): cuál es el valor, cómo se construirá esto y cómo podría fallar.

Formato 1: criterios de aceptación en lista de verificación

Una lista simple de condiciones. Es el formato más rápido de escribir y leer, y funciona bien para historias simples y para equipos que prueban manualmente.

Historia: Como cliente recurrente, quiero restablecer mi contraseña por correo electrónico, para que pueda volver a acceder a mi cuenta sin contactar al soporte.

• La pantalla de inicio de sesión tiene un enlace “¿Olvidaste tu contraseña?” que abre el formulario de restablecimiento.
• Enviar una dirección de correo electrónico registrada envía un enlace de restablecimiento en un minuto.
• El enlace de restablecimiento funciona una vez y expira después de 30 minutos.
• La nueva contraseña debe cumplir con las reglas de contraseña existentes, y el formulario indica qué regla no se cumplió.
• Tras un restablecimiento exitoso, todas las demás sesiones de esa cuenta se cierran.
• Enviar una dirección no registrada muestra el mismo mensaje de confirmación que una registrada, por lo que el formulario no revela quién tiene una cuenta.

Utilice la lista de verificación cuando el comportamiento sea sencillo. Su debilidad es que oculta el estado inicial y el orden de los eventos, lo que el siguiente formato hace explícito.

Formato 2: Criterios de aceptación Given/When/Then (Gherkin)

Given/When/Then proviene del desarrollo orientado a comportamientos, que Dan North describió con Chris Matts en Introducing BDD. Cada escenario establece un contexto inicial (Given), una acción (When) y un resultado esperado (Then). Gherkin es la versión estructurada de este lenguaje utilizada por Cucumber y herramientas similares, por lo que los escenarios escritos de esta manera pueden convertirse en pruebas automatizadas con poca reescritura.

Aquí está la misma historia de restablecimiento de contraseña como tres escenarios, incluyendo dos rutas no exitosas.

Escenario 1: restablecer con un enlace válido

• Dado que tengo una cuenta registrada en anna@example.com
• Y he solicitado un restablecimiento de contraseña
• Cuando abro el enlace de restablecimiento dentro de los 30 minutos y escribo una nueva contraseña que cumple con las reglas
• Entonces mi contraseña se cambia
• Y me inicio sesión
• Y mis otras sesiones se cierran

Escenario 2: el enlace ha expirado

• Dado que solicité un restablecimiento de contraseña hace más de 30 minutos
• Cuando abro el enlace de restablecimiento
• Entonces veo un mensaje de que el enlace ha expirado
• Y se me ofrece un botón para enviar un nuevo enlace

Escenario 3: la dirección de correo electrónico no está registrada

• Dado que no existe ninguna cuenta para sam@example.com
• Cuando solicito un restablecimiento de contraseña para sam@example.com
• Entonces veo el mismo mensaje de confirmación que ve un usuario registrado
• Y no se envía ningún correo electrónico

Cuando un escenario necesita ejecutarse con varias entradas (por ejemplo, una lista de contraseñas que deben rechazarse), el Scenario Outline de Gherkin permite escribirlo una vez y listar las entradas en una tabla de ejemplos.

Mantenga Gherkin legible: un comportamiento por escenario, y escriba de forma declarativa (“Cuando solicito un enlace de restablecimiento”) en lugar de paso a paso (“Cuando hago clic en el botón Enviar”), para que el escenario sobreviva a un rediseño.

Formato 3: Criterios de aceptación basados en reglas

Para historias que son principalmente reglas de negocio (precios, elegibilidad, validación, permisos), establezca las reglas directamente y agregue escenarios solo para las combinaciones complicadas.

Historia: Como comprador, quiero aplicar un código de descuento al finalizar la compra, para que pague el precio promocional.

• Regla 1: un código por pedido.
• Regla 2: un código porcentual se aplica solo al subtotal del producto, no al envío o al impuesto.
• Regla 3: un código con un gasto mínimo se aplica solo cuando el subtotal, antes del descuento, cumple con el mínimo.
• Regla 4: los códigos expirados o agotados se rechazan con un mensaje que indica el motivo.
• Regla 5: eliminar artículos para que el subtotal baje por debajo del mínimo elimina el código y muestra un aviso.

Puedes mezclar formatos en una sola historia. Un patrón común es usar reglas para la lógica más dos o tres escenarios Dado/Cuando/Entonces para los casos que la gente es más propensa a malinterpretar.

Definición de listo vs definición de hecho

Los criterios de aceptación son específicos de una historia. La definición de listo y la definición de hecho son acuerdos de todo el equipo que se aplican a cada historia.

El Guía de Scrum define la definición de hecho como la descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto. La definición de listo no es parte de Scrum; es una práctica que muchos equipos adoptan para evitar que el trabajo mal comprendido entre en un sprint (ver el glosario de la Alianza Ágil sobre definición de listo y definición de terminado).

Ejemplo de definición de listo

• La historia sigue la plantilla y el campo “para que” está completado.
• Los criterios de aceptación están escritos y revisados por producto, desarrollo y pruebas.
• Los diseños están vinculados, o el equipo acordó que no se necesitan.
• Las dependencias están completas o programadas.
• El equipo lo ha estimado y cabe en un solo sprint.

Ejemplo de definición de hecho

• Todos los criterios de aceptación se cumplen.
• El código está revisado y fusionado en la rama principal.
• Las pruebas automatizadas cubren el nuevo comportamiento y la suite completa pasa.
• Se superan las comprobaciones básicas de accesibilidad (uso del teclado, etiquetas, contraste).
• Está desplegado en staging y el propietario del producto lo ha aceptado.

Trata la definición de listo como una lista de verificación para el refinamiento, no como una barrera. Si un equipo rechaza cada historia que no cumple un punto, el trabajo se ralentiza y la conversación que la historia debía iniciar nunca ocurre.

Ejemplos prácticos

Dos historias más de diferentes tipos de producto. Para ver cuarenta más, consulta nuestro ejemplos de historias de usuario.

SaaS: invitar a un compañero de equipo (lista de verificación)

Como administrador de espacio de trabajo, quiero invitar a un compañero de equipo por correo electrónico, para que pueda ver nuestros proyectos sin que tenga que compartir mis credenciales de acceso.

• Los administradores ven un botón “Invitar” en la página de miembros; los demás roles no lo ven.
• El administrador puede elegir el rol (Miembro o Administrador) antes de enviar la invitación.
• El correo de invitación llega en menos de un minuto y el enlace es válido durante siete días.
• Invitar a una dirección que ya es miembro muestra un mensaje en lugar de enviar una segunda invitación.

Comercio electrónico: guardar un artículo para más tarde (Dado/Cuando/Entonces)

Como comprador que no está listo para comprar, quiero mover un artículo de mi carrito a una lista guardada, para que pueda encontrarlo de nuevo sin que afecte al total de mi pedido.

• Dado que estoy registrado y tengo dos artículos en mi carrito
• Cuando elijo “Guardar para más tarde” en un artículo
• Entonces ese artículo se mueve a mi lista guardada
• Y el total de mi carrito se recalcula sin incluirlo
• Dado que no estoy registrado
• Cuando elijo “Guardar para más tarde”
• Entonces se me pide que me registre, y el artículo se guarda una vez que lo hago

Usando la plantilla en Jira, Linear, Notion o una hoja de cálculo

En Jira, usa el tipo de problema Story y pega la plantilla en la descripción (o mantén los criterios de aceptación en un campo dedicado si tu administrador ha añadido uno). En Linear, guárdalo como una plantilla de problema. En Notion, colócalo en una plantilla de base de datos para que las nuevas páginas del backlog se abran prellenadas. Una hoja de cálculo con una fila por historia funciona para un primer backlog o un taller, pero pasa a un rastreador una vez que varias personas lo editan. Sea cual sea la herramienta, mantén la plantilla lo suficientemente corta para que la gente la complete.

Redactar historias y criterios de aceptación con IA

Los modelos de lenguaje son buenos para un primer borrador de historias y criterios. Un prompt que funciona:

Eres un gestor de producto. Para la función descrita a continuación, escribe historias de usuario en el formato “Como [usuario], quiero [acción], para que [beneficio]”. Para cada historia, añade de 3 a 6 criterios de aceptación en forma Dado/Cuando/Entonces, incluyendo al menos un camino no feliz. Lista cualquier suposición y pregunta abierta por separado. Función: [describe la función, los usuarios y cualquier restricción].

Luego revisa el borrador como cualquier otra entrada:

• ¿El usuario es un segmento real con el que has hablado, o es un “usuario” genérico?
• ¿El modelo inventó reglas de negocio, límites o números? Reemplázalos con los tuyos.
• ¿Los caminos no felices son los que tus usuarios realmente encuentran? Un borrador nunca reemplaza la conversación de refinamiento.

Preguntas frecuentes

¿Quieres que un equipo convierta tus historias en software funcional? Trae tu backlog, o solo la idea, y te ayudaremos a dar forma a historias de tamaño de sprint y a construirlas. Ver nuestros planes de desarrollo mensual.