Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

En nuestro trabajo diario con los Equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

El Proceso

Con esa idea en mente, en uno de nuestros clientes decidimos utilizar y relacionar diferentes métricas que estamos recogiendo, tratando de encontrar patrones y/o disfunciones en el sistema, que nos ayudaran a comprender por qué ocurría lo que ocurría.

Nº de Historias

Empezamos con lo más simple y habitual. Comparamos la cantidad de historias de usuario que planifican con la cantidad de las que entregan los equipos Scrum sprint a sprint, buscando encontrar entre otras cosas:

  • Grado de estabilidad en la tasa de entrega.
  • Si están siendo arriesgados o conservadores a la hora de planificar.
  • Grado de confluencia entre lo planificado y entregado.

Éste es el gráfico que nos encontramos, mostrando los datos de los últimos 12 sprints.

Aunque con mucha variabilidad entre sprints, la entrega es estable con una ligera tendencia a aumentar. Sin embargo, ¿por qué tenemos tantos picos? La entrega de producto, ¿se mantiene en el picos, aumenta o disminuye?

 

Relacionar Nº Historias y Coste en Puntos

Antes de incorporar otras métricas, decidimos comprobar si la tasa de producto entregado se mantenía en proporción a la cantidad de historias entregadas. Aun no disponemos del aporte de valor al negocio de cada una de las historias de usuario, por lo que nos hemos tenido que conformar con utilizar el puntos de historia asociados por los equipos Scrum.

Esto fue lo que nos encontramos:

En general se mantenía la proporción. A una misma cantidad de historias, se entregaba una proporción similar de puntos de historia. Nos ayudó a entender que el coste medio en puntos de una historia de usuario estaba estabilizado.

Sin embargo, teniendo tanta variación no podíamos predecir la tasa de entrega en futuros sprints. Algunos picos se explicaban por la adaptación al teletrabajo por la COVID-19, o por la entrega de producto pendiente del sprint anterior, o por periodos vacacionales. Pero ¿y los descensos? ¿Por qué se producen? ¿Ha ocurrido algo en esos sprints de lo que no somos conscientes?

 

Relacionar Historias e Incidencias

Los Equipos Scrum con los que estamos trabajando dedican tiempo al desarrollo de nuevo producto y al mantenimiento del ya existente. Es decir, generan producto nuevo y evolucionan el existente, y además dan soporte a las incidencias y consultas que surjan. Esto hace que su capacidad se tenga que dividir entre desarrollo y mantenimiento.

Así que incorporamos las métricas de incidencias a nuestra gráfica.

Observamos una tendencia a la alza en el número de incidencias que entran en los Equipos Scrum, pero que no explica el descenso en la entrega de producto. Toma forma la explicación más simple: dejan producto pendiente de completar en uno o más sprints, que en un momento determinado se entregan de golpe y se produce un pico.

Existen procesos mensuales que requieren una atención especial por parte de los equipos. Sin embargo, tampoco hay un patrón reconocible en esos periodos. No aumenta de forma sistemática el número de incidencias, no disminuye la entrega de producto.

 

Relacionar Historias, Incidencias y Soporte a Negocio

Consideramos interesante incorporar una métrica más. Dentro del mantenimiento, dan soporte a las áreas de negocio en determinados eventos de la compañía.

ENTENDER A LOS EQUIPOS SCRUM DESDE LAS MÉTRICAS 3

Encontramos que cuando se producen eventos de Negocio, aumenta la necesidad de soporte por parte de los Equipos Scrum. Aún así seguimos sin poder explicar algunos sucesos, ni encontrar un patrón claro.

A partir de este punto, nos reunimos con los Scrum Master para incorporar la información que ellos tienen sobre lo ocurrido dentro y fuera del equipo en cada sprint, y relacionarla con lo que nos están mostrando las métricas. Pusimos foco en aquellos sprints que se salían del patrón habitual.

Este esquema de métricas es el que actualmente utilizan los equipos Scrum para revisar su cadencia de entregas en cada sprint. Al trabajar con datos objetivos, las retrospectivas han dado un salto claro de calidad y de enfoque.

 

Resumen

En la realización de esta comparativa no analizamos los valores de cada métrica de manera aislada, ya que son escalas y dimensiones diferentes, difíciles de relacionar si usamos los valores. Nos interesaba más identificar patrones en cada métrica individual, que fueran explicando lo que ocurría en las demás.

Queremos saber en qué sprints está ocurriendo algo fuera de lo habitual, y así dedicar nuestros esfuerzos a investigar y trabajar con los equipos como afrontar la situación la próxima vez que ocurra.

Por último, relacionar todos los elementos que influyen en la capacidad de entrega de los Equipos Scrum, nos está sirviendo para:

Comprender mejor el impacto que tiene el mantenimiento del software en la construcción o evolución del producto.

  • Conocer si los equipos son conscientes de su capacidad real. Si sistemáticamente son optimistas o conservadores en sus planificaciones.
  • El nivel de saturación de los Equipos Scrum, y su capacidad para atender las necesidades de la compañía.
  • Adaptarnos para atender las necesidades excepcionales del Negocio.

Os animamos a realizar este mismo ejercicio con vuestros equipos y a que nos contéis lo que habéis encontrado y la utilidad que ha tenido para vosotros.

Tabla de contenidos

Comparte:

Más artículos

lean-kanban

Lean Kanban ¿qué es?

El Toyota Production System, data de los años 50 del siglo pasado. Es un complejo conjunto de principios y prácticas que han llevado a Toyota

Devops ¿qué es?

DevOps surge de la necesidad de mejorar el proceso de gestión de las operaciones en los equipos de desarrollo de software. Está basado en un

valor en empresa

Define qué significa VALOR en tu empresa con estas claves

En términos de agilidad, lo primero que se nos viene a la mente es “aporte de valor”. Es una expresión muy manida, con frases como “Con Scrum maximizamos el aporte de valor” o “Primero abordamos los elementos que aporten más valor”.

Suscríbete y mantente al día de las novedades

¿Alguna duda?

¡Reserva 30 minutos con uno de nuestros expertos y soluciónala!