UX en equipos ágiles: Scrum y Kanban sin perder diseño

En Scrum y Kanban el diseño suele quedarse atrás o llegar tarde. Qué dicen la Guía de Scrum 2020, NN/g y Scrum.org y cómo integrar descubrimiento y entrega.

info Definición Rápida
En un equipo ágil, el diseño tiene dos trabajos que a veces chocan: descubrir qué construir (investigación, prototipos, pruebas) y ayudar a construirlo bien (decisiones de interacción, criterios de aceptación, revisión). El sprint empuja hacia la entrega y el descubrimiento necesita tiempo. Integrar ambos sin perder ninguno es el problema central de UX en agile.

¿Por qué el diseño suele quedarse atrás en Scrum?

Porque el sprint tiene un ritmo fijo y el diseño tiene un ritmo variable. Una prueba con usuarios puede tardar una semana en organizarse, y el análisis puede revelar que la idea no funciona. Si el equipo de desarrollo espera el diseño, pierde tiempo. Si el diseño va por delante sin contacto con el equipo, se produce trabajo que no se implementa.

NN/g (Anna Kaley, 2023), en su video sobre descubrimiento en agile, pide escalar las actividades de descubrimiento en lugar de saltárselas, aunque los sprints sean cortos. La idea es planificarlas alrededor de preguntas concretas y supuestos probables, no de plazos arbitrarios del sprint.

¿Qué dice la Guía de Scrum 2020?

La Guía de Scrum no menciona el diseño ni UX, pero sus reglas marcan el terreno:

  • El equipo es multifuncional. Sus miembros tienen todas las habilidades necesarias para crear valor en cada sprint, y dentro del equipo no hay subequipos ni jerarquías.
  • Los Developers son quienes crean cualquier aspecto del incremento. La guía define así a las personas comprometidas con crear “cualquier aspecto de un incremento utilizable” en cada sprint. Es una lectura razonable que el trabajo de diseño entra ahí, pero la guía no lo dice de forma explícita.
  • El incremento debe ser utilizable y cumplir la Definición de Terminado.
  • El sprint dura un mes o menos.

De ahí sale el argumento contra un “equipo de diseño” aparte que entrega al equipo de desarrollo. El Manifiesto Ágil apunta en la misma dirección en su cuarto principio: los responsables de negocio y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

¿Qué riesgo tiene el desfase de un sprint?

Scrum.org (Alex Ballarin Latre, 2024) analiza el modelo en el que diseño define la interfaz en el sprint N, desarrollo la construye en el N+1 y diseño la prueba en el N+2. Su crítica es directa: no es Scrum, porque al final del sprint no hay un producto potencialmente entregable; la entrega se retrasa tres ciclos de sprint; y casi toda la interacción entre usuario, diseñador y desarrollador se pierde.

Jeff Gothelf (2018) llega a una conclusión parecida: si el diseño ocurre fuera del equipo, ya sea con un diseñador interno o externo, se vuelve al diseño completo por adelantado (Big Design Up Front) y se pierden la colaboración, el entendimiento compartido y la confianza. Su recomendación es un diseñador a tiempo completo dentro del equipo Scrum.

Eso no significa que todo el descubrimiento deba caber en el mismo sprint que la construcción. Significa que la conversación entre diseño y desarrollo no puede romperse.

¿Qué es el dual-track y en qué se diferencia?

El dual-track agile separa el trabajo en dos pistas que corren en paralelo. La de descubrimiento produce, prueba y valida ideas de producto antes de comprometerse a construirlas. La de entrega convierte lo validado en producto. Según Productboard, la idea aparece por escrito en 2005 con Lynn Miller, Desirée Sy la retoma en 2007, y en 2012 Marty Cagan y Jeff Patton hablan de dual-track scrum.

Su atractivo es claro: el diseño trabaja sobre lo que viene y el desarrollo sobre lo que ya está listo. El riesgo es que se convierta en dos equipos que se pasan trabajo, que es justo el desfase de arriba. Scrum.org recuerda que la idea original de Sy implicaba colaboración frecuente entre diseñadores y desarrolladores, no sprints separados. El detalle del modelo está en dual-track agile; el Lean UX plantea la misma tensión desde la hipótesis y el experimento, y el discovery continuo propone el hábito semanal de hablar con usuarios.

¿Cómo se integra en Scrum?

