Los formatos de las historias de usuario: más allá de los estándares populares

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

1. La historia de las historias de usuario. Lucho Salazar.
2. De Colección: Ejemplos de Historias de Usuario de la Fuente: Los Libros de Extreme Programming (XP)
3. How to Implement Hypothesis-Driven Development. Barry O'Reilly
4. Historias de usuario: Una visión pragmática (Spanish Edition)
5. Modos de Representación de las Historias de Usuario - Un Capítulo del Libro Historias de Usuario una Visión Pragmática.
6. What's in a Story?. Dann North.
7. Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.
8. Pichler, Roman. Agile Product Management with Scrum. Addison-Wesley, 2010.
9. Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley, 2004.

Frase: Actuando en tiempos de cambio

---

"El mayor peligro en tiempos turbulentos no es la turbulencia, es actuar con la misma lógica que antes."

-Peter Drucker

---

La necesidad del pensamiento Lean en la era de la GenAI: un enfoque hacia las historias de usuario

Hola a todos,

La inteligencia artificial generativa (GenAI) ha transformado significativamente el proceso de generación e identificación de historias de usuario (HU). Antes, construir una historia de usuario requería sesiones de descubrimiento, múltiples interacciones con los interesados y refinamiento iterativo con el equipo de desarrollo. Aunque estas sesiones siguen siendo esenciales para garantizar una alineación con las necesidades reales del usuario, la GenAI ha simplificado y acelerado el proceso al capturar múltiples puntos de vista clave, sintetizarlos y generar rápidamente una lista estructurada de épicas, características esenciales del producto e historias de usuario relevantes. Con un prompt bien diseñado, también puede proporcionar criterios de aceptación detallados e incluso generar el código base necesario para su implementación (1).

Automatización y eficiencia en la construcción de historias de usuario

Gracias a la GenAI, no solo podemos generar historias de usuario más rápido, sino que también podemos obtener el código que resuelve la funcionalidad requerida casi de inmediato. Esto significa que la velocidad de desarrollo ha aumentado drásticamente, pero al mismo tiempo, han surgido nuevos riesgos y desafíos que pueden comprometer la efectividad del producto final (2).

Sin embargo, la velocidad no es sinónimo de precisión., de nada sirve ir a 200 km/h en la dirección incorrecta, es preferible dirección y precisión sobre velocidad. La GenAI, aunque útil para agilizar procesos, no reemplaza la interacción humana ni la validación con usuarios reales. Es fácil caer en la trampa de creer que, porque la IA genera respuestas convincentes y completamente acertadas, recordemos que los modelos de GenAI tiene una precisión cercana (a hoy del 99%) (5). Pero la realidad es otra: un producto verdaderamente exitoso no solo debe ser funcional, sino que debe resonar con sus usuarios, ser intuitivo y sentirse como una extensión natural de su flujo de trabajo (3).

En Apple, el diseño se basa en una premisa clara: eliminar todo lo que no sea esencial. Un producto verdaderamente excepcional no es aquel que tiene más características, sino aquel que resuelve necesidades de la manera más elegante y precisa posible (4).

El peligro de la sobreconstrucción y la desconexión con el usuario

Uno de los mayores riesgos que enfrentamos en esta nueva era de automatización e inteligencia es la tendencia a construir más de lo que realmente se necesita. La facilidad con la que la GenAI genera código y funcionalidades puede llevarnos a desarrollar características que no son esenciales, simplemente porque es fácil hacerlo. Sin una adecuada priorización basada en las necesidades reales del usuario, podemos terminar creando productos saturados de opciones innecesarias, en lugar de soluciones minimalistas y funcionales que realmente resuelvan sus problemas (1).

Otro peligro latente es la falta de comunicación con el usuario. La GenAI puede simular el comportamiento de un usuario a través de perfiles de "Personas" creados mediante técnicas de Design Thinking (3). Un prompt como:

Contexto: Vamos a generar una app para los guardabosques, y vas a responder como si fueras un guardabosques de más de 10 años de experiencia. A continuación, te haré preguntas que me guiarán en el diseño de un producto que mejorará tu forma de gestionar el bosque que estás cuidando.

