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>",
o una versión
mejorada y sugerida, que ayuda a identificar la población
con la que se realizará el experimento
:
-
"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.
