Resumen: Las métricas de scrum son puntos de datos específicos que los equipos de scrum supervisan y utilizan para mejorar la eficiencia y la eficacia, tomar decisiones más fundamentadas, ser más eficientes en la planificación y ejecución y definir objetivos y planes de mejora.
"Si no puedes medir algo, no puedes mejorarlo", recalcó el famoso pensador de gestión Peter Drucker. Esta afirmación no se aplica a todos los ámbitos de la vida, pero sí a los equipos que practican la metodología scrum ágil. Utilizando ciertas métricas, los equipos de scrum pueden ajustar, cambiar y definir mejor la efectividad del equipo.
¿Qué es scrum?
Scrum es un marco y una forma de trabajar ágil que ayuda a los equipos a abordar problemas complejos y, al mismo tiempo, les permite desarrollar soluciones de forma iterativa en torno a un objetivo. Los procesos de trabajo de scrum se basan en sprints, que son un periodo de tiempo fijo durante el cual los equipos de scrum deben completar una serie de tareas.
Debido a su adaptabilidad, los marcos ágiles como scrum se han adoptado hasta en equipos no tecnológicos, como los de soporte, diseño y marketing, entre otros. Es por eso que las métricas de scrum son cada vez más importantes para medir el rendimiento y la efectividad de los equipos.
¿Qué son las métricas de scrum?
Son puntos de datos específicos que los equipos de scrum supervisan y utilizan para mejorar su eficiencia y eficacia. Si se definen, comprenden e implementan, pueden convertirse en datos muy valiosos que contribuyan a guiar y mejorar el recorrido ágil de los equipos.
Los equipos de scrum emplean estas métricas para tomar decisiones más fundamentadas y poder planificar y ejecutar el trabajo de una forma más eficiente. También las pueden usar como punto de referencia sobre el statu quo y fijar tanto objetivos como planes de mejora. De hecho, actualmente no hay ningún criterio estándar en el sector que sirva como referencia, ya que comparar puntos de datos sin contexto es como comparar peras con manzanas. Cada equipo es único: puede ser más grande o más pequeño, utilizar tecnologías diferentes, realizar tipos de trabajo distintos, etc.
Cada equipo tiene que ponerse de acuerdo en qué grupo de métricas quiere fijarse y cómo quiere usarlas. No se trata de un trabajo individual ni de un asunto que la dirección o los responsables de equipo deban definir y aplicar en nombre de los equipos.
¿Por qué necesitas métricas de scrum?
Las métricas de scrum pueden ayudar a los equipos a fijar puntos de referencia y a marcar la dirección de sus proyectos. Por eso, las métricas de scrum son útiles tanto para los equipos establecidos como para los nuevos.
Hacer un seguimiento de las métricas de scrum también permite dar visibilidad a varias dimensiones que definen la eficacia de un equipo, ya sea la velocidad, la capacidad, la predictibilidad en la entrega o la calidad del producto. Las métricas clave pueden fomentar la consciencia sobre el rendimiento de un equipo y motivarlo a cambiar y mejorar. Es más, incluso pueden ayudarle a medir la felicidad y satisfacción del equipo con el paso del tiempo.
A menudo, los equipos confían demasiado en su intuición para hacerse una idea de su rendimiento. Seguro que hay muchos motivos prácticos detrás de este hábito, pero así lo que hacen es dejar escapar una gran oportunidad.
¿Se pueden usar las métricas de scrum como KPI?
Sí y no. Las métricas de scrum se pueden usar para configurar indicadores clave de rendimiento (KPI) dependiendo del tipo y del alcance del trabajo. Es decir, las métricas de scrum por sí solas no pueden medir el valor de un cliente ni indicar si el equipo ha entregado el trabajo correcto. Para un equipo ágil, los KPI deben mostrar hasta qué punto su trabajo contribuye a las prioridades de la empresa.
A la hora de medir el rendimiento de un equipo de scrum, se deben tener en cuenta otras métricas más allá de las de scrum. Por ejemplo:
- Retorno de la inversión (ROI) de una empresa: las empresas miden este valor de muchas formas según los objetivos que tengan, como el aumento de los ingresos y los usuarios activos al mes (UAM).
- Satisfacción del cliente: las métricas de encuesta, como el Net Promoter Score® (NPS) y la satisfacción del cliente (CSAT), pueden ayudar a hacer un seguimiento de los resultados de un proyecto. Es importante que las métricas de satisfacción del cliente se mantengan estables en cada lanzamiento, ya que eso indica el valor que aporta el equipo de scrum a los clientes.
- Satisfacción del equipo: con solo preguntar al equipo si se siente motivado y comprometido con el proyecto, puedes detectar problemas como la rotación, el desgaste y la insatisfacción de los desarrolladores.
Eventos clave de scrum y qué métricas analizar
While agile scrum defines several recurring events — sprint, sprint planning, daily scrum, sprint review, sprint retrospective — these don’t provide any guarantees of progress or success. However, each one allows team members to inspect and adapt how they work.
Planificación de sprints
Al inicio de un sprint, se realiza una reunión de planificación en la que un equipo convierte las descripciones de las historias en tareas detalladas. De esta forma, se puede estimar la cantidad de trabajo que se entregará durante el sprint. Hay varios puntos de datos que pueden contribuir a hacer que la planificación de sprints de tu equipo sea más eficiente, como los objetivos de sprint, la velocidad actual y la capacidad del equipo y el tipo de trabajo. Usamos una plantilla para reuniones de planificación de sprints, que nos sirve de guía para planificar los sprints.
Objetivos del sprint
Los objetivos de sprint ayudan a los equipos a decidir qué quieren conseguir en cada sprint, a trabajar de una forma cohesionada y a establecer prioridades. Además, suelen contribuir a unos resultados a largo plazo que se pueden lograr mediante varios sprints. Se debe dar prioridad a un objetivo u otro en función del impacto que pueda tener en estos resultados a largo plazo. Un equipo realmente efectivo revisará sus objetivos y prioridades periódicamente y definirá una estrategia para secuenciar y dividir el trabajo de los ingenieros.
Velocidad del equipo
La cantidad de trabajo a la que puede comprometerse un equipo con un sprint se reduce esencialmente a la velocidad, al volumen de trabajo que puede realizar durante un periodo determinado, así como a la capacidad o a la disponibilidad que tiene. Un gráfico de velocidad, como el que usamos en Jira, muestra la cantidad de valor que se entrega durante un sprint. Esto nos ayuda a predecir el volumen de trabajo que un equipo puede realizar para futuros sprints. La velocidad de un equipo solo se puede entender después de ejecutar algunos sprints juntos como equipo. Con el tiempo, la velocidad se estabilizará gracias al trabajo en equipo. Esto implica no solo ampliar las tecnologías empleadas, sino también conocer la experiencia de los demás y aprender a trabajar juntos.
El ejemplo siguiente es una gráfica de velocidad con (1) estadística de estimación basada en puntos de historia, (2) compromiso (que es una estimación de todos los problemas del sprint), (3) estimaciones completadas y (4) sprints completados.
Capacidad del equipo
No es ninguna sorpresa que la cantidad de trabajo que un equipo pueda asumir en un sprint sea proporcional a su capacidad y disponibilidad. De nada sirve llevar una velocidad estable si la mitad del equipo está de vacaciones. Una forma de planificar su capacidad es anotando la disponibilidad de cada miembro con unos cuantos sprints de antelación y sumándolo todo para obtener un porcentaje de la capacidad total. Dado que a cualquier persona le pueden surgir imprevistos o emergencias, no está de más dejar un 10 % de margen en el compromiso con el sprint para evitar que el equipo se comprometa en exceso y entregue menos trabajo de lo previsto.
Tipo de trabajo
When your sprint backlog is a growing mix of feature work, bug fixes, and technical debt, it becomes tricky to see where your team is dedicating their time in the sprint. It’s easy for bugs or tech debts to sneak into your sprint, especially if the development team is passionate about quality. But if a team isn’t careful, it can end up after the sprint wondering why it didn’t ship enough customer values as planned.
Sé consciente del trabajo que asignas a tu equipo: comprueba cómo repartes los diferentes tipos de trabajo durante la planificación del sprint. De este modo, aunque haya mucha deuda técnica y tareas de calidad en el backlog, podrás resolverlo de forma estratégica programando un sprint específico para deuda técnica o subiendo el nivel de exigencia en el control de calidad.
Reuniones rápidas (también conocidas como "scrums diarios")
Las reuniones rápidas (o scrums diarios) son breves y tienen lugar cada día para que los miembros de los equipos de scrum pongan en común todo el trabajo realizado hasta entonces. Para que esos equipos sean efectivos, tienen que ir un paso más allá y no centrarse solo en lo que haya avanzado cada persona respecto a su lista de tareas pendientes. Estas reuniones son una oportunidad para analizar el progreso del sprint con el equipo y modificar las prioridades según las decisiones que haya que tomar a diario, ya sean grandes o pequeñas, las cuales pueden tener un enorme impacto en el resultado final del sprint.
En estas reuniones, puede ser útil contar con los siguientes datos y métricas:
Progreso hacia los objetivos del sprint
Si bien los miembros del equipo pueden tener claro cuál es el estado y el progreso de su trabajo, puede ser fácil perder de vista el progreso global hacia los objetivos colectivos del sprint. Por eso, es importante mostrar una lista de los objetivos del sprint durante las reuniones rápidas para comentarla con el equipo.
Tómatelo como una oportunidad para comprobar si todo marcha según lo previsto. Si no es el caso, ¿por qué y qué se puede hacer al respecto? Si es algo que no tiene solución, es importante comunicárselo a las partes interesadas clave para que estén al corriente de todo.
Trabajo pendiente de los sprints
Para tener una idea clara de cómo avanza el equipo, este debe repasar rápidamente el sprint utilizando un gráfico de trabajo pendiente. En este gráfico se registra el trabajo pendiente terminado a lo largo de un sprint. Para ello, se comparan el tiempo y la cantidad de trabajo que se debe entregar, los cuales se miden en horas o puntos de historia. Este gráfico ayuda a predecir la capacidad que tendrá el equipo para completar el trabajo en el plazo designado, así como a supervisar el alcance. Si un gráfico de trabajo pendiente registra una caída brusca, podría deberse a una estimación inexacta del trabajo.
A continuación se muestra un gráfico de trabajo pendiente de un sprint en Jira, con (1) la estadística de estimación, (2) los valores restantes que representan la cantidad total de trabajo pendiente en el sprint y (3) una pauta que es una aproximación de en qué punto debería estar tu equipo.
Distribución de la carga de trabajo
Una cosa que el equipo no debería perder de vista es la cantidad de trabajo que se asigna a cada miembro. Esto se aplica principalmente a las empresas con una cultura de teletrabajo, ya que cuesta saber cuántas tareas asume cada persona. Si no tienes forma de ver esta información, podría ser que algún miembro de tu equipo esté sobrecargado de trabajo. Las reuniones rápidas son un espacio donde el equipo puede pedir ayuda y donde también se puede redistribuir la carga de trabajo, de modo que todo el mundo pueda trabajar en mejores condiciones para lograr los objetivos del sprint.
Hay algo que debes tener presente a la hora de usar esta métrica con tu equipo: no la conviertas en un arma. Si la usas para medir la productividad de cada miembro, podrías acabar desmotivando al equipo. Te recomendamos que crees un entorno seguro para que todos puedan hablar abiertamente sobre la carga de trabajo que tienen y si necesitan ayuda con algo.
Consulta información útil en su contexto
Una vez que hayas establecido una cadencia en torno a los eventos de scrum, es importante que utilices métricas continuamente para optimizar el rendimiento. Con la información útil, los equipos pueden acceder a métricas cuando las necesitan: durante la planificación de sprints, en la reunión rápida diaria o cuando quieren optimizar las entregas. Puedes consultar la información útil en la esquina superior derecha de las vistas de tablero, backlog e implementaciones de Jira.
Retrospectiva del sprint
Incluso los mejores equipos pueden beneficiarse de las retrospectivas de sprints. Tienen lugar tras finalizar un sprint para comentar con el equipo cómo ha ido todo, celebrar lo que ha salido bien y ver qué se podría mejorar y por qué. Obviamente, este es el momento y el lugar perfectos para repasar las métricas clave del sprint, incluida la consecución de objetivos y la satisfacción durante el sprint.
A continuación se muestra un ejemplo de una retrospectiva que hice con mi equipo en una página de Confluence:
Consecución de objetivos del sprint
¿Cuál fue el rendimiento del equipo en relación con los objetivos marcados durante la planificación del sprint? Si el equipo logró terminar todo el trabajo acordado, ¡enhorabuena! Si no es así, ¿qué podría haberse hecho mejor? Al evaluar los resultados del equipo, puede ser útil recurrir a las métricas de scrum que ya hemos analizado. Cualquier mejora en el flujo de trabajo del equipo merece un reconocimiento; tal vez el equipo avanzó más rápido porque no surgió ningún imprevisto. En el caso de los equipos que practican DevOps, este también puede ser un buen momento para repasar las métricas DevOps clave, como la duración del ciclo o la frecuencia de implementación, para ver qué mejoras pueden introducirse en el proceso de entrega que contribuyan a aumentar las posibilidades de lograr los objetivos de los sprints. Así ayudarás a tu equipo a abordar el problema y a idear un plan de acción más claro.
Satisfacción con el sprint
Aquí bastaría con preguntar a tu equipo si está satisfecho con el sprint. Algunos equipos usan una escala numérica, anécdotas o incluso emojis o GIF. Puedes pedir a tu equipo que reflexione sobre los objetivos que tenía marcados y preguntarle si el tipo de trabajo se correspondía con esos objetivos. ¿Se dedicó demasiado tiempo a la deuda técnica en vez de a terminar una función?
A lo largo de la retrospectiva, anima a los miembros del equipo a dar su opinión y pídesela expresamente si hace falta. En las mejores retrospectivas suele haber muchos puntos de vista y opiniones variadas. Lo importante es que, al final de la reunión, haya habido un amplio consenso sobre cuáles han sido los principales problemas, qué propietarios se deben nombrar y cuál es el plan para hacer un seguimiento de las incidencias clave.
Conclusión
El objetivo de scrum es ayudar a los equipos a trabajar mejor y el de las métricas de scrum, ayudarles a que scrum se adapte a ellos de la forma que más les convenga. El uso de métricas de scrum no debe suponer una carga para ellos, sino que deben servirles de inspiración. No hace falta hacer un seguimiento de cada punto descrito en este artículo; se puede empezar por una o dos métricas y ver si el equipo nota alguna mejora. También puede ser que tu equipo ya tenga las prácticas de scrum muy por mano y que, por tanto, esas métricas no le aporten mucho. ¡Cualquier equipo querría estar en ese punto! Eso sí, no te olvides de los buenos hábitos que esas métricas te han ayudado a establecer. Ve consultándolos de vez en cuando para mantener las prácticas de scrum por buen camino.
Recursos relacionados
