Integrar UX en un equipo Scrum es más complejo de lo que parece. El diseño requiere exploración, iteración y validación con usuarios — actividades que tienen tiempos y dependencias distintos al desarrollo de software. Si simplemente añades un diseñador al equipo sin adaptar la forma de trabajar, el resultado suele ser un diseñador bloqueado o trabajando desincronizado con el resto.
Este artículo es la segunda parte de una serie sobre UX y Scrum. Aquí nos centramos en los aspectos más prácticos: cómo organizar el backlog, cómo gestionar la Definition of Done y cuáles son los dos modelos de integración posibles.
01 · BacklogDos modelos para gestionar el backlog con UX.
Existen dos formas principales de organizar el trabajo de UX y desarrollo en Scrum:
Backlogs separados
El equipo de diseño y el equipo de desarrollo trabajan de forma asíncrona, con sus propios backlogs y cadencias. La ventaja es que cada equipo puede optimizar su propio flujo. El problema es que crea desconexión: los diseñadores producen en el vacío sin feedback rápido del código, y los desarrolladores esperan diseños sin poder colaborar en ellos.
Backlog único
Diseñadores y desarrolladores trabajan sincronizados en el mismo sprint, con un único backlog compartido. Es el modelo que recomienda Scrum porque mantiene la cohesión del equipo. La pregunta que surge es: ¿cómo clasificar los ítems de diseño en el backlog?
Los ítems de diseño puro (exploración, prototipado, investigación) no generan valor independiente y no deberían existir como historias standalone. En su lugar, las actividades de UX se organizan en tres fases dentro de cada ítem:
- Discovery: exploración, prototipado, entrevistas con usuarios.
- Definition: refinamiento, planificación, gestión de dependencias.
- Development: implementación en el sprint.
02 · UpstreamEl modelo Upstream/Discovery de Kanban como alternativa.
La comunidad Kanban propone separar el trabajo de descubrimiento del trabajo de entrega mediante el concepto de "Upstream" — trabajo que ocurre fuera del sistema principal de entrega.
El Upstream/Discovery valida ideas de forma económica antes de comprometer capacidad de desarrollo. La diferencia con Scrum es sutil pero importante: Kanban acepta explícitamente que hay tipos de trabajo cualitativamente distintos (exploración vs. entrega) que merecen sistemas separados.
El riesgo del modelo de backlogs separados es la desconexión entre equipos. El riesgo del backlog único mal implementado es mezclar actividades incompatibles en el mismo ítem.— Dilema central de UX en Scrum
03 · DoneLa Definition of Done con UX: el problema del "desplegado".
Scrum define "Done" como "potencialmente desplegable". UX añade una capa de complejidad: desde la perspectiva de Lean UX, el trabajo no está completo hasta que una hipótesis se valida cambiando el comportamiento del usuario. Eso no puede confirmarse en el momento del sprint review.
La solución más pragmática es aceptar que "Done" significa "desplegado" — no "publicado para todo el mundo". Técnicas como Canary Releasing permiten desplegar funcionalidades a un subconjunto de usuarios para observar efectos reales sin afectar a toda la base de usuarios.
04 · PrácticaPrincipios para una integración UX+Scrum que funciona.
Más allá de los modelos formales, la integración de UX en Scrum requiere cambios culturales:
- El diseñador es un miembro del equipo Scrum, no un proveedor externo de artefactos. Esto implica presencia en todos los eventos y corresponsabilidad en el sprint goal.
- El refinamiento incluye trabajo de UX. Las historias que implican interacción significativa con el usuario deben refinarse con el diseñador antes del sprint planning.
- La validación con usuarios no es opcional. Si no hay presupuesto para investigación, hay que negociar explícitamente qué suposiciones se están tomando sin validar.
- Los prototipos son parte del incremento. Un prototipo navegable demostrado en el sprint review tiene más valor que una funcionalidad implementada sin testear.