Blog · Cátedra Viewnext-USAL en Metodologías Ágiles
Este artículo es la tercera entrega de la serie sobre Dual Track Agile con IA. Si no has leído los anteriores, te recomendamos empezar por la introducción al modelo y el caso práctico de organización: https://viewnext.usal.es/blog/dual-track-agile-con-ia-un-caso-pr%C3%A1ctico-paso-paso
El problema
Saber que necesitas un track de discovery no es suficiente. El error más habitual una vez adoptado el modelo es tratar todas las hipótesis igual: mismo número de personas, mismas herramientas, misma cadencia. Una hipótesis sencilla de UX no necesita el mismo equipo que una hipótesis técnica compleja, y sobredimensionar el squad en casos simples consume capacidad sin añadir valor.
La pregunta correcta no es cuántas personas hay disponibles para el track de discovery, sino qué tipo de pregunta se quiere responder. El tamaño del squad y las herramientas son una consecuencia de esa clasificación, no una decisión previa.
La solución: clasificar antes de dimensionar
Las hipótesis del track de discovery caen habitualmente en tres categorías, cada una con necesidades distintas de equipo y herramientas:
Hipótesis de UX / Producto: Preguntas sobre comportamiento del usuario: ¿usarán esta funcionalidad? ¿entenderán cómo funciona? Se validan con prototipos de baja fidelidad y sesiones de prueba con usuarios reales. Un solo miembro del squad con herramientas de prototipado y síntesis de feedback asistida por IA es suficiente. Ciclos de 3-4 días.
Hipótesis Técnica: Preguntas sobre viabilidad de implementación: ¿es posible construir X con la arquitectura actual? ¿funcionará este algoritmo sobre datos reales? Se validan con prototipos funcionales, no con maquetas. Pueden requerir una segunda persona si la integración implica sistemas externos. Ciclos de 4-5 días.
Hipótesis de Valor / Negocio: Preguntas sobre impacto medible: ¿aumenta la conversión? ¿reduce el abandono? Se validan con datos reales de comportamiento o con tests controlados. Requieren acceso a analítica y capacidad de análisis de datos, lo que habitualmente implica incorporar un segundo perfil al squad. Ciclos de 4-5 días.
Este esquema recoge el framework completo: tipos de hipótesis, tamaño de squad recomendado, herramientas principales y criterios para ampliar a 2-3 FTE.
Un ejemplo de aplicación real
A continuación presentamos cómo Éclat Cosmetics aplica este framework en el Q1, dando continuidad al caso de organización del artículo anterior. Marco llega al nuevo trimestre con tres ítems en su backlog de discovery: el asistente de belleza, que no se validó en Q4, un motor de búsqueda semántica y una hipótesis nueva sobre personalización por tipo de piel. Los tres son preguntas distintas y, aplicando la Figura 1, Marco toma decisiones de equipo y herramientas diferentes para cada uno.
El caso: Éclat Cosmetics Q1
Ítem 1. Asistente de belleza: hipótesis de UX / Producto
La pregunta del Q4 era «¿tiene valor un asistente de belleza?». Los usuarios no sabían qué preguntarle. En Q1 la hipótesis se reformula: «¿un flujo de entrada conversacional, en lugar de un campo de búsqueda vacío, hace que el usuario interactúe de forma natural con el asistente?»
Clasificación: hipótesis de UX. Marco trabaja solo. En cuatro días construye dos prototipos en Figma, uno con campo abierto, otro con preguntas guiadas de inicio, y los prueba con quince usuarios usando Claude para sintetizar el feedback. El prototipo con preguntas guiadas genera un 70% más de interacciones completadas. Decisión: validado. Pasa al backlog del equipo Scrum con especificación de diseño incluida.
Ítem 2. Motor de búsqueda semántica: hipótesis técnica
La pregunta: «¿puede un modelo de embeddings mejorar los resultados de búsqueda respecto al motor actual por palabras clave, sobre el catálogo real de Éclat?
Clasificación: hipótesis técnica. Marco trabaja solo. En cinco días conecta la API de embeddings de OpenAI al catálogo de productos, construye un comparador de resultados en Python y evalúa la precisión de ambos motores sobre 200 búsquedas reales. El motor semántico mejora la precisión un 38% en búsquedas de más de tres palabras. Decisión: validado. Pasa al roadmap del equipo Scrum para el Q1.
Ítem 3. Personalización por tipo de piel: hipótesis de valor
La pregunta: «¿aumenta la conversión mostrar el catálogo filtrado automáticamente por el tipo de piel registrado en el perfil del usuario, frente al catálogo general?»
Clasificación: hipótesis de valor/negocio. Esta hipótesis requiere datos de comportamiento reales con tráfico de producción y análisis estadístico de los resultados: por primera vez, Marco no puede resolverla solo. Se incorpora al squad de forma puntual una analista de datos del equipo Scrum, durante tres días de los cinco del ciclo.
Con Python y el sistema de analítica existente, miden la conversión en dos grupos durante 48 horas. El grupo con catálogo personalizado convierte un 8% más. El tamaño de muestra es suficiente para que el resultado sea estadísticamente significativo. Decisión (camino A): va directamente a producción como funcionalidad activa para todos los usuarios con perfil de piel registrado.
La decisión de ampliar el squad no fue arbitraria: se tomó antes de empezar el ciclo, al clasificar el tipo de hipótesis, no a mitad del proceso cuando el tiempo ya se había consumido.
El resultado
Los tres ítems del Q1 se resolvieron con equipos y herramientas distintos, todos dentro del plazo de cinco días por ciclo. El asistente de belleza, que había fallado en Q4 por un problema de diseño, llegó al equipo Scrum con una especificación validada. El motor semántico se construyó sabiendo de antemano que funcionaba. Y la personalización por tipo de piel pasó directamente a producción con datos que respaldaban la decisión.
El coste total del track de discovery en Q1 fue de cinco ciclos de trabajo de Marco más tres días puntuales de la analista. Ninguno de los tres ítems llegó al equipo Scrum sin validación previa.
Lo que necesitas para aplicarlo
El framework de la Figura 1 se aplica en tres pasos: formular la hipótesis como una pregunta concreta, clasificarla en uno de los tres tipos, y decidir equipo y herramientas a partir de esa clasificación. Si la hipótesis no cabe en ninguna de las tres categorías, es probable que sea demasiado amplia para un ciclo de discovery y necesite dividirse antes de empezar.
Con estos dos artículos, el de organización y este de dimensionamiento, tienes los elementos esenciales para arrancar con el Dual Track Agile con IA en tu equipo. Puedes consultar toda la serie en el blog de la Cátedra: viewnext.usal.es/blog
Add new comment