"Vamos a generar una app para guardabosques, y vas a responder como si fueras un guardabosques de más de 10 años de experiencia. A continuación, te haré preguntas que me guiarán en el diseño de producto que mejorará tu forma de gestionar el bosque que estás cuidando."

puede ayudar a capturar información valiosa, sin dudarlo. Sin embargo, aunque esto sirve, es indudable que tiene limitaciones. Nada sustituye las entrevistas reales, la observación en el campo y la empatía directa con quienes usarán el producto. Un diseño exitoso no es aquel que solo responde a suposiciones bien estructuradas, sino aquel que emerge de la interacción genuina con los usuarios reales (4).

La importancia del diseño centrado en el usuario y la medición del impacto

El éxito en esta nueva era dependerá de quién logre conectarse verdaderamente con los usuarios y utilice el potencial de la GenAI para construir productos alineados con sus expectativas reales (2). Empresas como Apple han demostrado que la simplicidad y la precisión en el diseño generan una experiencia de usuario superior (3). Los consumidores buscan productos que resuelvan sus necesidades de manera intuitiva, sin saturación ni funcionalidades innecesarias. En este sentido, herramientas como A/B Testing y el análisis de métricas de uso se vuelven indispensables para validar continuamente la utilidad de las funcionalidades implementadas (1).

Las empresas que no adopten este enfoque y se dediquen a saturar a los usuarios con opciones irrelevantes verán cómo el mercado elige la perfección sobre la sobrecarga. Sin una estrategia de medición y ajuste basada en el comportamiento real de los usuarios, muchas organizaciones podrían quedar desconcertadas al ver que sus productos no son elegidos, sin entender que la razón fundamental fue la falta de alineación con las necesidades del cliente (4).

¿Es esta historia de usuario necesaria o es desperdicio?

Para evitar la sobrecarga de funcionalidades innecesarias, los Product Owners y los equipos ágiles deben evaluar rigurosamente cada historia de usuario antes de desarrollarla. A continuación, algunas preguntas clave que pueden ayudar en esta validación:

1. ¿Cuál es el problema real que esta historia resuelve?

   • Si no puedes identificar claramente un problema que impacte negativamente al usuario, es posible que esta historia sea innecesaria.

2. ¿Esta funcionalidad alinea con los objetivos del producto?

   • Una historia de usuario debe contribuir a la visión del producto. Si no lo hace, podría ser un desperdicio de recursos.

3. ¿Esta historia de usuario tiene métricas de éxito definidas?

   • Si no hay una manera clara de medir su impacto, ¿cómo sabremos si fue útil?

4. ¿Qué impacto tendría si no se desarrolla esta historia?

   • Si el producto aún funciona perfectamente sin ella, probablemente no es prioritaria.

5. ¿La funcionalidad generará fricción en la experiencia del usuario?

   • Más opciones no siempre son mejores. A veces, menos es más.

6. ¿Cuántos usuarios realmente la necesitan?

   • Si la funcionalidad es relevante solo para un nicho muy reducido, podría ser mejor posponerla o encontrar una alternativa más general.

7. ¿Es una funcionalidad que puede validarse con un experimento rápido?

   • Antes de construirla completamente, ¿podemos hacer un test de baja fidelidad para ver si realmente se usa?

Un producto bien diseñado es aquel que parece haber leído la mente del usuario, eliminando lo innecesario y dejando solo lo esencial. Si cada historia de usuario se filtra a través de estas preguntas, el backlog estará compuesto solo por elementos que realmente aportan valor.

El rol del Product Owner en la era de la GenAI

A pesar de la automatización que permite la GenAI, el papel del Product Owner (PO) sigue siendo crucial. No basta con generar funcionalidades rápidamente; es necesario identificar qué sí y qué no hacer, qué agrega y qué no agrega valor (2). El PO es quien tiene la responsabilidad de ordenar y priorizar el backlog, asegurando que el producto final no solo cumpla con las necesidades funcionales, sino que logre la perfección oculta en el imaginario del usuario (3).

Cuando un usuario interactúa con un producto bien diseñado, experimenta una sensación de esbeltez y perfección. No se trata solo de que el producto funcione, sino de que se sienta preciso, exacto, como si hubiera sido diseñado específicamente para ellos (1). Esa sensación no se logra con cantidad, sino con calidad,  atención al detalle (4) y a la eliminación de cualquier forma de desperdicio.

