Seguimiento de Sprints en Scrum para Big Data & Analytics

Cabecera Datahack expertos en big data

El artículo anterior  estuvo dedicado a la lista de producto (Product Backlog). En esta ocasión quiero comentar sobre el seguimiento dentro del Sprint, algo que también forma parte de la guía de Scrum.

El seguimiento del Sprint

Lo primero que hay que considerar es que las técnicas ágiles están pensadas para simplificar las tareas de gestión. Es así puesto que algunas recaen sobre el equipo de desarrollo, y siempre se prefiere que estén desarrollando antes que reportando el estado del proyecto. Todavía más crítico, el foco del seguimiento se centra en entender lo que queda para conseguir el objetivo del sprint, y en su caso modificar las estimaciones.

Sin embargo, no se pretende analizar cuánto tiempo se ha invertido en lo ya desarrollado, un hecho bastante desconcertante para quienes estén acostumbrados a las metodologías predictivas. Esto es porque Scrum no se pensó especialmente para ahorrar costes de fabricación ni tiempos de desarrollo (al menos no medidos de la forma tradicional), sino para entregar productos más adecuados a las necesidades cambiantes del negocio. Es decir, no debemos asociar ágil con veloz ni con barato, sino con productos de mejor calidad, tanto objetiva como subjetiva, y con mayor capacidad de incorporar cambios sobre la marcha. Por eso tampoco tiene mucho sentido realizar una contabilidad de horas por técnico y tarea, ya que esto inhibe la introducción de cambios, así como el trabajo en equipo.

Estimaciones de tiempo y esfuerzo del Sprint

Enlazando con lo expuesto en el artículo de planificación de sprints que publiqué anteriormente, en proyectos de Big Data, Analytics & Bussiness intelligence es el equipo de desarrollo quien estima lo que es capaz de terminar en un sprint dado, y esto lo hace mediante algún sistema de puntuación para cada ítem que acaba dentro del sprint backlog. Es común acabar convirtiendo la puntuación en horas, pero con el riesgo de caer en la contabilidad clásica de costes.

La utilidad no es tanto la conversión en horas, sino entender que un ítem valorado como 10 puntos requiere el doble de esfuerzo (tiempo supuesta una dedicación del 100%) que uno valorado en 5 puntos. Y también podemos conocer el histórico de puntos entregados en cada sprint, a medida que van sucediendo sus ciclos, para establecer una velocidad media. Esto permite ir afinando más el compromiso de entrega que alcanza el equipo de desarrollo durante la planificación del sprint, y también hacerse una idea de lo que supone el product backlog restante en cuanto a tiempo, entendiendo que es algo que irá evolucionando.

Gráfico de Burn down

Hay varias técnicas para visualizar en medio de un sprint cómo nos encontramos respecto a la planificación. Sin duda, el artefacto más conocido es el gráfico de burn down. Aquí tenemos un ejemplo de gráfico sencillo:

Seguimiento de Sprints en Scrum para Big Data & Analytics

En el eje horizontal aparecen los días hábiles del sprint en un proyecto de Big Data, en este caso 20, y la línea verde representa la previsión de avance diaria. En el eje vertical en este caso figura el esfuerzo restante en días (agregado para todo el equipo), aunque mi recomendación es representar mejor la valoración en puntos. Al inicio del sprint conocemos la estimación total de los puntos a terminar, e idealmente al final del sprint se habrán entregado todos ellos, por lo que la línea verde es una recta que acaba en cero para el eje vertical.

Mientras, la línea roja representa el avance real, e insisto una vez más, no como tiempo real dedicado sino como valoración de puntos de las tareas terminadas conforme al “definition of done”. La línea roja por encima de la azul nos advierte de un retraso respecto a la planificación. Por ello, es el propio equipo técnico quien debe decidir si es posible acelerar el ritmo de desarrollo, o bien considerar reducir el alcance del sprint en el supuesto de que ello no amenace el objetivo del mismo.

Gráfico de Burn Up

Aunque el gráfico de burn down resulta útil, puede inducir a error de interpretación cuando se realizan cambios de alcance durante el sprint, y ya sabemos que hay que contar con ellos si el objetivo lo requiere. Por eso me parece necesario usar también el gráfico de burn up. En la siguiente imagen se aprecia la diferencia:

Seguimiento de Sprints en Scrum para Big Data & Analytics

Pensemos en un proyecto de Big Data donde a mitad del sprint se ve necesario introducir una nueva tarea no planificada al inicio, o bien se trata de una tarea cuya estimación se ha tenido que aumentar al ir conociendo más detalles funcionales. En el burn down podríamos volver a dibujar la recta planificada, que resultará más inclinada si es que mantenemos las escalas originales. Pero el gráfico no nos dice en qué momento se ha producido este cambio.

Viendo ahora el gráfico de burn up, la línea de trabajo planificado total pasa a ser una recta horizontal al inicio del sprint. Si hay cambios de valoración se van a poder visualizar como saltos en dicha línea. La otra línea ya no es el trabajo pendiente, sino el completado hasta el momento, y se espera que al final del sprint alcance la línea del trabajo planificado total. Si no se alcanza, al menos se puede tener una idea de hasta qué punto ha sido el cambio el que ha provocado esta situación.

Conclusión

La lección práctica es que parte del aprendizaje de Scrum consiste en saber cómo cambia la planificación durante el propio sprint (saltos en la línea horizontal), y planificar los siguientes sprints con suficiente holgura como para absorber este tipo de cambios inevitables. Pero, cuidado, no se trata de abrir la puerta a cualquier cambio dentro del sprint, estos cambios tienen que estar justificados siempre conforme al objetivo, en caso contrario el equipo de desarrollo se va a ir desentendiendo del mismo.

Si habéis seguido todos los artículos anteriores, y queréis profundizar un poco más allá de la guía de Scrum, os sugiero este otro documento más detallado.


José Julio López, Business Intelligence, Data Science, IT Project Manager. SCRUM Master, PMP y antiguo alumno del máster de Big Data & Analytics de DataHack.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *