Agile-UX: ¿Por qué el Sprint Cero es una aberración?
- Victor M. Gonzalez
- 29 sept 2020
- 6 Min. de lectura
Extendiendo mis ideas sobre este polƩmico asunto

Photo by StartaĆŖ Team on Unsplash
Hace poco, en el contexto de una emocionante e iluminadora sesión de capacitación con la comunidad Ćgil (yo como participante), enviĆ© a mis redes sociales un mensaje sobre la aberración que significa pensar en un Sprint Cero como una forma de insertar āUXā en un marco Ć”gil como Scrum .

Mi post sobre el āSprint Zeroā en LinkedIn
Mi mensaje causó comentarios a favor y en contra (directos e indirectos) y creo que la única forma de aclarar el punto y contribuir al aprendizaje es crear esta nota.
Sobre Scrum ā ideas de arranque Primero que nada hay que decir que cuando hablo de aberración, uso la palabra para apuntar a la definición de la Real Academia EspaƱola que establece el significado de la palabra como: āGrave error del entendimientoā. Uso la palabra para apuntar a que la idea (āSprint Zero para UXā) tanto es grave porque nos lleva por un camino que conduce al error, y ademĆ”s, que tiene su raĆz en no entender bien de lo que se trata el marco en cuestión: Scrum.
Scrum es quizÔ el marco de trabajo Ôgil mÔs popular para el desarrollo de productos. En su definición se especifican roles, eventos, artefactos y reglas para operar e integrar procesos y técnicas que permiten un desarrollo incremental, iterativo e implementado a través de ciclos cortos donde se marcan los cierres y planeación con espacios para evaluación, reflexión para asimilar el aprendizaje y mejorar el producto y el proceso.
Sprints: el corazón de Scrum Una de las ideas centrales de Scrum (su corazón) es el Sprint, que se define de acuerdo a La GuĆa de Scrum⢠como un ābloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto āterminadoā utilizable y potencialmente desplegableā.
Tomando la idea de Alan Cyment, podemos decir que un Sprint es el espacio donde y durante el cual un equipo de desarrolladores hace dos cosas: (1) Crea el incremento del producto en lo que podrĆamos llamar un proceso de ādeliveryā, en el sentido de āgiving birthā de la palabra y (2) Define el siguiente incremento del producto en lo que podrĆamos llamar un proceso de ādiscoveryā, en el sentido de revelar, descubrir y provocar un esfuerzo de refinamiento de lo que previamente se ha incluido en el asĆ llamado Backlog (Lista de Producto).
Lo anterior revela la posible existencia de un error en el entendimiento en cuanto a lo que es Scrum. Muchos practicantes (āagilistasā y āUXersā) entienden erróneamente que durante un Sprint de Scrum la acción estĆ” en las manos de los desarrolladores y que cualquier esfuerzo de diseƱo (incluido el diseƱo de la experiencia de usuario) y sus actividades (por ejemplo, investigar usuarios o definir una arquitectura de información) no se hace durante esos bloques de tiempo.
El rol de diseƱo no se limita a los espacios āfuera del Sprintā o en sus puntos extremos (planeación o evaluación), los diseƱadores trabajan durante el Sprint porque son parte esencial de los esfuerzos de delivery y discovery.
En ese contexto, en las siguientes lĆneas explico mi perspectiva sobre el rol del diseƱo para el desarrollo de productos interactivos digitales.
¿Cómo el diseño de UX contribuye al Delivery que se hace en un Sprint?
AquĆ entendemos el diseƱo de la experiencia de usuario (UX) en su sentido de aportar fundamentos para definir la interacción entre la persona y un producto digital. Estos fundamentos pueden ser elementos de psicologĆa cognitiva, social, organizacional, o fisiologĆa sensorial, o elementos de economĆa de la conducta. Todo son, sin duda, aportaciones que se dan mientras se construye el producto y que un desarrollador requiere co-definir con un diseƱador UX. Muchos otros elementos como el seguimiento y revisión de lineamientos de diseƱo o el diseƱo de la información, deberĆan co-definirse en un esquema de justo en el momento que se requiere (just in time).
ĀæCómo el diseƱo de UX contribuye al Discovery que se hace en un Sprint? El diseƱo de la experiencia de usuario (UX) tambiĆ©n tiene aportaciones muy importantes para ayudar al proceso de refinamiento que se hace durante un Sprint (n) para anticipar lo que serĆ” el trabajo en el siguiente Sprint (n+1). Herramientas de UX para investigar a usuarios y sus reacciones, para validar prototipos de partes del producto o para hacer anĆ”lisis competitivo, entre otras, son y pueden ser utilizadas durante el Sprint. Se utilizan para ayudar a mitigar el riesgo de no saber cómo un usuario reacciona ante uno de los elementos del Backlog que se estĆ”n contemplando para el siguiente Sprint. Estos esfuerzos se hacen en colaboración con los desarrolladores y claramente con el dueƱo del producto (product owner) y otros stakeholders. Evaluaciones y pruebas se insertan entonces durante el Sprint y se programan para llevarse a cabo en varios y mĆŗltiples momentos antes de una fecha lĆmite que, obviamente, es previa a la finalización de Ć©ste.
El Fantasma del Modelo de Cascada es el Gran Problema La pieza clave para entender el rol de UX en un marco como Scrum es entender que (1) el diseƱo es parte del desarrollo de un producto y (2) desarrollar implica tanto delivery como discovery. Son estos dos procesos que corren durante el Sprint, no exclusivamente en puntos extremos (al principio o al final). Como lo expresa Andy Kelk estos procesos se deben entrelazar para lograr dos metas: āBuild the Right Thingā (Discovery) y āBuild the Thing Rightā (Delivery).
Por lo anterior decimos que, para integrarse de manera efectiva con el marco de Scrum, el diseƱo de la experiencia de usuario (UX) no se define exclusivamente a priori o se evalĆŗa a posteriori. Debemos rechazar la idea de un āSprint Zero de UXā si este se piensa como un esfuerzo donde se trata de generar toda la contribución de UX al inicio del proyecto.
Debemos rechazar la idea de una āEvaluación UX al final del Sprintā, si esta se piensa como el Ćŗnico espacio en donde este esfuerzo puede integrarse a la prĆ”ctica de Scrum. En resumen rechazamos pensar en UX como un componente no integrado a Scrum y marcado por el paradigma del modelo de cascada (Waterfall), donde la separación y la especialización son la base.
Para aclarar, debo enfatizar que esfuerzos de descubrimiento inicial (al arrancar un proyecto complejo), o bien evaluaciones formativas en cada evaluación al final del Sprint (ej. pruebas de usabilidad) o pruebas sumativas al final del release, son todas excelentes aportaciones que el profesional UX da al marco de Scrum, pero no son las únicas y las mÔs fundamentales.
La idea central que identifica la relevancia de UX para Scrum estÔ en entender que los procesos de planeación y evaluación no deben hacerse sólo en los puntos extremos de un Sprint, sino dosificarse a lo largo de este.
Para madurar la integración de UX a Scrum seguramente deberemos de transicionar por varias etapas en las que primero introducimos algunos mĆ©todos y componentes de UX en el marco. QuizĆ”s nuestros esfuerzos iniciarĆ”n con un marcado acento Waterfall (separado y especializado), pero no deben permanecer ahĆ. UX deberĆ” integrarse orgĆ”nicamente en el nĆŗcleo de las prĆ”cticas si se aporta fundamentos y mĆ©todos para el diseƱo de la experiencia de usuario.
Conclusión Siempre soy optimista. Creo que aunque en muchos escenarios existe renuencia a la integración de UX con Scrum, la realidad es que los mÔs talentosos miembros de las comunidades Agile y de UCD (User Centered Design) estÔn plenamente conscientes de lo absurdo de las divisiones y son proponentes de la integración inteligente.
Creo que aunque UCD es un marco de métodos robustos, lógicos y valiosos, marcos de desarrollo de producto como Scrum aportan un esquema vÔlido y prÔctico de articulación que tiene mejores oportunidades de ser adoptado por algunas organizaciones.
Un UX con énfasis Waterfall no es tampoco malo y para muchas situaciones es la única forma en cómo el valor del diseño (fundamentos+métodos+estrategia) podrÔ impactar al desarrollo de un producto digital. Busquemos entonces, integración plena donde se puede y esfuerzos puntuales donde no.
UX y Scrum tienen mucho que lograr juntos y esto se lograrĆ” si propiciamos entre ellos, como lo indica el Manifiesto Ćgil: una colaboración, no una negociación contractual.
¿En qué te ayudaron las ideas de esta nota? ¿En qué te puedo ayudar?
Aprecio tus opiniones y comentarios.
EscrĆbeme e-mail: victor.gonzalez@sperientia.com / twitter: @vmgyg
¿Deseas platicar sobre cómo mejorar la experiencia de tus productos o servicios? ContÔctanos: Sperientia [studio+lab]® www.sperientia.com
Nota: Esta nota se públicó originalmente en Medium el 27 de mayo de 2017 y luego en mi libro "Ensayos de Sperientia" (2018). La versión que se incluye aquà tiene ligeros cambios con respecto a esas otras.
All rights reserved Copyright Ā© 2017-2020 VĆctor M. GonzĆ”lez Todos los derechos reservados por VĆctor Manuel GonzĆ”lez y GonzĆ”lez. Sperientia, Sperientia [studio+lab] son marcas registradas. Todas las opiniones expresadas aquĆ son a tĆtulo personal y no representan la opinión de mis actuales o anteriores empleadores, clientes o socios.