Cerrando

La GenAI es una herramienta poderosa que, bien utilizada, puede revolucionar la manera en que diseñamos y desarrollamos productos. Sin embargo, su éxito dependerá de nuestra capacidad para combinar la automatización con un enfoque genuinamente centrado en el usuario, evitando la trampa de construir más por el simple hecho de que podemos hacerlo. Aquellos que comprendan esto y logren equilibrar la velocidad con la precisión y la esbeltez serán quienes dominen esta nueva era digital+ai.

Saludos ágiles, 

Jorge Abad

Notas, aclaraciones, referencias y comentarios

1. Ries, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011.
2. Norman, Donald A. The Design of Everyday Things. Basic Books, 2013.
3. Brown, Tim. Change by Design: How Design Thinking Creates New Alternatives for Business and Society. Harper Business, 2009.
4. Blank, Steve. The Four Steps to the Epiphany: Successful Strategies for Startups That Win. K&S Ranch, 2013.
5. Hughes Hallucination Evaluation Model (HHEM) leaderboard - https://huggingface.co/spaces/vectara/leaderboard

Escribir Historias de Usuario para GenAI

Hola a todos,

En el desarrollo de aplicaciones basadas en Inteligencia Artificial Generativa (GenAI), la definición de historias de usuario juega un papel crucial para garantizar que los modelos entreguen valor real a los usuarios. A diferencia de las historias tradicionales de software, en GenAI debemos considerar aspectos como el procesamiento de lenguaje natural, la calidad de respuestas generadas y la iteración con datos reales.

Este artículo explora cómo escribir historias de usuario efectivas para proyectos de GenAI, incluyendo criterios de aceptación en prosa y en BDD (Behavior-Driven Development), casos de agentes inteligentes y estrategias para mantener el tiempo de desarrollo hasta preproducción en menos de 36 horas, que es el tiempo aproximado para construir una historia de usuario.

Estructura de una Historia de Usuario para proyectos o funcionalidades con GenAI

Las historias de usuario para GenAI pueden seguir la estructura popular:

Como [rol del usuario],
quiero [acción],
para [objetivo o beneficio].

Sin embargo, es fundamental incluir:

• Entradas esperadas: tipo de datos que el usuario proporcionará.
• Salidas esperadas: qué debe generar el modelo en respuesta, incluyendo la descripción y ejemplos de lo que se espera obtener.
• Criterios de calidad: precisión, relevancia y tiempos de respuesta (1).
• Limitaciones: alcance de la funcionalidad dentro del ciclo de desarrollo ágil.

Dado que los modelos de IA son probabilísticos, la validación de historias debe centrarse en métricas cuantificables y validaciones iterativas con usuarios.

Ejemplo 1: Generación de Resúmenes Automáticos

Como usuario de un sistema de análisis de documentos,
quiero que la IA genere un resumen preciso de un documento PDF,
para poder extraer información clave rápidamente.

Criterios de Aceptación en Prosa

• El resumen debe reducir el contenido original en al menos un 70% manteniendo coherencia.
• Debe extraer y sintetizar los puntos clave sin omitir información esencial.
• El tiempo de respuesta no debe superar los 5 segundos por página procesada.
• La salida debe estar estructurada en párrafos y permitir correcciones manuales por parte del usuario.

Criterios de Aceptación en BDD (gherkin)

Escenario: Generación exitosa de un resumen  

• Dado un documento PDF de más de 10 páginas  
• Cuando el usuario solicita un resumen  
• Entonces el sistema genera un texto condensado  
• Y el contenido preserva los puntos clave  
• Y el tiempo de procesamiento no supera los 5 segundos por página 

¿Qué es RAG y por qué importa en historias de usuario?

RAG (Retrieval-Augmented Generation) combina recuperación de información con modelos generativos para mejorar la precisión de las respuestas. En lugar de depender solo del conocimiento estático del modelo, RAG consulta una base de datos de documentos relevantes en tiempo real.

Cuando escribimos historias de usuario para sistemas basados en RAG, debemos considerar:

