Quality Coach: Evaluando la Calidad de tus User Stories con IA (Artículo 5 de 7)
Serie Gemba: AI Mercadona User Story Framework — Puntuación 6D y detección de antipatrones en user stories
Este es el Artículo 5 de una serie de 7 sobre el Marco de Historias de Usuario de IA Mercadona (AI Mercadona User Story Framework). Si aún no has leído los artículos anteriores, te recomendamos que comiences con:
Artículo 1: La investigación de DAPP como puerta de entrada al desarrollo impulsado por evidencia
Artículo 2: Cómo transformar brechas de investigación en hipótesis de Jobs-to-be-Done verificables
Artículo 3: De Jobs-to-be-Done a User Stories: El puente conceptual entre investigación y ejecución
Artículo 4: El constructor de historias de usuario: cómo escribir desde cero
En este artículo, abordaremos el desafío que enfrenta cualquier organización de tecnología con múltiples equipos: ¿cómo asegurar consistencia en la calidad de las historias de usuario cuando tienes 12 verticales, decenas de historias por sprint, y cada Product Manager trae su propia intuición sobre qué es “bueno”?
La respuesta no es delegar la evaluación completamente al framework, ni tampoco ignorar el juicio humano experto. Es, en su lugar, crear un sistema compartido de evaluación que sea simultáneamente riguroso y accesible, que eleve los estándares sin paralizar la ejecución, y que permita a los equipos aprender de los patrones que se repiten una y otra vez en el pipeline.
Bienvenidos al Entrenador de Calidad (Quality Coach).
El Problema Invisible de la Inconsistencia
Hace pocos meses, durante una reunión de revisión de backlogs, sucedió algo que probablemente reconocerás si trabajas en una organización con múltiples equipos de producto.
Un Product Manager presentó una historia de usuario que comenzaba así: “Como usuario, quiero poder ver mis pedidos previos para poder realizar compras más rápidas.” El equipo de ingeniería hizo preguntas técnicas sobre la arquitectura. El equipo de diseño preguntó sobre wireframes. Pero nadie hizo la pregunta más fundamental: ¿Sabemos realmente si esto resolverá el problema del usuario?
Cuando examinas esa historia con rigor, descubres que no hay evidencia de cuántos usuarios realmente abandonan el flujo de compra por esta razón, no se especifica cuál es el perfil exacto del usuario, la métrica de éxito es ambigua, y no hay plan para validar experimentalmente si la hipótesis era correcta.
Pero la historia fue aprobada de todas formas. Porque se veía “suficientemente buena.”
En Mercadona Tech, con 12 verticales funcionando en paralelo y decenas de historias en cada sprint, esta inconsistencia se multiplica. El equipo de Checkout trabaja con un estándar de calidad. El equipo de Tienda trabaja con otro. El equipo de Primera Milla con otro diferente. No por incompetencia, sino porque no existe un framework compartido que defina qué es realmente “una buena historia de usuario.”
El Entrenador de Calidad (Quality Coach) existe para resolver exactamente esto: crear un sistema de evaluación que sea lo suficientemente riguroso para garantizar que las historias representen experimentos reales sobre comportamiento del usuario, pero lo suficientemente flexible para respetar el contexto, la urgencia y las realidades operativas de cada equipo.
La Filosofía: Calidad como Experimento, no como Checklist
Antes de sumergirnos en las seis dimensiones de evaluación, necesitamos establecer una premisa filosófica que guía todo el trabajo del Entrenador de Calidad.
La mayoría de los equipos evalúan historias de usuario usando un checklist: ¿Tiene un usuario? Sí. ¿Tiene un beneficio? Sí. ¿Es accionable? Sí. Siguiente.
Pero esto trata la historia como un artículo para entregar, no como una hipótesis para validar.
Jobs-to-be-Done, el framework que sustenta todo el marco de historias de usuario de IA Mercadona, nos enseña que el trabajo verdadero no es la característica que entregamos. El trabajo verdadero es el cambio de comportamiento que queremos producir en el usuario. Una vez que aceptas esa premisa, la pregunta sobre calidad cambia fundamentalmente.
Ya no preguntamos: “¿Está bien escrita?”
Preguntamos: “¿Es verificable como un experimento? ¿Podemos observar si el usuario realmente cambió su comportamiento de la manera que esperamos?”
Esta perspectiva viene del libro “50 Quick Ideas to Improve Your User Stories” de Gojko Adzic y David Evans, dos de los pensadores más influyentes en evolución del movimiento ágil. Su insight central es que una buena historia de usuario no es una promesa vaga, sino una hipótesis comprobable sobre cómo el usuario se comportará diferente después de que entregues la solución.
El Entrenador de Calidad formaliza esta filosofía en seis dimensiones medibles.
Las Seis Dimensiones de Evaluación
El Entrenador de Calidad evalúa cada historia de usuario en una escala de 0 a 10 en cada una de estas dimensiones. No es un enfoque de “pasar/fallar,” sino un sistema diagnóstico que te dice exactamente dónde están las debilidades de la historia y qué se necesita para fortalecerla.
Dimensión 1: Contexto JTBD y Evidencia del Problema
¿Realmente entendemos el trabajo que el usuario necesita hacer?
Esta es la dimensión más fundamental. Una historia que no está anclada en una comprensión profunda del trabajo del usuario es, en el mejor de los casos, un disparo a ciegas. En el peor, es trabajo que nadie quería hacer en primer lugar.
Una buena puntuación en esta dimensión requiere tres tipos de evidencia:
Primero, evidencia cualitativa: Observaciones directas de usuarios diciendo que necesitan hacer este trabajo. No es una encuesta. Es alguien en el campo viendo frustración real. Idealmente, esta evidencia viene del PRD, que a su vez proviene de investigación Mom Test (ver Artículo 1).
Segundo, evidencia cuantitativa con baseline y target: Si el trabajo es importante, debería ser observable en los datos. ¿Cuántos usuarios enfrentan este problema hoy? ¿Cuál es el baseline? ¿A qué número queremos llegar? Una historia sobre “mejorar la experiencia de búsqueda” podría tener un baseline de “40% de búsquedas no producen compra” con un target de “reducir a 25%.”
Tercero, observación del terreno (Gemba): Idealmente, alguien del equipo ha visitado el contexto real donde ocurre el trabajo. Si es un trabajo de logística, alguien estuvo en el almacén. Si es un trabajo de tienda, alguien estuvo en el punto de venta. Esto no siempre es posible, pero cuando es posible, proporciona insights que ningún análisis de datos puede dar.
Una historia con puntuación 9 en esta dimensión te dice exactamente por qué el trabajo importa, con números que lo respaldan, y con observaciones de campo que lo hacen real. Una historia con puntuación 3 dice: “Creemos que los usuarios podrían querer esto” y espera que tengas fe.
Dimensión 2: Especificidad del Usuario
¿Sabemos realmente quién es el usuario de esta historia?
Aquí llegamos a uno de los antipatrones más comunes en la industria: la historia de usuario genérica. “Como usuario, quiero poder buscar productos para encontrar lo que necesito.” Este es un ejemplo de lo que llamamos una “historia fantasma.” Es tan genérica que podría aplicar a casi cualquier plataforma digital.
El framework de Jobs-to-be-Done resuelve esto a través de lo que Wendell llama las cuatro preguntas de usuario específico:
¿Quién exactamente es este usuario? No “usuarios de móvil.” Específicamente: “Mujeres que compraban entre dos y tres veces a la semana en la tienda física, y están experimentando con compra online por primera vez.”
¿En qué contexto está intentando hacer su trabajo? “A las 7 AM en casa mientras se prepara para el trabajo, usando 5-10 minutos para hacer un pedido rápido.”
¿Qué otras alternativas está considerando? “Podría seguir yendo a la tienda físicamente, podría usar Amazon Fresh, podría pedir a través de WhatsApp.”
¿Qué obstáculos enfrenta para hacer su trabajo? “No sabe qué categorías están disponibles online, tarda 20 minutos en buscar lo que necesita.”
Una historia que no puede responder estas cuatro preguntas específicamente tiene una puntuación máxima de 5 en esta dimensión. Este es un hard rule, no una sugerencia. Porque sin especificidad de usuario, no puedes medir si la solución realmente funciona para alguien.Dimensión 3: Cambio de Comportamiento Cuantificable
¿Qué hará diferente el usuario después de usar nuestra solución?
Esta es la dimensión donde muchas historias de usuario tradicionalmente fracasan. Porque la mayoría de las historias definen el “beneficio” de manera abstracta. “Como vendedor de tienda, quiero un dashboard de inventario en tiempo real para tener mejor visibilidad.” ¿Mejor visibilidad? ¿Eso qué significa?
Con la óptica de Jobs-to-be-Done y la filosofía de experimento del Entrenador de Calidad, necesitamos traducir esto a cambio de comportamiento observable:
“Como vendedor de tienda en turno de mañana, quiero recibir alertas automáticas cuando un producto se queda sin stock para que pueda reabastecer en los próximos 15 minutos en lugar de esperar a la revisión manual cada hora. Baseline: 3 horas de espera promedio. Target: 15 minutos.”
Observa lo que cambió: el usuario es específico (vendedor en turno de mañana), el comportamiento es específico (recibir alertas, actuar rápido vs. revisar manualmente), y es cuantificable (15 minutos vs. 3 horas).
Esto es una historia que puedes validar experimentalmente. Despliegas el feature, y después de dos semanas observas: ¿Los vendedores realmente están reabasteciendo en 15 minutos en lugar de 3 horas?
Una historia sin cambio de comportamiento cuantificable tiene una puntuación máxima de 5 en esta dimensión. Este es otro hard rule. Sin cambio de comportamiento cuantificado, es solo un feature backlog, no una historia de usuario.
Dimensión 4: Zona de Control
¿Está el equipo en control de lo que necesita entregar para lograr este cambio de comportamiento?
Este es un tema sutil pero crítico. Imaginemos esta historia: “Como centro de distribución, quiero que los proveedores entreguen con exactitud 99% de las unidades pedidas para que nuestro sistema de picking sea más eficiente.”
Este es un problema real. Pero el equipo de tecnología no controla a los proveedores. Una historia en esta situación tiene que redefinirse para estar dentro de la zona de control del equipo:
“Como especialista de relaciones con proveedores, quiero un dashboard que muestre exactitud de entregas por proveedor en tiempo real para poder identificar patrones y contactar proactivamente a proveedores con bajo desempeño.”
Ahora el equipo controla lo que importa: generar datos confiables, alertar, facilitar la comunicación. El cambio de comportamiento del proveedor es el segundo efecto, no el primero.
Dimensión 5: Restricciones de Tiempo
¿Es la urgencia real o artificial?
He visto esto en cientos de organizaciones: llega el final del sprint, y de repente todo es urgente. Cuando más del 50% de las historias de un sprint tienen deadlines cercanas, algo está mal. No es un problema de ejecución. Es un problema de priorización.
El Entrenador de Calidad observa las restricciones de tiempo en dos dimensiones: Primero, ¿es la urgencia real o percibida? “Perderemos 10k en ventas por día si no lo entregamos” es real. “El stakeholder quiere verlo en la review” es artificial. Segundo, ¿es síntoma de un problema sistémico? Un sprint donde cada historia tiene presión de tiempo es un patrón que necesita atención.
Dimensión 6: Experimento Sobrevivible
¿Qué haremos si nos equivocamos?
Esta es la dimensión más futurista, pero también la más importante para una organización que quiere escalar. Una buena historia de usuario debería incluir desde el principio:
La hipótesis explícita: Lo que creemos que va a pasar
La métrica de éxito: Cómo sabremos si tuvimos razón
El plan de rollback: Cómo revertiremos si nos equivocamos
El plan de validación: Cuántos usuarios, durante cuánto tiempo, antes de la entrega completa
Un ejemplo de una historia que puntúa 9 en esta dimensión: “Hipótesis: Mostrar productos frecuentemente comprados juntos en la página de detalles del producto aumentará la cesta promedio de compra en 15% para usuarios que repiten compra semanal. Métrica de éxito: AOV sube a 15% en grupo de test vs. control después de 2 semanas. Plan B: Si AOV no aumenta, revertir automáticamente a control. Validación: 10,000 usuarios en grupo de test durante 14 días.”
Una historia que puntúa 3: “Queremos mostrar productos relacionados en la página de detalles del producto.” ¿Qué hipótesis estamos validando? No se sabe. ¿Cuándo sabemos que fue exitoso? Cuando termine el sprint.
Los Siete Antipatrones de Historia Débil
A través de analizar cientos de historias de usuario en Mercadona Tech, hemos identificado patrones recurrentes de debilidad. No son errores en sí mismos, sino síntomas de historias que no han sido pensadas como experimentos verificables sobre cambio de comportamiento.
Antipatrón 1: El Usuario Fantasma
“Como usuario, quiero poder filtrar por marca para buscar más fácilmente.” El usuario aquí es tan genérico que es invisible. ¿Quién? ¿Un usuario habitual que compra dos veces a la semana? ¿Un nuevo usuario que no sabe cuáles son las marcas disponibles? La solución es incluir el proto-personaje completo, respondiendo las cuatro preguntas de especificidad de usuario de Wendell.
Antipatrón 2: El Beneficio Fantasma
“Para poder encontrar lo que necesito.” ¿Qué significa “encontrar”? ¿Menos clics? ¿Menos tiempo? ¿Resultados más relevantes? Sin una definición operacional del beneficio, no puedes validar experimentalmente si la solución funcionó.
Antipatrón 3: La Historia Falsa
“Como equipo de ingeniería, quiero refactorizar la base de datos para poder tener mejor performance.” ¿Quién es el usuario aquí? No es el equipo de ingeniería. Es el usuario final que espera una aplicación más rápida. Una historia verdadera sería: “Como usuario que hace búsquedas frecuentes de ofertas en categoría Frescos, quiero que los resultados se carguen en menos de 2 segundos (vs. los actuales 5 segundos) para poder navegar sin frustración.”
Antipatrón 4: La Solución como Necesidad
“Quiero un botón de favoritos en la página de producto.” Estamos describiendo la solución técnica, no el trabajo del usuario. ¿Por qué el usuario necesita favoritos? ¿Es para comparar productos? ¿Es para volver a productos vistos anteriormente? Cada respuesta es una historia diferente, con métricas de éxito diferentes.
Antipatrón 5: Entrega Fuera de Control
“Como gestor de centros, quiero que el sistema de proveedores externo envíe datos de inventario cada hora.” El equipo no controla el sistema externo. La historia está configurada para fracasar porque está fuera de la zona de control del equipo.
Antipatrón 6: Todo es Urgente
Si tu sprint tiene 80% de las historias con deadlines apretadas, tu priorización está rota. No es un problema de ejecución. Una historia bajo presión de tiempo real es diferente de una sprint donde todo es urgente por defecto.
Antipatrón 7: División Técnica Horizontal
“Como desarrollador frontend, quiero crear la interfaz de filtros. Como desarrollador backend, quiero implementar los endpoints de filtros.” Lo que debería ser una única historia de usuario se divide en tareas técnicas de capas. Puedes tener dos “historias” completadas y el usuario seguir sin tener la funcionalidad de punta a punta.
El Mecanismo: Evaluación Rigurosa sin Rigidez
El Entrenador de Calidad utiliza las seis dimensiones para evaluar cada historia en una escala de 0-10. Pero el mecanismo es importante: no es un juicio de “bueno” o “malo.” Es un diagnóstico.
Una historia que puntúa 32/60 (53%) no es rechazada. Se dice: “Aquí está el diagnóstico. La historia es débil en especificidad de usuario, débil en cambio de comportamiento cuantificado, fuerte en contexto JTBD. Esto significa que entiendes el problema real, pero aún necesitas clarificar exactamente quién es el usuario y qué comportamiento esperas cambiar.”
Entonces el Entrenador proporciona una reescritura sugerida de la historia, reformulada en lenguaje JTBD, que el Product Manager puede adoptar, adaptar, o descartar.
Aquí es donde la filosofía es crucial: El Entrenador respeta la autonomía de decisión del PM, pero no respeta la vaguedad. Si decides ignorar el feedback del Entrenador, puedes hacerlo. Pero hazlo con los ojos abiertos, sabiendo exactamente dónde está el riesgo.
Ejemplo Completo: Reescritura de Una Historia Débil
Vamos a tomar una historia de usuario tal como aparecería en un backlog real, y mostrar exactamente cómo el Entrenador de Calidad la diagnostica y propone una reescritura.
Historia Original:
“Como usuario de la aplicación de compra, quiero poder ver recomendaciones personalizadas de productos en mi inicio de sesión para poder descubrir productos nuevos y aumentar mis compras.”
Diagnóstico del Entrenador:
Dimensión/Puntuación/Observación
D1: Contexto JTBD 4/10 Hay un problema implícito (”descubrir productos nuevos”) pero sin evidencia cuantificada.
D2: Especificidad de Usuario 2/10 ”Usuario de la aplicación de compra” es extremadamente genérico. Hard rule: máximo 5 sin especificidad.
D3: Cambio de Comportamiento 3/10 ”Descubrir productos nuevos” y “aumentar mis compras” son beneficios abstractos. Hard rule: sin cuantificación clara, máximo 5.
D4: Zona de Control 7/10 El equipo controla la recomendación y el display. Mayormente controlable.
D5: Restricciones de Tiempo 8/10 Sin deadline urgente aparente. Puede desarrollarse con rigor adecuado.
D6: Experimento Sobrevivible 2/10 No hay hipótesis explícita, no hay plan de validación, no hay métrica de éxito clara, no hay plan B.
Puntuación Total: 26/60 (43%)
Feedback del Entrenador:
“Esta historia toca un tema legítimo (personalization aumenta valor), pero está muy poco especificada. No sabemos quién es el usuario exacto, no sabemos en qué contexto está usando recomendaciones, y no sabemos cómo mediremos el éxito. Recomendación: Reformular incluyendo proto-personaje específico, contexto, cambio de comportamiento cuantificado, y métrica de validación.”
Historia Reescrita (Sugerencia del Entrenador):
“Como cliente en categoría de Frescos que históricamente compra el mismo tipo de productos cada semana (plátanos, leche, queso), quiero recibir recomendaciones de nuevos productos en las mismas categorías al iniciar sesión para poder descubrir ofertas o variantes que se alineen con mis preferencias sin incrementar el tiempo de búsqueda. Contexto: Cliente que dedica 8-10 minutos a completar su pedido. Hipótesis: Mostrar 3-5 recomendaciones de ‘también te pueden gustar’ en la pantalla de inicio aumentará el AOV (Average Order Value) en al menos 8% en este segmento, sin aumentar el tiempo de compra (permanecerá menos de 12 minutos). Métrica: Comparar AOV grupo test vs. grupo control durante 2 semanas. Plan de validación: 5,000 usuarios en grupo test. Plan B: Si AOV no aumenta en 5 días, revertir recomendaciones a grupo de control.”
Puntuación de la Historia Reescrita:
DimensiónPuntuaciónObservación D1: Contexto JTBD7/10Hay hipótesis clara, hay segmento de usuario identificado. Falta evidencia de campo, pero es sólida. D2: Especificidad de Usuario9/10Específico: cliente de Frescos que repite compra semanal. Proto-personaje claro. D3: Cambio de Comportamiento8/10Cuantificado: AOV aumenta 8%. Contexto: sin aumentar tiempo de compra. Claramente medible. D4: Zona de Control8/10Equipo controla recomendaciones y display. AOV es métrica observable del sistema. D5: Restricciones de Tiempo9/102 semanas de test. Plan de decisión claro. No artificial. D6: Experimento Sobrevivible9/10Hipótesis explícita, métrica de éxito, plan de validación, plan B. Es un experimento real.
Puntuación Total: 50/60 (83%)
Casos de Uso: Evaluar Historias en Cualquier Momento del Pipeline
Lo que hace al Entrenador de Calidad especialmente valioso es que funciona en múltiples puntos del pipeline, no solo para nuevas historias.
Caso 1: Evaluación Temprana (PRD → Story)
Durante la fase de investigación (Artículos 1-2), el Entrenador puede evaluar los PRDs para asegurar que contienen la evidencia necesaria. Un PRD que no tiene suficiente contexto JTBD para puntuar mayor a 6 en Dimensión 1 significa que necesitas más investigación antes de escribir historias.
Caso 2: Evaluación en Escritura (Story Builder)
Mientras escribes historias de usuario (Artículo 4), el Entrenador proporciona feedback en tiempo real. “Esta versión puntúa 4 en especificidad de usuario. Intenta nombrar el segmento exacto.”
Caso 3: Evaluación en Sprint (Historias Existentes)
El Entrenador puede evaluarse directamente desde Jira, incluso historias que fueron escritas sin el framework. Un Product Manager puede correr el Entrenador contra su backlog actual, ver dónde están los problemas, y enfocarse en las historias débiles para mejoramiento.
Caso 4: Benchmarking Entre Equipos
Cuando corres el Entrenador contra historias de 12 equipos diferentes, emergen patrones. El equipo de Tienda tiende a ser fuerte en especificidad de usuario pero débil en cambio de comportamiento cuantificado. El equipo de Primera Milla tiende a ser fuerte en contexto JTBD pero débil en experimento sobrevivible.
Estos patrones son datos de coaching. Permiten que los líderes de producto identifiquen dónde entrenar al equipo, qué hacer diferente, cómo transferir mejores prácticas entre equipos.
La Paradoja de la Consistencia
Aquí está la paradoja deliciosa del Entrenador de Calidad: Proporciona consistencia sin requerir rigidez.
En organizaciones tradicionales, intentas imponer consistencia forzando un estándar. “Todas las historias DEBEN tener este formato.” El resultado es que las historias son uniformes pero vacías. Todos cumplen con el checklist. Pero nadie realmente está pensando.
El Entrenador hace lo opuesto. Proporciona un sistema de diagnóstico que es lo suficientemente flexible para respetar contextos diferentes, pero lo suficientemente riguroso para garantizar que ciertas debilidades sean transparentes.
Una historia en Checkout puede priorizar diferente que una en Tienda. Pero ambas responden las mismas preguntas fundamentales: ¿Quién exactamente es el usuario? ¿Qué comportamiento espera cambiar? ¿Cómo validaremos que nuestra hipótesis fue correcta?
Porque si estos tres puntos no están claros, entonces no es realmente una historia de usuario. Es una tarea técnica disfrazada de historia.
La Importancia de “Especificidad de Usuario” y “Cambio de Comportamiento” como Hard Rules
Es importante enfatizar dos de las seis dimensiones porque emergen como los mayores predictores de fracaso en historias de usuario tradicionales.
Dimensión 2 (Especificidad de Usuario): El cambio de comportamiento observable, medible, requiere un usuario específico. Porque diferentes usuarios tienen diferentes contextos, diferentes limitaciones, diferentes motivaciones. Una historia que dice “usuario” en lugar de “usuario que compra en Frescos dos veces a la semana” es una historia que no puedes validar experimentalmente. Por eso tiene un hard rule: máximo 5 sin especificidad.
Dimensión 3 (Cambio de Comportamiento Cuantificado): El cambio de comportamiento es lo que distingue entre un feature backlog y una hipótesis verificable. “Mejorar la experiencia” es un feature backlog. “Reducir el tiempo de búsqueda de 180 segundos a 60 segundos” es una hipótesis verificable. Por eso tiene un hard rule: máximo 5 sin cuantificación.
Estos hard rules no son arbitrarios. Son las condiciones mínimas para que una historia sea experimentable.
Antipatrones en Mercadona Tech: Aprendizajes Específicos
En los meses que el Entrenador de Calidad ha estado operacional, hemos visto patrones específicos en cómo diferentes equipos de Mercadona Tech necesitan mejorar.
Tienda (Shop): Tendencia fuerte a cometer antipatrón #1 (Usuario Fantasma) porque el usuario es “vendedor” o “cliente.” Necesidad de entrenar en diferenciación de proto-personajes por turno, por antigüedad, por tipo de tienda.
Primera Milla: Tendencia a cometer antipatrón #3 (Historia Falsa) porque a menudo las historias están escritas desde la perspectiva del equipo técnico en lugar del usuario final (repartidor, cliente, operador de logística).
Ser Humano: Mezcla de antipatrón #2 (Beneficio Fantasma) con antipatrón #6 (Todo es Urgente). Historias frecuentemente bajo presión de tiempo, lo que significa menos tiempo para especificar. Necesidad de proteger tiempo de planning.
Colmena: Tendencia a antipatrón #4 (Solución como Necesidad) porque la mayoría del trabajo es automatización/reposición. Requiere pasos explícitos para conectar la solución técnica con el cambio de comportamiento del usuario humano (reponedor, operador, gestor).
Estos patrones no son críticos. Son observaciones que permiten coaching específico.
Conclusiones: De la Intuición a la Disciplina
A lo largo de cinco artículos de esta serie, hemos construido un framework completo para transformar investigación de usuarios en historias de usuario de alta calidad que actúen como experimentos sobre cambio de comportamiento.
Primero, aprendimos a investigar PRDs con rigor científico, usando Mom Test para validar hipótesis directamente en el campo (Artículo 1).
Segundo, aprendimos a traducir esa investigación en Jobs-to-be-Done, el lens conceptual que nos permite ver el trabajo verdadero que el usuario está intentando hacer (Artículo 2).
Tercero, aprendimos a hacer puente entre Jobs-to-be-Done y User Stories, manteniendo la especificidad y rigor a través de la transición (Artículo 3).
Cuarto, aprendimos a escribir historias de usuario desde cero cuando no tenemos un PRD, usando un proceso conversacional que extrae claridad (Artículo 4).
Ahora, aprendemos a evaluar historias consistentemente usando un sistema que es simultáneamente riguroso y flexible.
Lo que emerge de estos cinco pasos es una transformación organizacional profunda. Ya no estás entregando features basado en intuición de PM. Estás ejecutando hipótesis sobre cambio de comportamiento, validadas con evidencia de investigación, escritas con especificidad, evaluadas contra estándares claros.
El Entrenador de Calidad no es un policía que rechaza historias débiles. Es un coach que dice: “Aquí está exactamente dónde tu historia es débil. Aquí está lo que necesitas hacer para reforzarla. Tienes la autonomía de decidir si quieres hacer el esfuerzo.”
Algunos equipos lo harán. Otros usarán el diagnóstico para tomar decisiones conscientes sobre riesgo. Ambas opciones son válidas. Lo que no es válido es pretender que una historia vaga es una historia de usuario simplemente porque está en el backlog.
En Mercadona Tech, con 12 verticales en paralelo, la diferencia entre intuición y disciplina en la calidad de historias de usuario es la diferencia entre ejecutar y ejecutar con confianza.
El Entrenador de Calidad existe para hacer esa diferencia tangible y medible.
Próximo Artículo (6 de 7): Síntesis e Integración — Cómo todas las piezas del Marco de Historias de Usuario de IA Mercadona trabajan juntas en un workflow real, y cómo ha cambiado la forma en que Mercadona Tech ejecuta producto.