Scrum.org propone poner a diseñadores y desarrolladores en el mismo sprint, trabajando en paralelo: el diseño llega antes de que el desarrollo necesite la pantalla, pero no tanto antes que pierda contacto. Estas prácticas ayudan y encajan con el proceso de diseño UX que el equipo ya use:

  • Descubrimiento continuo. Pequeñas pruebas semanales, con preguntas concretas, en lugar de una gran investigación al inicio. Gothelf añade que actividades como design sprints, investigación cualitativa y redacción de hipótesis mantienen el backlog anclado en la realidad del cliente.
  • Diseño en la planificación. Bocetos colaborativos y lluvia de ideas en la planificación del sprint ayudan a resolver dudas sobre flujos de pantalla y excepciones.
  • Criterios de aceptación con diseño. Estados, mensajes de error y comportamientos incluidos en cada historia, para que desarrollo no adivine.
  • Revisión conjunta. En la revisión del sprint se discuten revisiones de diseño, síntesis de investigación y analítica para decidir qué se lanza y qué se prioriza después.
  • Un trabajo previo de visión general. Warren Croce, citado por UXmatters, defiende un “Sprint 0” de descubrimiento antes de desarrollar. Es una práctica de la comunidad, no parte de la Guía de Scrum; si la usas, mantenla corta y con contacto con el equipo.

Adrian Howard, citado en la misma discusión de UXmatters, sostiene que el ritmo ágil le permite incluir investigación generativa y evaluativa dentro de los ciclos del equipo.

¿Y Kanban?

Kanban no tiene sprints, así que el diseño no necesita un desfase formal. Lo que necesita es visibilidad: que el descubrimiento aparezca en el tablero con sus estados, por ejemplo “por investigar”, “en prueba” y “validado”. Es una propuesta de este artículo, no una norma de Kanban: tratar el descubrimiento como un flujo propio con límites de trabajo en curso, para que no se acumulen hipótesis sin probar.

Ejemplo

Ejemplo ilustrativo: un equipo de una aplicación de salud trabaja en Scrum con sprints de dos semanas, y la diseñadora forma parte del equipo. En el primer sprint, las historias son pequeñas y la diseñadora usa la primera semana para entrevistar a cinco pacientes y probar un prototipo en papel, mientras desarrollo prepara la base técnica. En los sprints siguientes, cada historia llega con su criterio de diseño: estados de carga, mensajes de error y navegación con teclado. Cada semana, la diseñadora prueba con dos personas la versión construida la semana anterior. Desarrollo no espera al diseño, y el diseño no trabaja en el vacío.

Para tu equipo: revisa las últimas tres historias de usuario. Si alguna llegó sin criterio visual o de interacción, pide que se revise antes del próximo sprint.

¿Cuándo NO conviene?

  • Cuando el equipo es tan pequeño que una sola persona hace diseño y desarrollo. Separar pistas no aporta.
  • Cuando el producto no tiene usuarios accesibles para descubrimiento. Sin ellos, el descubrimiento se convierte en suposiciones.
  • Cuando el equipo usa agile solo como etiqueta y las decisiones las toma una sola persona fuera del ciclo.

Errores comunes

  • Diseñar un sprint por delante sin contacto con el equipo de desarrollo.
  • Tratar el descubrimiento como una fase que se termina antes de empezar a construir.
  • Dejar historias sin criterio de diseño.
  • Excluir el diseño de la planificación porque no se considera “trabajo real”.
  • Medir el diseño por entregables y no por resultados de usuario.
  • Hacer descubrimiento sin revisar lo que realmente se construyó.

Fuentes

Preguntas frecuentes

¿Dónde debe estar el diseño en un equipo Scrum?
Dentro del equipo, no fuera. La Guía de Scrum 2020 dice que el equipo es multifuncional y no tiene subequipos, y Scrum.org critica el modelo en que el diseño trabaja un sprint por delante porque retrasa la entrega y rompe la conversación entre usuario, diseñador y desarrollador.
¿Qué es el dual-track agile?
Es un modelo con dos pistas: descubrimiento, donde se producen, prueban y validan ideas de producto, y entrega, donde se construye lo validado. Productboard lo describe así y ubica su difusión como dual-track scrum en 2012, con Marty Cagan y Jeff Patton.
¿El diseño puede hacerse en un Kanban?
Sí. Kanban no tiene sprints, así que el reto es la visibilidad. Una propuesta práctica es mostrar el descubrimiento como un flujo propio en el tablero, con estados como ‘por investigar’, ’en prueba’ y ‘validado’, y con límites de trabajo en curso.
¿Qué pasa si el diseño va un sprint por delante?
Según Scrum.org, al final del sprint no hay un producto potencialmente entregable, la entrega se retrasa hasta tres ciclos y se pierde casi toda la interacción entre usuario, diseñador y desarrollador.