Historias de usuario (user stories)
Describe lo que hay que construir como necesidades pequeñas y comprobables escritas desde el lado del usuario, para que el equipo construya lo correcto y sepa cuándo ha terminado.
- Tiempo
- 45 min
- Personas
- 3–6
- Tipo de trabajo
- Planificar
En resumen
Una historia de usuario es una frase breve que expresa una necesidad, con la forma "Como [usuario], necesito [algo], para [motivo]", acompañada de criterios de aceptación que indican cuándo está terminada. Para escribirlas, parte de la investigación, agrupa las historias relacionadas en épicas, divide las grandes y acuerda los criterios con quienes las construirán y probarán.
Qué es
Una historia de usuario describe una pieza de trabajo desde el punto de vista de la persona que la va a usar, y no como una tarea técnica. Tiene tres partes: quién es el usuario, qué necesita y por qué lo necesita. La parte del "para" es la que más importa, porque dice al equipo qué problema resuelve el trabajo y le permite proponer una forma mejor de resolverlo. Cada historia lleva criterios de aceptación: una lista breve de condiciones que deben cumplirse para que la historia cuente como terminada.
Las historias de usuario vienen de la práctica ágil de desarrollo de software y se usaron por primera vez en Extreme Programming a finales de los años noventa. Hoy son habituales en los equipos de servicios digitales, también en la administración pública. El GOV.UK Service Manual usa la fórmula "necesito" en lugar de "quiero", para mantener el foco en necesidades reales. Las historias grandes que abarcan un objetivo completo se llaman épicas y se dividen en historias más pequeñas que pueden construirse y probarse en poco tiempo. En esta ficha registras el usuario, la necesidad, el motivo, los criterios de aceptación, la épica a la que pertenece y la evidencia que la respalda.
Cuándo usarlo
Úsalo cuando
- Has terminado el trabajo de investigación y diseño y necesitas convertirlo en una lista de trabajo que un equipo de desarrollo pueda construir.
- Un documento de requisitos es largo y técnico, y nadie sabe decir qué partes importan más a los usuarios.
- Estás planificando la primera versión de un servicio nuevo y necesitas acordar qué entra y qué puede esperar.
- Los equipos de negocio, de políticas y técnicos describen el mismo servicio con palabras distintas y no dejan de malinterpretarse.
- Necesitas condiciones claras para las pruebas, de modo que todos estén de acuerdo en cuándo una funcionalidad está terminada.
Evítalo cuando
- Todavía no sabes quiénes son tus usuarios ni qué necesitan. Investiga primero o las historias describirán conjeturas.
- El trabajo es puramente técnico, sin cambios visibles para el usuario, como actualizar una base de datos. Una descripción de tarea sencilla es más clara.
- Todavía estás explorando ideas muy distintas. Las historias fijan el detalle demasiado pronto; usa antes un storyboard o un prototipo.
Qué necesitas
- Tiempo
- Unos 45 minutos para redactar y revisar las historias de una épica; más para un servicio completo.
- Personas
- De 3 a 6 personas: la persona responsable del producto o del servicio, alguien de la investigación y al menos una persona que vaya a construir y otra que vaya a probar.
- Materiales
- Hallazgos de la investigación o un mapa de experiencia, fichas o un tablero compartido y una plantilla sencilla con los seis campos de la ficha.
Cómo aplicarlo
Paso 1: Parte del objetivo del usuario
Escribe en la parte superior del tablero el objetivo general de un grupo de usuarios, por ejemplo "un afiliado solicita su pensión de jubilación". Esa será la épica. Coloca a su lado la investigación relevante, como citas, un mapa de experiencia o un enunciado de punto de vista, para que las historias sigan vinculadas a la evidencia.
Paso 2: Nombra a los usuarios con precisión
Enumera con palabras sencillas los tipos de usuario que intervienen en el objetivo: "un afiliado que se jubila este año", "la empresa del afiliado", "un técnico de pensiones". Evita "como usuario" y "como sistema"; ocultan de quién es la necesidad. El personal también es usuario y tiene sus propias historias.
Paso 3: Redacta las historias
Pide a cada persona que escriba historias en fichas separadas con la forma "Como…, necesito…, para…". Escribe la necesidad en los términos del usuario, no como una pantalla o un botón: "necesito saber qué documentos enviar" en lugar de "necesito una página para subir documentos". Apunta a una necesidad por ficha.
Paso 4: Revisa el "para"
Lee cada ficha en voz alta y pregúntate si el motivo es real y concreto. "Para poder solicitarla" no aporta nada. "Para que mi primer pago no se retrase" dice al equipo qué aspecto tiene el éxito. Si nadie sabe decir por qué lo necesita el usuario, retira la ficha o márcala como supuesto que hay que comprobar.
Paso 5: Divide las historias grandes
Si construir y probar una historia le llevaría a un equipo más de unos pocos días, divídela. Buenas formas de dividir son por tipo de usuario, por paso del recorrido, por casos sencillos y complejos, o primero el camino principal y después las excepciones. Mantén las historias resultantes bajo la misma épica.
Paso 6: Escribe los criterios de aceptación
Para cada historia, acuerden de tres a seis condiciones que deben cumplirse cuando esté terminada, redactadas para que alguien que prueba pueda comprobarlas. Un patrón útil es "Dado [situación], cuando [acción], entonces [resultado]". Incluye los caminos con problemas, como un documento que falta o un número erróneo, no solo el principal.
Paso 7: Ordena y registra
Coloca las historias bajo la épica en el orden en que los usuarios se las encuentran y marca cuáles hacen falta para la primera versión. Registra cada historia con su evidencia y sus criterios en el backlog del equipo, y acuerden quién revisará las historias con el equipo de investigación antes de empezar a construir.
Ejemplo práctico
Un fondo público de pensiones recibía unas 3.400 solicitudes de jubilación al mes, casi todas en papel. Tramitar una solicitud llevaba una media de 47 días, y el 38 % se devolvía al afiliado al menos una vez por información incompleta o errónea. El fondo planeaba un servicio en línea y tenía un documento de requisitos de 400 páginas que al equipo de desarrollo le resultaba difícil de usar.
Cinco personas se reunieron durante 45 minutos: la responsable del servicio, un investigador de usuarios, una técnica de pensiones, un desarrollador y una persona de pruebas. Tomaron la épica "un afiliado solicita su pensión de jubilación" y colocaron a su lado citas de entrevistas y el mapa de experiencia.
Enumeraron cuatro usuarios: un afiliado que se jubila este año, la empresa del afiliado, una técnica de pensiones y un familiar designado por el afiliado. El primer borrador produjo 26 fichas de historia.
Revisar el "para" eliminó cuatro fichas que solo repetían el paso. También transformó "Como afiliado, necesito subir mi certificado de servicios prestados" en "Como afiliado que se jubila este año, necesito saber que mi empresa ya ha confirmado mis fechas de servicio, para no tener que conseguir yo el certificado".
La historia sobre el cálculo de la pensión era demasiado grande. El equipo la dividió en tres: afiliados con una sola empresa, afiliados con varias empresas y afiliados con lagunas de cotización, y marcó solo la primera para la versión uno.
Los criterios de aceptación de la historia de las fechas de servicio incluían "Dado que la empresa ha confirmado las fechas, cuando el afiliado inicia sesión, entonces se muestran las fechas y puede aceptarlas" y "Dado que faltan las fechas, cuando el afiliado inicia sesión, entonces ve a quién debe contactar y el caso se señala para una técnica".
El backlog final de la épica tenía 18 historias, 11 de ellas marcadas para la primera versión. El equipo reservó una revisión con el investigador antes del primer sprint.
IlustrativoConsejos y errores
Consejos
- Escribe la necesidad como algo que el usuario quiere conseguir, no como una funcionalidad. Deja margen para que el equipo encuentre una solución más sencilla.
- Mantén las historias lo bastante pequeñas para construirlas y probarlas en un sprint o en una semana. Las historias grandes esconden riesgos.
- Escribe también historias para el personal. Quienes tramitan los casos tienen necesidades que dan forma a todo el servicio.
- Vincula cada historia a la evidencia que la respalda, para que cualquiera pueda comprobar de dónde salió una necesidad.
Errores frecuentes
- Escribir "Como usuario" en todo, lo que oculta las distintas necesidades de distintas personas.
- Convertir una tarea técnica en historia añadiendo "Como sistema", lo que anula el sentido del formato.
- Omitir los criterios de aceptación, de modo que el equipo y quienes prueban deciden cada uno qué significa terminado.
- Escribir todo el backlog a solas en un escritorio y entregarlo, en lugar de redactarlo y revisarlo con el equipo.
Con qué terminas
Sales con una épica dividida en historias de usuario pequeñas, cada una con el usuario, la necesidad y el motivo, sus criterios de aceptación, un vínculo a la evidencia y una marca para la primera versión. Las historias pasan directamente al backlog del equipo de desarrollo. Una hoja de ruta ayuda a ordenar las épicas en el tiempo, y un storyboard puede mostrar cómo las historias componen una sola experiencia.
Preguntas frecuentes
¿Por qué GOV.UK usa "necesito" en lugar de "quiero" en las historias de usuario?
"Necesito" mantiene el foco en lo que los usuarios deben poder hacer para conseguir el resultado, y no en preferencias. Empuja a los equipos a pedir evidencia de que la necesidad es real. Muchos equipos fuera de la administración usan "quiero"; la estructura de la historia es la misma.
¿Qué diferencia hay entre una épica y una historia de usuario?
Una épica es un objetivo grande del usuario, como solicitar una pensión, demasiado grande para construirlo de una vez. Una historia de usuario es una parte pequeña de ese objetivo que un equipo puede construir y probar en pocos días. Una épica suele contener varias historias, a veces decenas.
¿Cuántos criterios de aceptación debería tener una historia de usuario?
Normalmente de tres a seis. Menos puede indicar que la historia es vaga o que se han pasado por alto los caminos con problemas. Muchos más suelen indicar que la historia es demasiado grande y debería dividirse.
Ficha de la herramienta
La ficha de trabajo que rellena tu equipo, una casilla por campo.
- Usuario
- Necesidad
- Para
- Criterios de aceptación
- Épica
- Evidencia