• Cómo se selecciona la información relevante (método de recuperación).
• Cómo se combinan los datos recuperados con la generación de respuestas.
• Qué métricas de calidad asegurarán que la respuesta sea útil y precisa.

Ejemplo 2: Uso de RAG para Respuestas Basadas en Documentos

Como analista de servicio al cliente,
quiero que la IA consulte documentación técnica y genere respuestas a preguntas frecuentes,
para reducir el tiempo de búsqueda de información en manuales.

Criterios de Aceptación en Prosa

• La IA debe buscar respuestas en documentos actualizados antes de generar una respuesta.
• Si no encuentra información relevante, debe indicar que no tiene suficiente contexto.
• La confianza en la respuesta debe ser superior al 85%.
• El tiempo de respuesta no debe superar los 3 segundos.

Criterios de Aceptación en BDD

Escenario: Generación de respuestas con RAG

• Given un usuario con una consulta técnica 
• Cuando la IA recibe la pregunta 
• Entonces busca la información en la base de documentos 
• Y combina los datos encontrados con su modelo generativo
• Y genera una respuesta precisa con referencias And la respuesta tiene una confianza superior al 85%

Ejemplo 3: Uso de Embeddings para Búsqueda Semántica

Como investigador,
quiero encontrar artículos académicos relevantes mediante búsqueda semántica,
para acelerar la revisión de literatura sin depender de coincidencias exactas de palabras clave.

Criterios de Aceptación en Prosa

• El sistema debe utilizar embeddings para representar documentos en un espacio vectorial.
• La búsqueda debe devolver documentos semánticamente similares, no solo coincidencias exactas.
• Los resultados deben estar ordenados por relevancia en función de la consulta.
• El tiempo de respuesta no debe superar los 2 segundos.

Criterios de Aceptación en BDD

Escenario: Búsqueda semántica con embeddings   
Dada una consulta sobre inteligencia artificial  
Cuando el usuario realiza una búsqueda  
Entonces el sistema devuelve artículos relevantes  
Y la similitud semántica se basa en embeddings  
Y los resultados se ordenan por relevancia  

Ejemplo de Historia de Usuario con Agentes de IA Autónomos

Los agentes de IA pueden realizar tareas complejas en múltiples pasos, como recopilar información, tomar decisiones y ejecutar acciones en nombre del usuario. Al escribir historias de usuario para agentes, es clave definir:

• Cuándo deben actuar automáticamente y cuándo necesitan intervención humana.
• Cómo gestionan interacciones multi-turno.
• Cómo garantizan que sus decisiones sean explicables y verificables.

Ejemplo 4: Agente de Atención al Cliente con IA

Como usuario de una plataforma de servicio al cliente,
quiero que el chatbot GenAI me ayude a solucionar preguntas frecuentes,
para recibir respuestas rápidas sin esperar a un agente humano.

Criterios de Aceptación en Prosa

• El chatbot debe responder con un nivel de confianza del 85% o superior basado en su entrenamiento.
• Si la consulta es ambigua, debe solicitar aclaraciones en lugar de dar una respuesta incorrecta.
• Si la pregunta no está en la base de datos, debe redirigir a un agente humano.
• El tiempo de respuesta debe ser menor a 2 segundos.

Criterios de Aceptación en BDD (gherkin)

Escenario: Chatbot responde correctamente  

Dado un usuario con una consulta sobre facturación  
Cuando el usuario pregunta “¿Cuánto debo pagar este mes?”  
Entonces el chatbot responde con el monto exacto  
Y la respuesta tiene una confianza superior al 85%  
Y el tiempo de respuesta es menor a 2 segundos 

Ejemplo 5: Agente de IA para Gestión de Correo Electrónico

Como ejecutivo ocupado,
quiero que un agente de IA clasifique y responda automáticamente correos electrónicos,
para reducir el tiempo dedicado a la gestión del correo y poder dedicarme a otras tareas.

Criterios de Aceptación en Prosa

• La IA debe clasificar correos en categorías como "Urgente", "Esperando Respuesta" y "Para Leer Luego".
• Si detecta preguntas frecuentes, debe generar una respuesta basada en plantillas predefinidas.
• Para correos que requieren atención humana, debe sugerir respuestas sin enviarlas automáticamente.
• Debe mejorar con el tiempo en función del feedback del usuario.

