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.

En los Equipos Scrum noveles, en más de una ocasión tienen dificultades para aplicar la regla “deja de empezar, y empieza a terminar”, para poner foco en la entrega de lo más importante del Sprint Backlog. Suele ocurrir además, debido a la inexperiencia del Product Owner y del equipo en general, que tendrán PBIs de usuario de un amplio espectro de tamaños. Ambas cosas unidas les llevarán a que la entrega de producto se realice en los últimos días del Sprint, generando un Burn Down tipo acantilado:

BURNDOWN2

Para ayudarles, hemos utilizado el Lead Time, una métrica de Kanban, aplicándola sobre los PBIs que forman parte del Sprint Backlog y el Sprint. 

¿Qué es el Lead Time?

Kanban lo define como el tiempo que un elemento está en proceso. Esto es, entre los puntos de compromiso y de entrega. Se conoce como “Tiempo de entrega del elemento” (o “Tiempo de ejecución del sistema”, System Lead Time).

En nuestro caso, los elementos son los PBI. Y los puntos de compromiso y entrega, en un tablero Scrum típico, es únicamente el estado “Doing”. El Equipo Scrum está adquiriendo un compromiso para construir el PBI cuando la primera tarea pasa a Doing, y completa la entrega cuando la última tarea pasa a Done. Por lo tanto, el System Lead Time es el tiempo que pasa en “Doing” un PBI, o más concretamente empieza a contar con la primera tarea que pase a “Doing” y finaliza cuando la última pasa a “Done”.

Evidentemente el Equipo Scrum ya ha adquirido un primer compromiso al aceptar que el PBI entre en el Sprint Backlog. Pero aquí nos estamos centrando en ayudarles a adaptar su forma de organizarse para entregarlas; de ahí que hablemos de un segundo punto de compromiso.

Ta

Ponerlo en marcha

Una vez aclaramos con los Equipo Scrum en qué consistía el System Lead Time, y acordamos utilizarlo, definimos con ellos y los responsables el valor objetivo: definimos el KPI. 

Sin un KPI claro, estamos midiendo y visualizando lo que ocurre, sin más. En el momento en que marcamos un objetivo, el Equipo Scrum puede empezar a plantear acciones de mejora que le lleven a lograrlo.

En este caso el Equipo Scrum del que te hablo tomó como objetivo un System Lead Time de 3 días hábiles. Consideraron que sus PBIs debían tardar en construirse entre 1 y 5 días, independientemente de su valor en puntos de historia, teniendo en cuenta que hacen Sprints de 2 semanas.

Ventajas

Algunas de las ventajas que encontrarás al aplicar el Lead Time a tu Equipo Scrum, son:

\

Acelerar la entrega. Fomentamos la entrega temprana frente a tener muchos PBIs abiertos sin finalizar.

Pretendemos cambiar el modo en que el Equipo Scrum completa los PBIs, de forma que inicie la primera y la finalice, y sólo entonces inicie la segunda y la finalice, y así sucesivamente hasta completar todas las que se hayan comprometido a entregar en el Sprint. De esta manera, si ocurre algo durante el Sprint que les impida completar todas los PBIs, habrán entregado las más importantes.

A parte de que abriendo todas al inicio del Sprint, van a tener muy complicado cumplir con el System Lead Time objetivo.

\

Dividir el Product Backlog en PBIs con una complejidad más homogénea.

Para ayudar en el objetivo de poner foco en la entrega, es muy recomendable que los PBIs en que está dividido el Product Backlog sean de una complejidad similar. De esta manera, será más probable que se cumpla el System Lead Time objetivo.

\

Ayuda a entender cuánto tardamos en aportar valor.

El System Lead Time que vayamos obteniendo nos está diciendo: el Equipo Scrum tarda x tiempo en construir una historia, es decir, tarda x tiempo en entregar algo de valor para el cliente.

Ten en cuenta que el System Lead Time no sustituye a tu sistema de estimación habitual. Lo que aquí te propongo es que lo utilices como palanca para acelerar vuestras entregas. ¿Tienes un Lead Time alto? Probablemente sea porque tienes PBIs demasiado grandes o porque abrís muchos PBIs al mismo tiempo (trabajo en paralelo).

¿Qué ha ocurrido hasta ahora?

Recuerdo perfectamente el primer Equipo Scrum en el que utilizamos el Lead Time como palanca de cambio. Ese equipo tenía un Lead Time de 12 días. Con un par de cambios que se propusieron en su retrospectiva consiguieron reducirlo a 7 días. Casi un 50% menos en sólo 1 Sprint. Y su Burn Down ha pasado de un acantilado a 3 saltos con cuidado.

Elegir una buena métrica os hará mucho más fácil orientar vuestras acciones de mejora continua al éxito. Para empezar, ¡prueba con el Lead Time!

También te puede interesar.

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.

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

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

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

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.

El Product Owner: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

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.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

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

ACEPTAR
Aviso de cookies