Cómo escribir una historia de usuario cuando no eres tú quien la construye
Una historia de usuario es la unidad más pequeña de un briefing de desarrollo. Bien escrita, te entrega lo que imaginaste. Mal escrita, se convierte en la factura que no esperabas. Aquí tienes el formato, las cuatro pruebas que separan una historia construible de una trampa, y un ejemplo trabajado.
Una fundadora con la que trabajé el año pasado aprobó una historia en unos cuatro segundos. Decía: “Como cliente, quiero gestionar mi cuenta.” Asintió, arrastró la tarjeta al sprint y se fue a una llamada de ventas. Tres semanas después, el equipo de desarrollo volvió con una factura por la página de cuenta: edición de perfil, restablecimiento de contraseña, configuración de doble factor, historial de facturación, cambio de plan, exportación de datos, eliminación de cuenta. Todo defendible. Todo “gestionar mi cuenta.” Nada de lo que ella tenía en la cabeza, que era una sola pantalla donde el usuario pudiera cambiar el correo.
Esa distancia es lo que una historia de usuario debería cerrar, y por eso aprender cómo escribir una historia de usuario importa más a quien paga el desarrollo que a los desarrolladores que lo hacen. Una historia de usuario es una frase que describe algo que una persona concreta quiere hacer con tu software y por qué, lo bastante pequeña como para construirla y verificarla en pocos días. El formato clásico, popularizado por Mike Cohn y los primeros equipos de Extreme Programming, es: Como [tipo de usuario], quiero [hacer algo], para [obtener algún beneficio]. Ese es el template entero. Lo difícil no es la frase. Es escribir una que no se convierta en silencio en tres semanas de trabajo que nunca aprobaste.
Qué es una historia de usuario, y qué no es
Una historia de usuario no es una especificación. Esto confunde a fundadores que vienen de finanzas y consultoría, que esperan un documento que fije cada detalle de antemano. La frase de Cohn para una historia es “una promesa de conversación.” La tarjeta es un marcador. Dice estamos de acuerdo en que esto vale la pena construir y vale la pena hablarlo, y confía en que tú y el equipo resolveréis los detalles cuando llegue el trabajo, no meses antes.
Es lo que llaman las “3 C”, que verás citado en todas partes: Tarjeta, Conversación y Confirmación (Card, Conversation, Confirmation). La tarjeta es la frase única. La conversación es donde tú y el desarrollador averiguáis qué hace la pantalla en realidad. La confirmación es cómo ambos sabéis que está terminada, y ya llegaremos, porque es la parte que los fundadores se saltan y la parte que cuesta cara.
Así que una historia es deliberadamente incompleta. Pero hay incompleta-a-propósito e incompleta-porque-es-vaga, y la diferencia es todo el juego. “Como cliente, quiero gestionar mi cuenta” no es una pequeña promesa de conversación. Es un área de funcionalidad entera disfrazada de historia única. El equipo puede cotizarla en cualquier cosa entre un día y un mes, y sea lo que sea que elijan, te vas a sorprender.
El template de historia de usuario, y las tres partes que de verdad son tuyas
Aquí está el formato de nuevo, rellenado como corresponde:
Como comprador primerizo, quiero cambiar la dirección de correo de mi cuenta, para seguir recibiendo avisos de pedido después de cambiar de trabajo.
Tres casillas. Como quién, quiero qué, para por qué. Al “quién/qué/cuándo/dónde/por qué” lo llaman las 5 W de una historia, pero tú, como fundador, solo eres dueño de tres: para quién es, qué intenta hacer la persona y por qué importa. El cuándo y el dónde pertenecen a la conversación con el equipo.
Las tres casillas no son adorno. Cada una es una palanca:
El quién te impide construir para un “usuario” genérico que no existe. Un comprador primerizo y un usuario avanzado que vuelve siempre quieren cosas distintas de la misma pantalla. Nombra a la persona real y la mitad de la ambigüedad desaparece.
El qué es una sola acción, no una capacidad. “Cambiar el correo” es una acción. “Gestionar la configuración de la cuenta” es una capacidad, y una capacidad es un cubo que contiene una docena de historias. Si tu qué contiene la palabra “gestionar”, “manejar”, “soportar” o “y”, detente. Tienes más de una historia.
El para es la parte que todos dejan caer, y la más útil. Le dice al equipo por qué quieres eso, lo que le permite proponer una forma más barata de darte el mismo resultado. La mitad de las veces, la versión del desarrollador del para es mejor que la funcionalidad que pediste. Solo lo averiguas si lo escribiste.
Las cuatro pruebas que separan una historia construible de una trampa
Los equipos ágiles usan una checklist llamada INVEST para esto. Es buena, y fue escrita para quien ejecuta. Aquí va la traducción para fundadores: las cuatro preguntas que de verdad hago antes de que una historia entre en un sprint que estoy pagando.
¿Se puede construir y mostrármela por sí sola? Una buena historia es una rebanada que atraviesa el producto entero, no una capa de él. “Construir la base de datos de las cuentas” es una capa. No puedes verla, no puedes probarla, no puedes decir si está bien. “Cambiar mi correo” atraviesa la base de datos, la pantalla y el correo de confirmación de una vez, y termina en algo que puedes mirar. Si una historia solo tiene sentido como parte de un paquete, todavía no es una historia.
¿Es lo bastante pequeña para terminarla en pocos días? No porque los desarrolladores no puedan hacer cosas grandes, sino porque las historias grandes esconden sorpresas, y las sorpresas en un presupuesto cerrado salen de tu bolsillo o de tu plazo. Si no puedes imaginar la cosa terminada dentro de una semana, es un peñasco. Divídela. “Cambiar mi correo” y “verificar el nuevo correo antes de que valga” son dos historias, y cotizarlas por separado te protege.
¿Podría rechazarla en la entrega? Esta es la que los fundadores nunca piensan hasta que es tarde. Una historia que no puedes suspender es una historia que vas a pagar dos veces. “Mejorar la experiencia de checkout” nunca puede estar mal, lo que significa que nunca puedes devolverla. “Mostrar el total, con envío incluido, antes del botón de pagar” o lo hace o no lo hace. Escribe historias que podrías rechazar, y conservas poder de negociación hasta la entrega.
¿Es sobre el usuario, no sobre la fontanería? “Añadir una caché Redis” es una tarea técnica, y las tareas técnicas las decide el equipo, no tú. Tus historias describen lo que alguien puede hacer con el producto. Si te descubres escribiendo sobre bases de datos, colas o cachés, te has ido al lado del desarrollador de la mesa. Devuélvelo y quédate en el tuyo.
Criterios de aceptación: cómo una historia deja de ser un deseo
Aquí es donde la aprobación de cuatro segundos sale mal y donde recuperas tu dinero. La historia es la promesa. Los criterios de aceptación son la confirmación, la checklist que dice exactamente qué significa “terminado”, escrita antes de que empiece el trabajo. Son la diferencia entre una historia que esperas que salga bien y una que puedes aceptar o rechazar de forma objetiva.
Para la historia del correo:
- El usuario puede abrir la configuración de la cuenta y ver su correo actual.
- Cambiarlo envía un enlace de verificación a la nueva dirección.
- El correo no cambia de verdad hasta que se pulsa el enlace.
- Si la nueva dirección ya la usa otra cuenta, el usuario ve un error claro.
- Los avisos de pedido van a la nueva dirección solo después de la verificación.
Fíjate en lo que esas cinco líneas acaban de hacer. Convirtieron un deseo de una frase en algo que el desarrollador puede cotizar con exactitud y que tú puedes revisar línea por línea en la entrega. También sacaron a la luz una decisión (¿qué pasa con un correo duplicado?) que de otro modo se habría vuelto una pregunta a mitad del sprint, o peor, una suposición silenciosa que descubrirías en producción. Los criterios de aceptación son baratos de escribir y caros de saltarse. Profundizamos en esto en nuestro texto sobre cómo escribir criterios de aceptación que un fundador no técnico pueda de verdad exigir.
Un ejemplo trabajado: de una petición vaga a una historia que puedes entregar
Empieza con lo que los fundadores de verdad dicen en un kickoff: “Quiero que los usuarios puedan invitar a sus compañeros de equipo.”
Eso es una capacidad, no una historia. Es la trampa de “gestionar mi cuenta” con otro traje. Pásala por las pruebas y se divide en historias, cada una que puedes ver, dimensionar y rechazar:
Como dueño de la cuenta, quiero enviar una invitación por correo a un compañero, para que se una a mi workspace sin que yo comparta mi contraseña.
Como compañero invitado, quiero aceptar una invitación y definir mi propia contraseña, para tener mi propio acceso en lugar de uno compartido.
Como dueño de la cuenta, quiero ver qué invitaciones siguen pendientes, para poder reclamar a los que no se han unido.
Tres historias donde había una línea. Cada una es de pocos días de trabajo, cada una termina en algo que puedes mirar, y cada una tiene sus propios criterios de aceptación. Cuando el equipo las cotiza, puedes decidir que “ver invitaciones pendientes” es deseable y quitarla para llegar a una fecha. No habrías podido tomar esa decisión sobre “dejar que los usuarios inviten a compañeros”, porque no veías las costuras. Las buenas historias te dan costuras por donde cortar. Para eso sirven, en su mayor parte.
Historias así no flotan en el aire. Se apoyan en tu product backlog, ordenado por lo que importa, y suben hacia el panorama mayor que fijaste en tu documento de requisitos de producto. La historia es el átomo. El backlog es la molécula. El documento de requisitos es el compuesto.
Escribe menos, escríbelas más apretadas
El instinto, cuando aprendes el formato, es escribir cuarenta historias en un fin de semana y entregar una pila. No lo hagas. Una pila de historias vagas es peor que ninguna, porque le da a todos una falsa confianza de que el pensamiento está hecho. No lo está. Las historias vagas son de lo que el scope creep está hecho de verdad: la expansión silenciosa de “gestionar mi cuenta” en siete pantallas, descubierta una factura cada vez.
Escribe las cinco o seis historias de la próxima rebanada de trabajo. Haz que cada una pase las cuatro pruebas. Dale a cada una criterios de aceptación que te sentirías cómodo exigiendo. Después conversa sobre ellas con quien construye, porque la tarjeta siempre fue una promesa de tener esa conversación. Haz eso y la historia cumple su papel de verdad, que no es documentación ni proceso. Es mantener la cosa que se construye y la cosa que imaginaste en la misma sala.
Preguntas frecuentes
¿Cuáles son las 3 C de una historia de usuario?
Tarjeta, Conversación y Confirmación (Card, Conversation, Confirmation). La Tarjeta es la historia de una línea. La Conversación es la discusión entre tú y el equipo sobre lo que de verdad significa. La Confirmación son los criterios de aceptación que definen “terminado”. El formato viene de Ron Jeffries, uno de los autores del Extreme Programming, y recuerda que la frase es un punto de partida, no el acuerdo entero.
¿Qué es un ejemplo de historia de usuario?
“Como comprador primerizo, quiero cambiar la dirección de correo de mi cuenta, para seguir recibiendo avisos de pedido después de cambiar de trabajo.” Nombra a un usuario concreto, una sola acción concreta y la razón detrás. Compáralo con “Como usuario, quiero gestionar mi cuenta”, que no nombra a nadie, describe un área entera de funcionalidad y no se puede cotizar ni rechazar.
¿Qué es un template de historia de usuario?
El template estándar es: Como [tipo de usuario], quiero [hacer algo], para [obtener algún beneficio]. Rellena las tres casillas. Si la casilla del medio contiene “y”, “gestionar” o “soportar”, casi con seguridad tienes más de una historia y deberías dividirla.
¿Cuáles son las 5 W en las historias de usuario?
Quién, qué, cuándo, dónde y por qué (who, what, when, where, why). En la práctica, un fundador es dueño de tres: para quién es la historia, qué quiere hacer la persona y por qué importa. El cuándo y el dónde (qué pantalla, qué estado, qué caso límite) se resuelven en la conversación con quien construye, y quedan fijados en los criterios de aceptación.
¿Qué es la regla 3-5-3 en ágil?
Se refiere a la estructura de Scrum: 3 roles, 5 eventos y 3 artefactos. Trata de cómo se organiza un equipo de Scrum, no de cómo escribir una historia, así que es una pregunta distinta de esta. Si estás contratando un desarrollo en lugar de llevar tú mismo el equipo, el formato de historia de arriba te importa mucho más que el conteo de ceremonias.