Criterios de Aceptación en BDD

Eecenario: Clasificación automática de correos  
Dada una bandeja de entrada con correos nuevos  
Cuando el agente los procesa  
Entonces clasifica cada correo en una categoría adecuada  
Y sugiere respuestas para preguntas frecuentes  
Y envía solo aquellas que el usuario haya autorizado
  

Ejemplo 6: Agente de IA para Automatización de Tareas Repetitivas

Como gestor de proyectos,
quiero que un agente de IA genere reportes semanales automáticamente,
para reducir el tiempo dedicado a la creación manual de informes.

Criterios de Aceptación en Prosa

• El agente debe recopilar datos desde múltiples fuentes (JIRA, Notion, Google Sheets).
• Debe estructurar la información en un formato predefinido y visualmente claro.
• Si detecta anomalías en los datos, debe alertar al usuario en lugar de generar el informe sin verificación.
• El tiempo de generación no debe superar los 5 minutos.

Criterios de Aceptación en BDD

Escenario: Generación de reportes automatizados  
Dado un conjunto de datos de proyectos activos  
Cuando el agente ejecuta su proceso semanal  
Entonces recopila la información desde las fuentes disponibles  
Y genera un informe en el formato solicitado  
Y alerta al usuario si detecta anomalías  

Garantizando Historias de Usuario Pequeñas (≤36 horas hasta Preproducción)

Para garantizar que las historias de usuario sean pequeñas y manejables una buena práctica es que tomen menos de 36 horas desde que se realiza su análisis, se realiza su desarrollo, se ejecutan las pruebas y se hasta preproducción o el ambiente definido en la Definition of Done, para esto se sugiere  las siguientes estrategias:

1. Definir historias con alcance limitado

   • Enfocarse en una funcionalidad específica dentro del sistema.
   • Evitar historias demasiado generales o con dependencias complejas.

2. Validación rápida

   • Implementar pruebas automáticas con métricas de precisión.
   • Usar entornos de pruebas con datos reales desde el inicio.

3. Integración sencilla

   • Aprovechar APIs existentes en lugar de construir modelos desde cero.
   • Definir entradas y salidas claras para reducir ajustes manuales.

4. Despliegue incremental

• Probar en entornos de staging antes de la implementación en producción.
• Obtener feedback temprano de usuarios reales para ajustar modelos.

Ejemplo de Historia Pequeña y Ejecutable en ≤36 horas

Como editor de contenido,
quiero que la IA sugiera mejoras gramaticales en mi texto,
para mejorar la claridad sin cambiar el significado.

Criterios de Aceptación en Prosa

• La IA debe detectar errores gramaticales sin modificar el estilo del usuario.
• Las sugerencias deben incluir una explicación breve de cada corrección.
• El tiempo de procesamiento debe ser menor a 2 segundos por párrafo.

Conclusión

Las historias de usuario bien escritas son clave para garantizar el éxito de proyectos de GenAI. Para lograrlo, debemos:

• Definir claramente las entradas y salidas esperadas.
• Escribir criterios de aceptación en prosa o en BDD.
• Los agentes de IA pueden automatizar tareas repetitivas, pero requieren criterios de aceptación claros para garantizar su efectividad.
• Diseñar historias pequeñas y ejecutables en menos de 36 horas, permitiendo iteraciones rápidas y mejoras continuas.

Siguiendo estos principios, las organizaciones pueden desarrollar soluciones de GenAI más efectivas, ágiles y centradas en el usuario.

Saludos ágiles,

Jorge Abad

Notas:

1. En el ámbito de la inteligencia artificial y de la Inteligencia Artificial Generativa, existen un sinnumero de métricas para contextos y usos específicos tales como: F1score, Perplejidad (Perplexity - PPL),Exactitud BLEU (Bilingual Evaluation Understudy), ROUGE (Recall-Oriented Understudy for Gisting Evaluation), y un largo etcétera, por lo que se sugiere conocer estás metricas y hacer uso de ellas para garantizar coherencia y confiabilidad en los resultados.

