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.

Por dónde empezar como Product Owner que viene de Tecnología

Estás dando tus primeros pasos como Product Owner, tras haber pasado años diseñando y desarrollando software. Te enfrentas a varios dilemas.

Multiplica los resultados de tu Sprint Planning

Hoy es día de Sprint Planning. Miras hacia tu equipo y… sólo ves pacas de paja rodar de un lado a otro. ¿Qué ha pasado con tus compañeros? ¿Dónde se esconderán? ¡Te han dejado solo! Te traigo 5 consejos para multiplicar los resultados de tu Sprint Planning.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

¿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.

Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. Una buena review te ayudará en la estrategia de producto.

Mi estrategia de Onboarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo??

Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

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.

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.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

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