¿Por qué necesita el Scrum Master estadísticas y métricas? Primero, para verificar si sus métodos de trabajo sobre la predictibilidad de resultados y la mejora de la efectividad del equipo son efectivos. Pero también para hacer un seguimiento de cómo sus acciones afectan al Equipo de Desarrollo. Es decir, cómo moldean la experiencia del usuario empleado (UX). Así que en este artículo, presentamos estadísticas y métricas que el Scrum Master debería seguir.
Las estadísticas y métricas más comúnmente utilizadas que el Scrum Master debería seguir son aquellas que describen el ritmo y el flujo de la ejecución de tareas. Estas son el Gráfico de Burnup, el Gráfico de Burnup y el Gráfico de Flujo Acumulado. Estas medidas evalúan tanto el desarrollo del producto como la efectividad del equipo. Cada una permite abordar estos temas desde un ángulo diferente, por lo que es una buena idea mostrarlas juntas. Son herramientas muy útiles para evaluar el progreso en diferentes escalas, durante un Sprint así como en todo el proceso de desarrollo del producto.
El gráfico de burndown muestra al Scrum Master y al Equipo de Desarrollo cuánto trabajo se ha realizado y cuánto queda por hacer. El eje X muestra el tiempo restante para completar el trabajo. El eje Y muestra la cantidad de trabajo que queda por hacer que estaba planificada en el Sprint Backlog o Product Backlog.
Este gráfico también ayuda a determinar la Velocidad del Equipo de Desarrollo, a la que también le dedicaremos un artículo separado. Aquí solo mencionaremos que es una cantidad promedio de trabajo realizado durante un Sprint.
Esta herramienta simple permite al Scrum Master no solo ver qué tan eficientemente está trabajando el equipo. También ayuda a responder preguntas:
Al usar el Gráfico de Burndown, el Scrum Master debe tener en cuenta que no es la única herramienta para evaluar estadísticamente el progreso del equipo. Funciona mejor para proyectos donde el alcance del trabajo es fijo y conocido. No funciona bien al crear soluciones muy innovadoras con un nuevo Cliente. Entonces, la cantidad de trabajo a realizar en todo el proyecto – es decir, el contenido del Product Backlog – puede cambiar significativamente durante el proyecto, lo que dificulta el uso del Gráfico de Burndown.
El Gráfico de Burnup es el reverso del gráfico de burndown discutido anteriormente. Aquí también, el eje Y muestra la cantidad de trabajo que queda por hacer. El eje X, por otro lado, muestra el tiempo de finalización expresado ya sea en el número de Sprints o en fechas.
Sin embargo, el Scrum Master utiliza el Gráfico de Burnup para un propósito ligeramente diferente. Esto se debe a que no solo ayuda a medir el progreso del producto y el progreso del Equipo. Esta métrica también evalúa cómo cambia el alcance del trabajo en un proyecto a lo largo del tiempo. Por lo tanto, funciona bien para proyectos con alcance variable.
El Gráfico de Burnup también es una herramienta de planificación que se vuelve más efectiva con el tiempo. Proporciona respuestas a la pregunta de cuánto trabajo se estima que hará el Equipo de Desarrollo en el próximo Sprint.
El tercer tipo de diagrama que es muy fructífero en el trabajo del Scrum Master con el Equipo de Desarrollo es el Diagrama de Flujo Acumulado. Presenta el análisis de qué tan estable es el ritmo y la productividad del Equipo de Desarrollo. La disposición de sus ejes es la misma que la del Gráfico de Burnup, por lo que a menudo se le llama su versión más compleja.
Sin embargo, el Diagrama de Flujo Acumulado no solo sirve para determinar el número de tareas completadas en un período de tiempo dado. También tiene en cuenta el número de tareas que están esperando en la cola para su ejecución. Gracias a esto, permite diagnosticar los llamados “cuellos de botella” – momentos del proceso que ralentizan la creación de un producto.
Esta característica diagnóstica lo convierte en una de las métricas más útiles en manos del Scrum Master. Esto se debe a que permite reorganizar el trabajo de manera que se distribuya la fuerza del Equipo de Desarrollo de manera diferente y se eviten tiempos de inactividad.
El mantenimiento y análisis regular y meticuloso de estadísticas es una parte esencial del trabajo efectivo de un Scrum Master. Sin embargo, debe tener en cuenta primero la experiencia del usuario empleado de los desarrolladores, es decir, la forma en que perciben el trabajo en el Equipo Scrum. Sin embargo, no es la calidad de las métricas lo que decide, sino la manera en que el Scrum Master las utiliza.
Si las estadísticas se mantienen de acuerdo con los principios de Scrum – son transparentes, públicas y comprensibles para los Desarrolladores involucrados – pueden ser una forma de motivar al equipo a trabajar de manera más eficiente o recompensarlos por grandes resultados. Sin embargo, las estadísticas pueden funcionar como una herramienta para presionar al Equipo de Desarrollo. Entonces, sus indicaciones se convierten en un generador de acusaciones y resentimientos. Pueden contribuir a deteriorar la moral del equipo y arruinar las prácticas de trabajo en equipo.
El segundo factor importante de la experiencia del empleado de los Desarrolladores, del que el Scrum Master que trabaja con herramientas estadísticas debe cuidar, es la manera de gestionar su tiempo. Esto se debe a que el Scrum Master necesita tener suficiente tiempo para cuidar del Equipo de Desarrollo. Por esta razón, en caso de un gran proyecto, vale la pena considerar incluir a una persona adicional en el Equipo Scrum. Él/ella actuará como gerente de proyecto y se encargará de las métricas. Gracias a esto, aliviará al Scrum Master – y en cierta medida al Product Owner – de las tareas que lo distraen de trabajar con el Equipo de Desarrollo.
El Scrum Master debería hacer un seguimiento de las estadísticas básicas que describen el trabajo del Equipo de Desarrollo. Su interpretación hábil aumenta la posibilidad de detectar rápidamente problemas en el trabajo del Equipo y reaccionar ante ellos. Sin embargo, más importante que mantener los gráficos es lo que el Scrum Master hace con ellos. No deberían tratar las métricas como una herramienta para evaluar al Equipo, sino más bien considerarlas como una ayuda útil para motivar al Equipo y diagnosticar su propia forma de hacer las cosas. Esto se debe a que las métricas solo serán herramientas útiles si ayudan a facilitar los procesos de mejora del Equipo y del Producto.
Si te gusta nuestro contenido, únete a nuestra comunidad de abejas trabajadoras en Facebook, Twitter, LinkedIn, Instagram, YouTube.
Como Gerente de Proyectos, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo presión de tiempo la convierten en la mejor persona para hacer realidad proyectos complicados.
¿Eres un freelancer que busca formas de promocionar su portafolio? Hoy en día, no solo…
La gestión financiera digital y la contabilidad en línea se han vuelto cada vez más…
Los estatutos del proyecto son el pan y la mantequilla de la gestión de proyectos.…
Las organizaciones de diversas industrias establecen relaciones con posibles empleados, proveedores y socios todos los…
Hay más que suficientes técnicas de gestión por ahí. Algunas parecen intrincadas, mientras que otras…
¿Sabes cómo empezar una ONG? ¿Has estado pensando en ello? ¿Eres consciente de lo que…