De lo Complejo a lo Simple: Cómo la IA Está Reinventando el Desarrollo de Software

Marco Cynefin

Hola a todos,

Hace unos días, hablando con mi compañero de trabajo, Roberto Moraga, surgió una reflexión interesante: el desarrollo de software ha pasado de ser un proceso altamente complejo a volverse más simple, en gran parte gracias a la inteligencia artificial. Sin embargo, si bien las herramientas han evolucionado, el mercado (usuarios, consumidores, empresas y negocios) sigue siendo dinámico, incierto y cada vez más complejo. Entender las necesidades y traducirlas en soluciones sigue siendo un desafío estratégico, que marcos como Scrum y metodologías como XP buscan reducir a la interacción con una sola voz.

Después de conversar un rato, llegamos a la misma conclusión: el software ya no se construye de la misma manera que antes. Scrum fue diseñado para gestionar la complejidad del desarrollo de software inicialmente, permitiendo a los equipos adaptarse de manera iterativa y generar soluciones en entornos de incertidumbre y luego su alcance se amplió hacia soliciones en entornos complejos, sin importar si incluían software o no. Sin embargo, hoy en día, el proceso software es mucho más predecible, gracias a la inteligencia artificial, las mejoras en los procesos han aumentado entre un 40% y un 60%, o incluso más, en la generación de código, la validación y la utilización del talento en los equipos.

Esto nos llevó a unas preguntas clave: ¿qué va a pasar con Scrum en el desarrollo de sofware? Si este se ha vuelto más automatizado y eficiente,  ¿Cómo afecta la IA a los marcos ágiles, metodologías ágiles?¿El escalamiento (es decir muchos equipos ágiles) seguirá igual o cambiará al emplear estas nueva tecnología?. Una aproximación para responder a estas preguntas, se plantearán en este artículo.

El desarrollo de software antes de la IA

El desarrollo de software siempre ha sido un ejercicio de lidiar con la complejidad. Antes de la llegada de la Inteligencia Artificial (IA) generativa, la construcción de software requería múltiples iteraciones, idas y venidas con el cliente, reuniones de refinamiento y planificación, pruebas constantes y ajustes sobre la marcha. Era un proceso artesanal en el que cada pieza de código debía encajar perfectamente en un entramado ya existente, con una complejidad que crecía exponencialmente con cada nueva funcionalidad.

Con la llegada de los marcos ágiles, esta complejidad se empezó a gestionar de manera más efectiva. En Scrum y XP por ejemplo, los equipos reducían la incertidumbre fragmentando el trabajo en historias de usuario pequeñas, cada una encapsulada dentro de un timebox de dos semanas (1). Por otro lado, Kanban ofrecía flujos de trabajo más cortos y continuos para optimizar la entrega (2). La clave estaba en la descomposición y la priorización: si algo no llegaba a desarrollarse, al menos lo más valioso ya estaba en producción.

¿Por qué el desarrollo de software es complejo?

El software no es solo líneas de código. Es una red interconectada de dependencias, reglas de negocio, infraestructura, bases de datos y lógica distribuida. Su complejidad crece con cada nueva funcionalidad porque:

• La cantidad de código crece exponencialmente: Cada nueva línea interactúa con muchas otras, lo que hace que el sistema se vuelva más difícil de comprender y modificar (3).
• Las dependencias se multiplican: Los sistemas modernos no son aplicaciones monolíticas; dependen de APIs, microservicios y plataformas en la nube (4).
• Las reglas de negocio son cambiantes: Lo que hoy es válido, mañana puede cambiar por una nueva regulación, requerimiento de usuario o innovación del mercado.
• Las expectativas de los usuarios evolucionan: Lo que antes tomaba meses ahora se espera en semanas o días.

Dave Snowden, con su marco Cynefin, nos dice que un problema puede estar en distintos dominios: simple, complicado, complejo o caótico (5). Durante décadas, el desarrollo de software ha habitado en la zona de lo complejo, donde la relación causa-efecto solo se entiende en retrospectiva, y donde la experimentación y la iteración eran la única forma de avanzar.

¿Cómo la IA ha simplificado el desarrollo de software?

