Una historia de usuario es una descripción corta de una necesidad, escrita desde el punto de vista de quien usa el producto: "Como [persona], quiero [acción], para [beneficio]". Viene con criterios de aceptación que dicen cuándo está terminada, muchas veces en el formato Dado, Cuando, Entonces. El checklist INVEST (independiente, negociable, valiosa, estimable, pequeña y testeable) ayuda a ver si la historia está lista para el backlog.
Cómo usar
- Indica la funcionalidad o la épica y la persona, tal como entra en la frase "Como...".
- Escribe un requisito por línea, empezando por el verbo; si quieres, agrega el beneficio después de ", para".
- Completa el beneficio general y las reglas de negocio que valen para todas las historias.
- Lee cada historia con sus criterios, el checklist INVEST y las sugerencias para dividir las que parecen grandes.
- Exporta en Markdown o CSV para llevar a Jira o al backlog del equipo.
Qué pide cada campo
| Campo | Qué completar |
|---|---|
| Funcionalidad o épica | Lo que se construye, en pocas palabras. |
| Persona | Quién la usa, tal como entra en la frase "Como...". |
| Requisitos | Uno por línea, empezando por el verbo. Cada uno será una historia. |
| Beneficio general | Se usa en las historias que no dicen el beneficio (opcional). |
| Reglas de negocio | Límites que valen para todas las historias (opcional). |
Ejemplo
Para el recordatorio automático de cobro de una app ficticia, la persona es una diseñadora independiente que emite facturas en la app. Cuatro requisitos se convierten en cuatro historias, cada una con dos a cuatro criterios de aceptación. Dos pasan todo el INVEST. La que activa recordatorios para todas las facturas recibe la sugerencia de empezar por un caso, y la que une ver y exportar la lista recibe la sugerencia de llevar "exportar" a una historia propia. Las dos reglas de negocio se vuelven criterios comunes.
Cuándo usar
- Después del PRD, para convertir los requisitos en ítems de backlog que el equipo pueda estimar.
- Antes del refinamiento, para llegar con criterios de aceptación y no solo con títulos.
- Para revisar un backlog antiguo y encontrar historias demasiado grandes o sin beneficio claro.
- Para enseñar a quien empieza a escribir historias con un formato coherente.
Preguntas frecuentes
¿Qué es una historia de usuario?
Es una necesidad descrita desde el punto de vista de quien usa el producto, en el formato "Como [persona], quiero [acción], para [beneficio]". Es una invitación a conversar, no una especificación completa.
¿Qué son los criterios de aceptación?
Son las condiciones que dicen cuándo la historia está terminada. El formato Dado, Cuando, Entonces describe un contexto, una acción y un resultado verificable, lo que facilita las pruebas y evita discusiones al final de la iteración.
¿Qué significa INVEST?
Es un checklist de calidad: independiente, negociable, valiosa, estimable, pequeña y testeable. La herramienta revisa cada letra con reglas simples e indica qué ajustar cuando alguna falla.
¿Cómo dividir una historia grande?
Separa acciones distintas en historias propias, divide verbos amplios como "gestionar" por operación y empieza por un caso simple antes de cubrirlos todos. Cada parte debe seguir entregando valor a quien la usa.
¿Cuál es la diferencia entre historia de usuario y requisito?
El requisito dice qué debe hacer el sistema. La historia dice quién lo necesita y por qué, y deja espacio para que el equipo proponga la mejor solución. Un requisito puede dar una o varias historias.
¿La IA escribe las historias por mí?
Sin IA, la herramienta ya arma historias, criterios y checklist con reglas. Cuando la IA esté activada, solo mejora la redacción y sugiere criterios extra; la decisión sigue siendo del equipo.