Hace unos años me encontraba trabajando para una consultora media (500 empleados). En aquella época, decidimos hacer un curso de “reciclaje” para todos los compañeros para refrescar y actualizar los conocimientos sobre Scrum y Agile. En la sección de la Sprint Planning, hicimos un experimento, antes de explicar el evento, preguntamos a los asistentes: ¿en qué consiste la Sprint Planning? Lo curioso es que, más del 90% de las personas contestaron: ¡estimar!
Estudiamos como tener una Sprint Planning útil y de valor, ¿Se puede sin estimaciones?
Estimaciones en la Sprint Planning
Scrum ha incluído el concepto de estimación o “size” en la Sprint Planning hasta el año 2020. A pesar de que el concepto “estimar esfuerzo” estaba presente, siempre iba acompañado de matices:
“El trabajo puede variar en tamaño o esfuerzo estimado. Sin embargo, el trabajo planificado durante la Sprint Planning por el Development Team para hacer una previsión de lo que creen que alcanzará en el Sprint siguiente” – Scrum Guide desde 2011
Es decir, por encima de la estimación, debemos tener a los Developers (antiguo Development Team) organizados para planificar el trabajo que consideran viable.
Este matiz es interesante, las estimaciones eran opcionales, de hecho, han sido eliminadas de la versión actual de Scrum. Los Developers deben ser capaces de planificar para hacer su previsión. Además, este matiz rompe con otro factor relevante de Scrum: ¡no existe el compromiso del Sprint!
El compromiso del Sprint
En la primera versión de la guía Scrum se comentaba que debería existir un compromiso entre los Developers (antiguo Development Team) sobre el alcance que serían capaces de acometer. Con el tiempo, se dieron cuenta que esta regla era absurda, los cambios son necesarios. A veces, el Product Owner desea introducir un cambio o bien los propios Developers descubren una manera diferente de acometer el Sprint Goal que se han fijado.
Sin embargo, si abrimos la puerta a los “cambios” podemos convertir el Sprint es un sin fin de cambios continuos, ¡el caos no es agilidad! El límite lo marca el Sprint Goal, el objetivo que nos hemos marcado este Sprint y por el que nos comprometemos. El Sprint Goal debe ser ambiguo, como la vacuna del Covid, ya que hay muchas maneras de resolverlo. Un objetivo ambiguo nos facilita entender lo que queremos conseguir, a la vez que permite cambios siempre que favorezcan la consecución del objetivo.
Por tanto, los Developers deben pactar con el resto del Scrum Team el objetivo, sobre el que planearan el Sprint para tratar de cumplirlo. El alcance pasa a ser parcialmente abierto, ya que es una previsión de lo que consideramos viable.
¿Cómo podemos saber lo que haremos sin estimar?
Un elemento clave que la inmensa mayoría de equipos Scrum no realizan es la Planificación del Trabajo del Sprint. Cómo acabamos de comentar, tenemos que definir un Sprint Goal y una serie de Items del Backlog, ¡pero falta el plan del Sprint!
Los Developers deben organizarse para decidir cómo acometer el Sprint, dividir los Items (PBIs) en tareas técnicas y ser capaces de explicarlo al Product Owner y Scrum Master.
En este ejemplo, un equipo de cinco personas acomodan las diferentes tareas que han previsto en un calendario para saber cómo organizarse. De esta manera, el Scrum Team mantiene una conversación sobre cómo organizarse. Algunos puntos a tener en cuenta son:
- Vacaciones u otras ausencias para conocer nuestra capacidad
- En qué momento abordaremos las tareas (no hay que seguir el mismo orden que el Product backlog).
- Saber cómo vamos a controlar que el Sprint Goal es viable
- Visualizar dependencias
Este ejemplo de Plan de Trabajo no es obligatorio, pero ayuda mucho más que el clásico debate sobre puntos de historia. De hecho, puedes visualizar las vacaciones y, a continuación, rellenar los huecos restantes.
Seguimiento del Sprint
Una de las ventajas de construir un plan de trabajo visual cómo el anterior es la capacidad de un equipo de hacer seguimiento. Cada día, miramos el trabajo que consideramos debía estar hecho y, si no es así, el impacto que conlleva en el resto del Sprint (y en el Sprint Goal).
De esta manera, conseguimos tener Daily Scrum útiles que nos permitan tomar decisiones sobre el estado del equipo. ¡Y sin estimaciones!
Entiendo que, muchas organizaciones, solo saben gestionar en base a estimaciones pero, aunque podamos realizarlas, la conversación de cómo organizarnos debe estar por encima de todo lo demás.
Y tú, ¿haces estimaciones en Scrum?
Como siempre de mucho interés Javier Martín. No obstante, no comparto la idea del «objetivo ambiguo». Creo que eso nos acerca más al caos que a la agilidad. El objetivo tiene que ser la satisfacción de los stakeholders, no tengo duda, pero, incluso en equipos superautoorganizados (palabro inventado) se necesita un «asidero». En otro caso, ¿cómo medimos después?. Abrazo.