La IA generativa está moviendo el desarrollo de software del espacio de lo complejo al de lo complicado e incluso a la frontera con lo simple. ¿Cómo?

• Generación automática de código: Hoy en día, un desarrollador puede describir en lenguaje natural qué necesita y herramientas como Copilot o ChatGPT pueden generar código funcional en segundos (6).
• Automatización de pruebas: La IA puede crear, ejecutar y ajustar pruebas unitarias y de integración sin intervención humana (7).
• Refactorización asistida: Lo que antes requería semanas de análisis, hoy se puede hacer en minutos con IA sugiriendo mejoras y optimizando código (8).
• Mayor velocidad en el desarrollo: Ahora es posible generar prototipos funcionales en horas, lo que antes tomaba semanas.

Esto ha cambiado radicalmente el flujo de trabajo. Antes, un equipo de desarrollo tenía que construir cada pieza de código manualmente y validarla en iteraciones cortas. Hoy, la IA permite automatizar gran parte de ese trabajo, transformando el proceso en algo más cercano a un modelo de entrega continua, donde Kanban empieza a ser una herramienta de gestión más efectiva que Scrum (9).

¿Qué pasa con el escalamiento?

El desarrollo de software no solo se ha vuelto más rápido con la IA, sino que también ha impactado la forma en que las organizaciones gestionan el escalamiento. Antes, uno de los mayores desafíos en la escalabilidad era la gestión de dependencias entre equipos: ¿Quién trabaja en qué? ¿Qué bloquea a quién? ¿Cuándo estará disponible una funcionalidad que otro equipo necesita?

Con ciclos de desarrollo más cortos gracias a la IA, los equipos están generando software a una velocidad nunca antes vista. Esto significa que los cuellos de botella ya no están en la escritura del código, sino en la coordinación entre equipos.

La nueva gestión de dependencias

Cuando la generación de código deja de ser un problema, la conversación cambia:

• Los equipos hablarán más de dependencias y lo harán más rápido, porque llegarán a ellas en menos tiempo.
• La gestión proactiva de dependencias es clave, porque ahora los bloqueos pueden detener desarrollos que, de otro modo, habrían estado listos en cuestión de horas.
• Los gestores de flujo de trabajo (Scrum Masters, Agile Coaches, facilitadores) deberán anticipar y resolver estas dependencias con más rapidez que nunca.

Esto tendrá un impacto directo en los marcos de escalamiento ágiles como SAFe, LeSS, Nexus y Spotify Model. Tradicionalmente, estos marcos han tratado las dependencias con eventos de sincronización como el PI Planning (SAFe) o los eventos de coordinación en LeSS. Pero en un entorno donde los equipos avanzan más rápido, estas cadencias predefinidas pueden volverse insuficientes. Y es allí donde toma valor la gestión impecable de las dependencias, que es la forma como trabaja Amazon, que logra escalar sientos de equipos sin necesidad de eventos de coordinación.

Cerrando: De la complejidad a la simplicidad

El desarrollo de software ya no es un proceso 100% artesanal. Las historias de usuario siguen funcionando como método de comunicación con el cliente, pero la ejecución es más ágil que nunca. Algunas funcionalidades pueden construirse de manera casi instantánea, moviendo el desarrollo del espacio complejo al complicado, o incluso a lo simple, cuando la IA puede resolverlo sin intervención humana.

La IA ha cambiado el juego. Ahora, la clave no es escribir código más rápido, sino enforcarnos en en entender mejor el negocio y remover bloqueos con la misma o más velocidad que con la que producimos software.

Saludos ágiles,

Jorge Abad

Referencias

1. Schwaber, Ken, and Jeff Sutherland. The Scrum Guide. Scrum.org, 2020.
2. Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
3. McConnell, Steve. Code Complete: A Practical Handbook of Software Construction. Microsoft Press, 2004.
4. Lewis, James. Microservices: The Journey to Cloud Native. O'Reilly Media, 2019.
5. Snowden, Dave. Cynefin: Weaving Sense-Making into the Fabric of Our World. Cognitive Edge, 2020.
6. GitHub. "Introducing GitHub Copilot." GitHub Blog, 2021.
7. Agile Alliance. "Dependency Management in Agile Teams." Agile Alliance, 2022.