Hablemos de Métricas de Producto: Presentación Scrum latam.

Video Keynote Comunidad Scrum Latam: Principios sobre prácticas - Una fórmula mas allá de los frameworks

Hola a todos,

Hoy quiero compartirles una de las reflexiones más potentes que surgieron en el reciente keynote que compartí con mi amigo y colega Lucho Salazar: la necesidad urgente de dejar de recitar prácticas ágiles vacías y comenzar a liderar desde los principios. Esta charla, titulada “Principios sobre Prácticas: Una fórmula para ir más allá de los frameworks”, fue una sacudida para muchos… y con toda la intención.

Cuando la agilidad se convierte en rutina… hay que despertar

La agilidad nació como una respuesta a la rigidez. Sin embargo, muchas organizaciones han convertido sus prácticas ágiles en nuevos rituales sin alma. Daily Scrums que son reuniones de control, PI Plannings hechos por cumplir, equipos que siguen Scrum sin cuestionarse si sigue siendo útil. ¿Y lo más grave? Coaches y líderes que se aferran a estas prácticas porque “así lo dice el marco”.

En nuestra charla planteamos una idea sencilla pero poderosa:

Agilidad real = Principios + Contexto – Resistencia

Sí, una fórmula. No matemática, sino heurística. Un recordatorio de que los principios son la brújula que nos permite navegar cualquier entorno, incluso en tiempos de crisis e incertidumbre.

El entorno cambió… pero ¿y tú?

La Inteligencia Artificial, la disrupción digital, las expectativas cambiantes de clientes y empleados, todo está cambiando. ¿Por qué seguimos haciendo lo mismo de siempre?

Muchos de los frameworks actuales nacieron hace más de 20 años. ¿Sirven? Sí. ¿Son suficientes? No. Como dijimos en la charla:

“La receta de la abuela funcionó, pero los ingredientes de hoy son otros.”

Por eso, no se trata de desechar todo, sino de revisar, adaptar, reinventar. Una práctica no es sagrada. Lo sagrado es el propósito que persigue: entregar valor, colaborar, adaptarse, aprender.

Redescubrir la esencia: 16+ principios para una agilidad viva

Durante la charla, compartimos más de 16 principios que consideramos esenciales en este nuevo entorno. Algunos de ellos:

• Gestión impecable de dependencias

• Equipos pequeños, empoderados y en sinergia con el negocio

• Entrega temprana, continua y con excelencia técnica

• Transparencia radical

• Priorizar impacto sobre entregables

• Reflexión e inspección frecuente

• Reducción implacable del desperdicio

• Cultura de aprendizaje y mentalidad experimental

Estos principios no son nuevos. Lo que es nuevo es la urgencia de vivirlos.

La invitación: menos dogma, más discernimiento

Lucho lo decía con fuerza: “El marco perfecto es un mito que paraliza el cambio.”
Y yo agregaría: el verdadero agilista no es el que mejor repite, sino el que mejor interpreta.

Esta charla es una invitación a cuestionar. A salir de la comodidad del “así se hace”. A leer el entorno como un jardinero, entendiendo qué semillas sembrar, qué malas hierbas cortar y cómo adaptar nuestra forma de trabajar para que florezca el valor.

¿Y tú? ¿Qué tan libre eres para adaptar?

¿Tus prácticas sirven a tus principios… o ya son cárceles del conformismo?

Si quieres profundizar en esto, mira la presentación y el video abajo al finalizar este artículo.

Y recuerda:

“Los frameworks son puntos de partida, no de llegada.”

Saludos ágiles,
Jorge Abad

Notas, aclaraciones, referencias y comentarios:

• Presentación basada en el keynote “Principios sobre Prácticas” presentado por Jorge Abad y Lucho Salazar, abril de 2025.

• Las ideas centrales se desarrollan a partir del documento: Principios sobre prácticas - Keynote - V1.0.20250301.pdf y la transcripción completa del evento.

• Más información sobre el enfoque en principios: https://heartofagile.com

• Para citar este artículo, usar: Abad, Jorge. “Principios sobre prácticas: la agilidad más allá del marco.” Lecciones Aprendidas, mayo 2025.

---

---

Whitepaper: Maximizando el valor de la estrategia digital

Aprendiendo Agentes AI con n8n usando a ChatGPT como profesor

Podcast: Hormigas Agilistas - EP138 - La IA reinventa el desarrollo de SW, y retomando el podcast luego de un bajón…

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.