Guía Scrum | 11. Estadísticas y métricas que el Scrum Master debe seguir

¿Por qué Scrum Master necesita estadísticas y métricas? En primer lugar, para comprobar si sus métodos de trabajo sobre la previsibilidad de los resultados y la mejora de la eficacia del equipo son eficaces. Pero también para hacer un seguimiento de cómo sus acciones afectan al Equipo de Desarrollo. Es decir, cómo dan forma a la experiencia de usuario del empleado (UX). Entonces, en este artículo, presentamos estadísticas y métricas que el Scrum Master debe rastrear.

Estadísticas y métricas importantes para el scrum master – índice:

1. Medición de los resultados del trabajo del Equipo de Desarrollo
2. Supervisión de la experiencia de usuario de los empleados Desarrolladores
3. Resumen

Medición de los resultados del trabajo del Equipo de Desarrollo

Las estadísticas y métricas más comúnmente utilizadas que Scrum Master debe rastrear son aquellas que describen el ritmo y el flujo de ejecución de la tarea. Estos son el gráfico de quemado, el gráfico de quemado y el diagrama de flujo acumulativo. Estas miden tanto el desarrollo del producto como la efectividad del equipo. Cada uno le permite abordar estos temas desde un ángulo diferente, por lo que es una buena idea mostrarlos juntos. Son herramientas útiles para evaluar el progreso en diferentes escalas, durante un Sprint y durante todo el proceso de desarrollo del producto.

Cuadro de incendio

El gráfico de trabajo pendiente 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 se planeó en el Sprint Backlog o Product Backlog.

Este gráfico también ayuda a determinar la velocidad del equipo de desarrollo, al que también dedicaremos un artículo aparte. Aquí solo mencionaremos que es una cantidad promedio de trabajo realizado durante un Sprint.

Esta sencilla herramienta le permite al Scrum Master no solo ver qué tan eficientemente está trabajando el equipo. También ayuda a responder preguntas:

• ¿Qué parte del trabajo ya se ha completado?
• ¿Cuántas tareas quedan por completar?
• ¿Cuánto tiempo llevará desarrollar el Producto?

Al usar el Burndown Chart, 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 con la creación de soluciones muy innovadoras con un nuevo Cliente. Luego, 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 Burndown Chart.

Gráfico de quemado

El gráfico Burnup es el reverso del gráfico 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 en el número de Sprints o en fechas.

Sin embargo, Scrum Master usa Burnup Chart para un propósito ligeramente diferente. Esto se debe a que no solo lo 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 con el tiempo. Por lo tanto, funciona bien para proyectos con alcance variable.

El Burnup Chart también es una herramienta de planificación que se está volviendo 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.

Diagrama de flujo acumulativo

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 Acumulativo. Presenta el análisis de cuán estable es el ritmo y la productividad del Equipo de Desarrollo. El diseño de sus ejes es el mismo que el Burnup Chart, por lo que a menudo se lo conoce como su versión más compleja.

Sin embargo, el diagrama de flujo acumulativo no es solo para determinar la cantidad de tareas completadas en un período de tiempo determinado. 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 misma función de diagnóstico la 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 de distribuir la fuerza del Equipo de Desarrollo de manera diferente y evitar el tiempo de inactividad.

Supervisión de la experiencia de usuario de los empleados Desarrolladores

El mantenimiento y análisis regular y meticuloso de las estadísticas es una parte esencial del trabajo efectivo de un Scrum Master. Sin embargo, primero debe tener en cuenta la experiencia de 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 forma 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 para que trabaje de manera más eficiente o para recompensarlos por obtener excelentes resultados. Sin embargo, las estadísticas pueden funcionar como una herramienta para presionar al Equipo de Desarrollo. Entonces sus indicaciones se convierten en generadoras de acusaciones y resentimientos. Pueden contribuir a deteriorar la moral del equipo y estropear las prácticas de trabajo en equipo.

El segundo factor importante de la experiencia de los empleados de los Desarrolladores, que el Scrum Master que trabaja con herramientas estadísticas debe cuidar, es la forma de administrar su tiempo. Esto se debe a que el Scrum Master necesita tener suficiente tiempo para cuidar al Equipo de Desarrollo. Por esta razón, en caso de un proyecto grande, vale la pena considerar incluir a una persona adicional en el Scrum Team. Actuará como gerente de proyecto y se encargará de las métricas. Gracias a esto, liberará al Scrum Master -y en cierta medida al Product Owner- de las tareas que lo distraen de trabajar con el Equipo de Desarrollo.

Estadísticas y métricas: resumen

El Scrum Master debe realizar un seguimiento de las estadísticas básicas que describen el trabajo del Equipo de Desarrollo. Su hábil interpretación 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 deben tratar las métricas como una herramienta para evaluar al Equipo, sino 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 le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube.

Autora: Carolina Becker

Como Project Manager, 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 la presión del tiempo la convierten en la mejor persona para convertir proyectos complicados en realidad.

Ver todas las publicaciones

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos