El Sprint Board es una de esas herramientas que se usan en Scrum de la que siempre se habla en las formaciones y que parece inherente al propio Scrum. En general la mayoría de las discusiones se centran en si prefiero un tablón físico o digital, pero hoy voy llevar el debate más lejos, voy a hablar de mi propia experiencia con el mismo y de algunas reflexiones que he tenido a lo largo del tiempo con alguno de mis compañeros.
Lo primero que me gustaría matizar es que el Scrum Board no es obligatorio en Scrum. Con esto quiero decir que no aparece en ninguna de las páginas de la Scrum Guide. Que no sea obligatorio no quiere decir que no sea muy recomendable y que una de las primeras cosas que se suele hacer cuando se inicia un proyecto en Scrum es crear el Sprint Board.
Pero ¿Para qué queremos el Sprint Board?. La primera reflexión que quiero hacer es que el Sprint Board no deja de ser una herramienta y tenemos que recordar el primer principio Agile. “Individuos e interacciones sobre procesos y herramientas“. En mi opinión el Sprint Board es útil cuando el Development Team lo usa para mejorar sus interacciones, es decir, cuando le ayuda a mantener conversaciones que de otra forma no tendrían, por ejemplo, hablar sobre una tarea que nadie está haciendo actualmente. Y me diréis ¿Esto no es siempre así?, pues por desgracia en muchas ocasiones he visto como los equipos eran obligados a usar un Sprint Board para poder controlar y supervisar su trabajo. Es decir, cambiamos el Gantt por un Sprint Board y encima obligamos al Development Team a mantenerlo.
También es típico justificar el mantenimiento del Sprint Board en aras de la transparencia hacia el Product Owner. Cuántas veces hemos oído frases del tipo: “El Product Owner tiene que saber el estado del Sprint para la reunión de seguimiento de mañana”. Ante esta frase pregunto ¿Cómo se hacía esto antes de implantar Scrum?. Yo recuerdo esas reuniones de seguimiento que se hacían cada 2 o 3 meses (si no cada más). Ahora parece que Scrum implica que diariamente toda la organización debe saber el estado del Sprint en curso, no es suficiente con el estado en el que terminó el Sprint anterior. Por otro lado, si el PO necesita saber cómo va el Sprint, en mi opinión, debería usar el empirismo, es decir, si por ejemplo estimamos en puntos, y el 90% de las veces hemos terminado 80 puntos, debería prever que más o menos eso es lo que va a pasar este Sprint, obviamente para que el PO pueda hacer esto debemos darle transparencia, pero no del Sprint en curso, si no de los Sprint pasados.
Por otro lado el Sprint Board se suele usar típicamente durante la Daily Scrum para ayudar a generar esas conversaciones que sin esa transparencia no se producirían. Relativo a esto pensemos en lo que dice la Scrum Guide “El Development Team es el encargado de establecer la estructura de la reunión y esta se puede conducir de diferentes maneras si se enfoca en el progreso hacia Sprint Goal”. Es decir, si un equipo decide que para inspeccionar el progreso del Sprint Goal no requiere de un Sprint Board y esto les funciona ¿Deberíamos obligarles a usarlo? En mi opinión la respuesta es no, que algo sea una buena práctica no implica que funcione siempre y por tanto si el equipo ha encontrado algo que les funciona no deberíamos obligarlos a cambiarlo.
Como último punto de reflexión es común tener conversaciones sobre equipos que no actualizan nunca su Sprint Board hasta el último día del Sprint (o en el peor de los casos durante el Sprint Planning del siguiente Sprint). Cuando observo estos comportamientos, mi primera reacción no es obligar al equipo a actualizarlo, si no preguntarme si esa herramienta les está dando valor, de no ser así, nunca la van a actualizar o en caso de hacerlo nunca van a estar comprometidos de verdad en que refleje el estado real del Sprint. Es cierto que muchas veces debemos aconsejar y recordar su uso para que el Development Team observe el valor que les da esta herramienta. Pero si pasado el tiempo siguen sin encontrarle valor ¿No deberíamos ir más allá y plantearnos que el problema puede estar en otro sitio?
En conclusión, creo que el Sprint Board y las conversaciones que se producen debido a el es una herramienta no solo para el Development Team, también es una gran herramienta para el Scrum Master, donde puede observar no solo si el Scrum Team es maduro, si no también si la organización ha interiorizado los valores que hay detrás de Agile.
Tabla de contenido
Entradas relacionadas
Estimar o no estimar, he ahí el dilema (parte 1 de 2)4 (1)
Comentarios recientes