Post original publicado en alianza con Libre Scrum, mas info en www.librescrum.com
Imagina que acabas de tomar desayuno, y que para variar te entregan la responsabilidad de hacer el almuerzo del día de hoy. Tu familia ha expresado la necesidad de comer un platillo en específico que puede que sepas cocinar, o puede que no. En el mejor de los casos, entiendes perfectamente lo que te están pidiendo y tienes todos los ingredientes necesarios a mano, por lo que la mañana será relativamente sencilla y el almuerzo saldrá sin ninguna complicación. Suena genial, pero lamentablemente el mejor de los casos rara vez ocurre en la realidad.
Has cocinado, sí, pero no sabes hacer cada uno de los platillos existentes. No tienes idea de cómo servirles lo que necesitan, aunque tal vez puedas llegar a algunas conclusiones lógicas. Sin embargo, te faltan algunos de los ingredientes, y asumamos que en tu casa no serás necesariamente tú quien los compre, que irá un tercero y que probablemente te traerá algo diferente a lo que solicitaste.
Decides cortar por lo sano, y dedicar tu día entero sólo a ver lo que necesitas para poder preparar el almuerzo al día siguiente, mientras piensas que todo hubiese sido mucho más fácil si en lugar de esperar a terminar el desayuno, te lo hubiesen pedido con algunos días de anticipación. Tu familia por supuesto, se encuentra molesta, ya que su almuerzo deseado tendrá que esperar, pero por suerte tu madre o tu hermana pueden improvisar algo y salvar la situación. Desafortunadamente, ninguna de ellas vendrá a desarrollar el backend de la interfaz de usuario que requiere el cliente, mucho menos a conectarla con los sistemas legado del proveedor.
Es de libro que la Planificación del Sprint debería durar ocho horas maximo para una iteración de un mes (proporcionalmente menos para períodos más cortos), y que obviamente, debe realizarse antes de comenzar con el desarrollo. Suena bastante obvio, pero seamos honestos, ¿A cuántas personas conocemos capaces de mantener la concentración por más de dos horas?
Realizar una larga y comprimida sesión de planificación, que usualmente suele ser interrumpida (Y con toda la razón) por dudas sobre dependencias, no es en justas palabras, una experiencia muy amena. Más todavía si debemos pausarla para que algunos de nosotros vayan a revisar código, o a conseguir validaciones con terceros que ni siquiera estaban contemplados en la invitación.
Imagina que estás a toda velocidad revisando las historias necesarias, pero que de pronto surge una de esas dudas complicadas que no puedes resolver, y que debe estar resulta para que el equipo determine si es factible realizar el trabajo solicitado. ¿Los vas a dejar sentados mientras vas a validarlo? ¿Qué pasa si quien puede responderte está en una reunión? ¿O almorzando? ¿O se alejó del PC y dejó su teléfono cargando? O peor, ¿Trabajas en un ecosistema arcaico donde la única forma de conseguir respuestas es presionando por correo electrónico?
Para evitar estos problemas, estimados, es que se inventó el refinamiento. Una práctica que no encontrarán en la guía Scrum en calidad de ceremonia y de la que, sin embargo, todo el mundo habla. Y su aplicación es bastante sencilla. En lugar de llegar a revisar las historias dentro de la próxima planificación, tomémonos pequeños intervalos dentro del Sprint actual, para revisar lo que se nos viene. Ya sea una media hora diaria en la mañana, o un espacio de una hora en las tardes de cada martes y jueves. Dependerá de lo que al equipo más le acomode.
En esta ceremonia revisaremos las historias, generaremos planes de acción para resolver dependencias o dudas que mantengan alta la incertidumbre, y si corresponde, les daremos peso. Y si algo queda pendiente, pues lo retomaremos en la próxima sesión de refinamiento.
Entonces, ¿Dejamos de hacer la Planning? ¡No, claro que no! Sólo que ahora cuando vayas a realizarla, llegarás con las dudas resueltas, con la información fresca, con las historias pesadas y con las dependencias validadas, por lo que el tiempo que le tomará al equipo decidir cuanto tomará, será mucho menor al habitual.
Así de simple, no hay mucho más que añadir. Pero como sabemos que les encantan los punteos, les dejamos algunos de los beneficios de realizar refinamientos:
1) Eliminas el tiempo muerto entre validaciones.
Supongamos que revisas las historias con tu equipo un día martes. Ninguna de las historias se puede tomar porque se necesitan datos que otro equipo posee. Se baja el telón, los chicos siguen desarrollando lo suyo mientras que el facilitador o el Product Owner consiguen esos datos. Ya con la información obtenida, retoman el refinamiento el jueves, y se da un análisis y planificación con menor incertidumbre.
2) Aumenta la confianza a la hora de estimar
Sobre todo en organizaciones con un área de negocios autoritaria, que indica qué PBI se DEBEN tomar de inmediato. La presión de estimar con tiempo es mucho menor a cuando lo haces a última hora, ya que te permite resolver dudas que los más tímidos suelen omitir por el nerviosismo de tenerlo todo antes de que se acabe el timebox de la ceremonia. En el fondo, puedes dedicar más tiempo a entender los requerimientos, y con un mayor entendimiento, viene una mejor estimación.
3) Se comunica mejor la visión del producto
Ya que el equipo no sólo estará al tanto de lo que están haciendo ahora, sino que además tendrán presente lo que viene después. Esto facilita la comprensión holística de lo que se está realizando, ya que al entender cuáles son los próximos pasos, facilitamos la creatividad y la coordinación del trabajo que realizamos actualmente.
4) Facilita el análisis del próximo Sprint.
A medida que vas completando el desarrollo de tu iteración, es muy probable que algunas personas vayan quedando en el aire. Sabemos que el tener todo listo antes del viernes no es muy común, pero asumamos que en ocasiones no es necesario que entre cinco personas estén metiendo mano en la integración de una API.
Pues bien, aquellos que estén relativamente listos, pueden comenzar con actividades características del inicio del Sprint siguiente, como: Analizar las próximas historias, identificar las tareas necesarias y generar los casos de prueba que asegurarán su calidad.
5) Reduce dependencias del Product Owner
Y no lo malinterpreten, el P.O. siempre será necesario en nuestro framework favorito. Pero al saber que el equipo tiene claro lo que verá en los próximos dos Sprints, tal vez pueda aprovechar para tomarse vacaciones.
En fin, podemos encontrar una gran cantidad de beneficios de esta pseudo ceremonia a medida que la analizamos. Sin embargo, debemos recordar que en la vida real no existen las balas de plata, y que cada nueva solución, si bien nos quita algunos problemas de los hombros, puede añadir otros más.
Si actualmente tienes planificaciones que te enriquecen, y las historias con las que trabajan son lo suficientemente claras, tal vez esto no sea para ti. Pero si eres de los muchos que tiene sesiones de planificación interminables que terminan por extenderse a un segundo día, pues te recomendamos intentarlo.
Recuerda que siempre debemos tener en mente el cómo podemos mejorar continuamente la forma en la que entregamos valor.
Artículo sugerido por los seguidores de Instagram, si les interesa un tema en particular, no duden en comunicárnoslo!
¿Te ha gustado el artículo? ¿Ejecutas refinamientos con tu equipo? ¡Escríbenos si quieres mas información!