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.

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.

Métricas Producto

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:

Métricas Producto

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.

Métricas Producto

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.

Métricas Equipos Scrum

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.

También te puede interesar.

Monta equipos Scrum de éxito

Cómo montar equipos Scrum de éxitoYa sabes lo que es un equipo Scrum. Es hora de dar un paso adelante y entender cómo montar un equipo Scrum de éxito. ¿Qué tipo de perfiles incorporas? ¿Cómo se balancean? ¿Cuándo les incorporas? Son preguntas que probablemente te...

¿Tiene mi equipo Scrum los conocimientos necesarios para construir mi Producto?

Scrum propone que nuestros equipos tengan todos los conocimientos para generar productos que cubran nuestras necesidades. Te traigo hoy una herramienta sencilla para averiguar si tus equipos Scrum son realmente multidisciplinares.

En que punto del proceso consideramos el Producto como Entregable

Escoger dentro de nuestro proceso de generación de producto entregable el punto adecuado, puede ser muy complejo cuando dependemos de terceros.

La historia de scrum, su primera implementación

Actualmente Scrum es el marco de trabajo más utilizado para implementar modelos Agile. Hoy os contamos como era su primera versión.

¿Quién debe priorizar el Product Backlog en Scrum?

Agile y Scrum nacen principalmente del mundo del Software, aunque en los últimos años se han llevado a otros ámbitos de las empresas. Scrum plantea al Product Owner como una única persona. La realidad de la empresa nos empuja a implementar algún tipo de escalado de Scrum, en el que aparecen, de una forma y otra, Product Owners de Product Owners. ¿Significa esto que se está haciendo una mala implementación de Scrum? ¿O nos estamos adaptando a las necesidades tal y como indica Agile? ¿Tiene que de verdad ser una única persona? ¿O hay otras posibilidades manteniendo la cultura Agile?

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

Plan para formar a Scrum Master propios de la empresa

En todo acompañamiento en la transformación a la agilidad con Scrum, llega un momento en que los Agile Coach y Scrum Master externos a la empresa deben dejar al Cliente que siga su camino. Y con garantías de que no se va a perder lo conseguido y se va a seguir fomentando la mejora continua y el customer centric.

Lo que te estás perdiendo por hacer «tu» Scrum

¿Qué ocurre si decides utilizar sólo parte de Scrum? Dejar de usar roles, eventos o artefactos tiene sus riesgos.

Beneficios de la automatización en los equipo Scrum

La automatización, cada vez más, forma parte del desarrollo del software. ¿Qué beneficios tiene para los equipos Scrum?

0 comentarios

Enviar un comentario

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

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies