Hola a todos,
En el mundo ágil, a menudo se cree que las historias de usuario deben seguir un formato único y establecido. Sin embargo, la realidad es que no hay un solo formato universalmente correcto. La propuesta inicial era una petición de máximo un renglón (1). Nunca ha habido un formato oficial, lo que si ha existido, son propuestas muy usadas. La forma más clásica y ampliamente adoptada, es la propuesta por Rachel Davies y popularizada por Mike Cohn (2), se centra en quién usa el sistema, qué quiere lograr y por qué es importante:
- "Como <rol>,
- quiero <acción o funcionalidad>,
- para <beneficio de negocio>".
Ejemplos:
- Como comprador en línea, quiero poder filtrar productos por precio, para encontrar opciones dentro de mi presupuesto más rápidamente.
- Como gerente de recursos humanos, quiero recibir notificaciones cuando un nuevo empleado complete su documentación, para agilizar el proceso de incorporación.
- Como usuario de la aplicación de transporte, quiero poder calificar mi viaje después de llegar a mi destino, para mejorar la calidad del servicio.
¿Cuándo usarlo?
- Cuando se necesita claridad en el propósito de la historia.
- Para equipos nuevos en metodologías ágiles que aún están aprendiendo a formular historias de usuario.
Otro muy popular es el propuesto por Barry O'Reilly y conocido como Hypothesis Driven Development (desarrollo dirigido por hipotesis) (3):
- "Creemos que <hacer este cambio funcionalidad>,
- resultará en <impacto medible>,
- sabremos que habrá sucedido cuando <observemos este señal medible>",
- "Creemos que <hacer este cambio funcionalidad>,
- para <este grupo de usuarios>,
- resultará en/no impactará / impactará / aumentará/reducirá <impacto medible>,
- sabremos que habrá sucedido cuando <observemos este señal medible>"
- en/durante <una fecha determinada>,
Ejemplos:
- Creemos que permitir a los usuarios registrarse con su cuenta de Google, para nuevos visitantes del sitio web, resultará en un aumento de la tasa de registros en un 20% en dos semanas. Lo sabremos cuando la métrica de conversión pase de 25% a 45% en un tiempo máximo de 3 meses después de salir a producción.
- Creemos que ofrecer una opción de “modo oscuro” en nuestra aplicación, para usuarios frecuentes, resultará en una mejora en la retención semanal en un 10%. Lo sabremos cuando la retención W1-W2 pase de 30% a 33% en dos semanas luego del lanzamiento oficial.
- Creemos que aumentar el precio mensual de $10 a $12, para usuarios que han estado más de 3 meses suscritos, no impactará negativamente la tasa de renovación. Lo sabremos si la tasa de cancelación se mantiene bajo el 5%, durante el mes próximo del lanzamiento del cambio.
- Creemos que permitir ordenar los resultados por “más vendidos” para compradores indecisos, aumentará la conversión en un 15%. Lo sabremos si la tasa de clics en productos y las compras en esa categoría aumentan en ese porcentaje, en las próximas 4 semanas después del lanzamiento.
¿Cuándo usarlo?
- Estás creando un producto nuevo o una funcionalidad no probada.
- Hay mucha incertidumbre sobre el valor o la necesidad de lo que estás construyendo.
- Quieres reducir el riesgo de desarrollar algo que nadie usará.
- Tu organización valora el aprendizaje y la mejora continua.
- Estás en fases tempranas de descubrimiento o validación de mercado.
Las historias de usuario son un arte tanto como una técnica, y deben adaptarse a las necesidades específicas de cada organización, equipo y contexto. Lo esencial es que cumplan su propósito: capturar la necesidad de negocio desde la perspectiva del usuario, servir como una invitación a la conversación y permitir la colaboración para entregar valor incremental.
En este artículo exploraré varios formatos alternativos de historias de usuario que pueden resultar útiles en contextos diversos. Si bien en el libro de historias de usuario (4) y en este blog (5) ya habíamos analizado distintos modos de representación según la madurez del equipo, el nivel de regulación o la cultura organizacional en la que operan, en esta ocasión ampliaré la mirada hacia otras plantillas que también pueden ser efectivas y adaptables.
Avancemos entonces, y descubramos juntos estas nuevas propuestas.
Nota importante: las plantillas sugeridas, requieren de seguir cumpliendo la buena práctica de las 3C, cumplir con INVEST, e incluir criterios de aceptación, que se han enumerado bastantes veces en esta blog.
Algunos formatos sugeridos y sus posibles usos
1. El formato centrado en el problema: "Cuando – Entonces - Porque"
Este formato enfatiza el contexto y la causa raíz del problema que la historia intenta resolver.
Estructura:
- Cuando:[situación]
- Entonces: [acción]
- Porque: [motivación]
Ejemplos:
- Cuando el usuario agregue productos al carrito y cierre sesión sin comprarlos, entonces le enviaremos un recordatorio por correo electrónico, porque queremos aumentar la conversión de ventas.
- Cuando un usuario ingrese una contraseña incorrecta más de tres veces, entonces bloquearemos su cuenta temporalmente, porque queremos prevenir accesos no autorizados.
- Cuando el sistema de facturación detecte una inconsistencia en el número de documento del cliente, entonces alertaremos al equipo de soporte, porque queremos reducir los errores en la generación de facturas.
¿Cuándo usarlo?
- Cuando el equipo esté enfocado en resolver problemas específicos del usuario.
- En entornos donde se requiere justificar cada funcionalidad con un problema de negocio claro.
2. El formato inspirado en el comportamiento de BDD (Behavior Driven Development) (6): "Dado que – Cuando – Entonces"
Muy útil en historias de usuario que son de eventos o cuando se necesita precisión en cómo se comportará una funcionalidad. Se sugiere que sus criterios de aceptación sean en prosa.
Estructura:
- Dado que: [contexto],
- Cuando: [acción],
- Entonces: [resultado]
Ejemplos:
- Dado que un usuario ha ingresado una dirección de correo electrónico no verificada, cuando intente iniciar sesión, entonces se le pedirá que confirme su correo antes de continuar.
- Dado que un pago con tarjeta puede fallar por diversos motivos, cuando el intento de pago falle, entonces el sistema debe mostrar el mensaje adecuado según el código de error del proveedor de pagos.
- Dado que el usuario puede realizar múltiples solicitudes de soporte, cuando una solicitud sea resuelta, entonces se enviará una encuesta de satisfacción al usuario.
¿Cuándo usarlo?
- Para historias con criterios de aceptación claros.
- En historias de usuario que están indicando eventos en el sistema.
- En desarrollo de software donde las reglas de negocio son críticas.
3. El formato “Necesidad – Solución – Valor”
Este formato es ideal cuando se quiere conectar claramente el problema, la propuesta y el beneficio entregado.
Estructura:
- Necesidad: [Qué se necesita].
- Solución: [Qué se propone].
- Valor: [Qué se gana].
Ejemplos:
-
Necesidad: Los usuarios necesitan hacer seguimiento de sus gastos mensuales.
Solución: El sistema ofrece un panel con gráficos de gasto por categoría.
Valor: Los usuarios pueden tomar decisiones financieras informadas. -
Necesidad: Los vendedores necesitan saber qué clientes tienen más potencial.
Solución: Algoritmo de puntuación basado en historial de compras.
Valor: Mejora la eficiencia comercial y priorización de esfuerzos. -
Necesidad: El área legal necesita acceder rápidamente a contratos archivados.
Solución: Búsqueda avanzada con filtros por fecha, cliente y tipo.
Valor: Ahorro de tiempo y reducción de errores administrativos.
¿Cuándo usarlo?
- Cuando se busca justificar una funcionalidad ante stakeholders.
- En roadmaps donde se prioriza por impacto en negocio.
4. El formato “Evento – Respuesta – Valor”
Este formato ayuda a detallar cómo el sistema debe comportarse ante eventos específicos.
Estructura:
- Evento: [Qué lo desencadena].
- Respuesta: [Qué hace el sistema].
- Valor: [Por qué esto es útil].
Ejemplos:
-
Evento: Un usuario introduce credenciales erróneas tres veces.
Respuesta: El sistema bloquea temporalmente la cuenta y envía una alerta.
Valor: Protección contra accesos no autorizados. -
Evento: Se confirma el pago de una factura.
Respuesta: Se actualiza automáticamente el estado en el ERP.
Valor: Reducción de tareas manuales y errores contables. -
Evento: Se detecta una caída en el rendimiento del sistema.
Respuesta: Se dispara una alerta al equipo de DevOps.
Valor: Reacción temprana ante posibles incidentes críticos.
¿Cuándo usarlo?
- En sistemas reactivos o eventos disparadores.
- En plataformas con necesidad de respuestas automáticas ante condiciones de negocio.
5. Historias de usuario con “Job Stories”
Las Job Stories se centran en la situación, la motivación y el resultado, dejando de lado el “rol”.
Estructura:
- Cuando [situación],
- quiero [motivación],
- para que [resultado esperado].
Ejemplos:
- Cuando estoy fuera de la oficina, quiero aprobar facturas desde el móvil, para que los pagos no se retrasen.
- Cuando tengo poco tiempo, quiero ver un resumen de métricas clave, para tomar decisiones rápidamente.
- Cuando recibo muchas notificaciones, quiero filtrarlas por prioridad, para enfocarme en lo más importante.
¿Cuándo usarlo?
- En entornos donde el contexto de uso es más importante que el rol.
- En descubrimiento de producto centrado en comportamiento del usuario.
6. El formato “Sentimiento – Necesidad – Solución – Beneficiario”
Este formato incorpora la emoción inicial, que es clave en diseño centrado en el usuario.
Estructura:
- Sentimiento: [Cómo se siente el usuario].
- Necesidad: [Qué requiere].
- Solución: [Qué se le ofrece]
- Beneficiario: [Personas que se benifician de la solución, no siempre es el usuario que hace clic, en ocasiones podrá ser alguien del backend, o cliente interno de la solución"
Ejemplos:
- Sentimiento: Frustrado por la lentitud del proceso de pago.
- Necesidad: Un checkout más ágil.
- Solución: Pago con un solo clic.
- Beneficiario: usuario comprador
- Sentimiento: Inseguro sobre la calidad de un producto.
- Necesidad: Opiniones de otros compradores.
- Solución: Mostrar reseñas verificadas.
- Beneficiario: comprador de la tienda
- Sentimiento: Ansioso por confirmar la reserva de su vuelo.
- Necesidad: Verificación inmediata.
- Solución: Correo con QR y confirmación automática.
- Beneficiario: viajero de la aerolínea
¿Cuándo usarlo?
- En diseño de experiencia de usuario (UX).
- Cuando se desea empatizar con el dolor del usuario.
7. El formato “Deseo – Acción – Satisfacción”
Este formato está inspirado en la motivación humana: qué desea, qué hace, qué obtiene.
Estructura:
- Deseo: [Qué quiere].
- Acción: [Qué hace].
- Satisfacción: [Qué logra].
Ejemplos:
-
Deseo: Sentirme seguro al comprar en línea.
Acción: Uso un método de pago confiable.
Satisfacción: Compro con tranquilidad. -
Deseo: Ser productivo durante reuniones.
Acción: Tomo notas con ayuda de una IA.
Satisfacción: Puedo revisar y compartir de forma eficiente. -
Deseo: Encontrar el mejor producto sin perder tiempo.
Acción: Uso un comparador de productos.
Satisfacción: Elijo lo mejor según mis necesidades.
¿Cuándo usarlo?
- En productos con fuerte componente emocional.
- Cuando se quiere visualizar claramente la satisfacción del usuario como resultado.
8. El formato “Contexto – Sentimiento – Acción – Resultado – Emoción”
Una evolución del clásico formato de flujo, que introduce las emociones como parte esencial de la historia.
Estructura:
- Contexto: [Situación].
- Sentimiento: [Emoción inicial].
- Acción: [Qué hace].
- Resultado: [Qué obtiene].
- Emoción final: [Qué siente después].
Ejemplos:
-
Contexto: El usuario está haciendo una compra online.
Sentimiento: Se siente abrumado por tantas opciones.
Acción: Usa la función de comparación de productos.
Resultado: Ve una tabla clara de diferencias.
Emoción: Se siente aliviado y confiado al elegir. -
Contexto: El colaborador quiere pedir vacaciones.
Sentimiento: Está confundido por el proceso.
Acción: Utiliza un asistente paso a paso.
Resultado: Solicita fácilmente sus días.
Emoción: Se siente tranquilo y comprendido. -
Contexto: El usuario busca soporte técnico.
Sentimiento: Está frustrado por un error recurrente.
Acción: Usa el chatbot para resolver el problema.
Resultado: El problema se soluciona en 2 minutos.
Emoción: Siente satisfacción y fidelidad con el servicio.
¿Cuándo usarlo?
- En productos orientados a experiencia y emoción del usuario.
- Para lograr empatía en equipos multidisciplinarios.
9. El formato “Regla de Negocio – Comportamiento – Resultado Esperado”
Este formato es útil cuando se requiere modelar decisiones automáticas del sistema basadas en reglas de negocio bien definidas. Aporta precisión y trazabilidad en entornos donde las políticas o condiciones deben cumplirse de manera estricta.**
Estructura:
- Regla: [Condición o política de negocio].
- Comportamiento: [Qué debe hacer el sistema].
- Resultado esperado: [Qué debe pasar].
Ejemplos:
- Regla: Si el cliente tiene más de 3 meses de mora.
- Comportamiento: Bloquear automáticamente nuevos créditos.
- Resultado esperado: Se genera una alerta y se deniega la solicitud.
- Regla: Si la fecha de vencimiento del contrato está próxima a 15 días.
- Comportamiento: Enviar notificación automática al responsable.
- Resultado esperado: El contrato es renovado a tiempo o gestionado oportunamente.
- Regla: Si un pedido contiene productos de más de un proveedor.
- Comportamiento: Separar el pedido en órdenes independientes por proveedor.
- Resultado esperado: Cada proveedor recibe la orden correspondiente sin errores de reparto.
¿Cuándo usarlo?
- En funcionalidades que dependen de reglas de negocio bien definidas.
- En contextos donde se busca automatizar decisiones basadas en políticas.
- Para equipos que trabajan con lógica condicional, procesos de backoffice o gestión de riesgos.
Comparativo de formatos de historias de usuario
| Formato | Estructura | Ventaja principal | ¿Cuándo usarlo? |
|---|---|---|---|
| Formato clásico | Como <rol>, quiero <acción>, para <beneficio> | Claridad de propósito | Para equipos nuevos o cuando se necesita claridad en el valor entregado |
| Desarrollo dirigido por hipótesis (HDD) | Creemos que <acción>, para <grupo>, resultará en <impacto>. Lo sabremos cuando <métrica> cambie, en <cuándo deberá suceder> | Fomenta validación y aprendizaje | Innovaciones, funcionalidades nuevas o inciertas |
| Cuando – Entonces – Porque | Cuando <situación>, entonces <acción>, porque <motivación> | Explora la causa raíz del problema | Problemas específicos con justificación de negocio clara |
| Dado – Cuando – Entonces (BDD) | Dado que <contexto>, cuando <acción>, entonces <resultado> | Claridad para escenarios de negocio | Eventos del sistema y reglas de negocio críticas |
| Necesidad – Solución – Valor | Necesidad: <qué se necesita>. Solución: <qué se propone>. Valor: <qué se gana> | Conecta problema, solución y beneficio | Justificación de funcionalidades ante stakeholders |
| Evento – Respuesta – Valor | Evento: <detonante>. Respuesta: <comportamiento>. Valor: <impacto> | Describe reacciones automáticas | Sistemas reactivos, seguridad o monitoreo |
| Job Stories | Cuando <situación>, quiero <motivación>, para que <resultado> | Contextualiza más allá del rol | Descubrimiento de producto y uso real |
| Sentimiento – Necesidad – Solución – Beneficiario | Sentimiento: <emoción>. Necesidad: <problema>. Solución: <respuesta>. Beneficiario: <quién gana> | Conecta emoción con impacto | Diseño UX, experiencias empáticas |
| Deseo – Acción – Satisfacción | Deseo: <meta>. Acción: <interacción>. Satisfacción: <resultado> | Modelo motivacional claro | Funcionalidades que buscan generar confianza y bienestar |
| Contexto – Sentimiento – Acción – Resultado – Emoción | Contexto > Sentimiento > Acción > Resultado > Emoción | Incluye la emoción antes y después | Historias centradas en experiencia completa del usuario |
| Regla de Negocio – Comportamiento – Resultado Esperado | Regla: <condición de negocio>. Comportamiento: <acción del sistema>. Resultado esperado: <efecto> | Precisión en decisiones de negocio | Funcionalidades que reflejan reglas o políticas específicas |
Evalúa constantemente la utilidad del formato
No te cases con un solo formato. Si descubres que una plantilla no está funcionando para tu equipo o para un contexto de la funcionalidad del producto, ajusta el enfoque, ¡Simple!.
Ejemplo de una retro de historias de usuario
Preguntas a responder:
- ¿Las historias son claras y entendibles para todos los miembros del equipo?
- ¿Los criterios de aceptación han sido útiles para definir cuándo una historia está completa?
- ¿Se ha usado el formato adecuado en cada caso?
Tip: Ajusta las plantillas basándote en la retroalimentación del equipo.
Cerrando
No hay un único formato correcto para escribir historias de usuario. La clave es elegir el formato que mejor se adapte al contexto de la organización y del equipo. Más importante que la estructura es garantizar, la conversación durante el proceso de construcción y que las historias sean pequeñas (menos de 36 horas de trabajo), claras y centradas en generar valor.
Además, con la llegada de la Inteligencia Artificial Generativa (GenAI), el proceso de creación y refinamiento de historias de usuario está evolucionando, permitiendo que los equipos sean más eficientes sin perder el enfoque en la entrega de valor.
No se trata de seguir un molde, sino de asegurarnos de que las historias cumplan su propósito: alinear a los equipos, generar conversaciones efectivas y entregar soluciones valiosas.
¿Y si tu equipo diseñara su propio formato de historias de usuario? ¿Cómo se vería?
Saludos ágiles,
Jorge Abad
Notas, aclaraciones, referencias y comentarios
- La historia de las historias de usuario. Lucho Salazar.
- De Colección: Ejemplos de Historias de Usuario de la Fuente: Los Libros de Extreme Programming (XP)
- How to Implement Hypothesis-Driven Development. Barry O'Reilly
- Historias de usuario: Una visión pragmática (Spanish Edition)
- Modos de Representación de las Historias de Usuario - Un Capítulo del Libro Historias de Usuario una Visión Pragmática.
- What's in a Story?. Dann North.
- Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.
- Pichler, Roman. Agile Product Management with Scrum. Addison-Wesley, 2010.
- Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley, 2004.
