El objetivo del cálculo de la velocidad es determinar la capacidad de trabajo del equipo para un Sprint y, para este fin, se basa en la información recopilada de los Sprint anteriores.
La velocidad está relacionada con el método de estimación del tamaño de las historias. En el post anterior hablamos sobre cómo estimar el tamaño de las historias con "Puntos" y en este post seguiremos en esta misma línea.
Vamos a tratar los siguientes aspectos:
- Calcular la velocidad real resultante del trabajo realizado por el equipo en el primer Sprint.
- Interpretar correctamente el significado del valor obtenido.
- Utilizar este cálculo de velocidad durante el Planning del segundo Sprint.
- Conseguir el compromiso del equipo con el trabajo planificado para el segundo Sprint.
Y para ilustrar el cálculo y uso de la velocidad vamos a utilizar el siguiente ejemplo:
- Tenemos un equipo de desarrollo compuesto por 4 miembros.
- La duración de los Sprints será de 15 jornadas de trabajo efectivo por Sprint.
- Las historias del Product Backlog están estimadas de la siguiente forma:
- Durante el primer Sprint, al no disponer de información de la capacidad de trabajo del equipo, se decidió intentar abordar las 5 primeras historias. Sin embargo, solo se han podido completar las 4 primeras. Además, durante el Sprint surgieron algunas incidencias que afectaron al equipo y que no estaban previstas: uno de los miembros del equipo estuvo un día de baja y todos los miembros del equipo tuvieron que asistir a un curso de un día de duración que no estaba programado al inicio del Sprint.
| Historia | Tamaño | Historia | Tamaño |
|---|---|---|---|
| H1 | 8 | H7 | 2 |
| H2 | 13 | H8 | 2 |
| H3 | 20 | H9 | 13 |
| H4 | 3 | H10 | 5 |
| H5 | 5 (*) | H11 | 20 |
| H6 | 8 | H12 | 5 |
Calcular la velocidad real en un Sprint
Al final de un Sprint, la velocidad se calcula de la siguiente forma:
- Total de puntos completados: se suman los puntos de historia correspondientes a las historias terminadas, es decir, de las 4 primeras (aunque el compromiso inicial fue de 5 historias, en realidad se completaron 4 y para el cálculo de velocidad solo se tiene en cuenta el trabajo finalizado).
- Total de jornadas reales: se suman las jornadas reales que cada miembro del equipo ha realizado en el Sprint, descontando las ausencias o circunstancias especiales que han surgido.
- Cálculo de Velocidad: la velocidad es la división de los puntos completados y de las jornadas reales.
Puntos completados = 8 (H1) + 13 (H2) + 20 (H3) + 3 (H4) = 44
Jornadas ideales = 15 + 15 + 15 + 15 = 60
Jornadas reales (descontando ausencias) = 13 + 14 + 14 + 14 = 55
Velocidad = 44 / 55 = 0,8
El equipo ha trabajado en el primer Sprint con una velocidad del 80%.
Interpretar el valor de la velocidad
Este es probablemente el aspecto más delicado del proceso. En las metodologías tradicionales estamos acostumbrados a que una jornada de trabajo equivale a 8 horas y a que los desarrolladores dedican todo ese tiempo a tareas de desarrollo. La experiencia suele demostrar que esta aproximación no es realista, todo el mundo tiene que atender eventos no planificados durante su jornada laboral. Algunos de estos eventos son: llamadas telefónicas o correos electrónicos, reuniones de seguimiento (en Scrum, la reunión diaria), ir al baño, corregir un bug grave que se ha descubierto...
Una velocidad del 80% significa que el equipo ha podido dedicar el 80% de su jornada laboral a acciones concretas de desarrollo que se habían programado para el Sprint y que un 20% ha sido invertido en otras acciones como las ya descritas. Al planificar los sucesivos Sprint con este "colchón" del 20%, estamos aportando al equipo una herramienta que le permite asumir trabajo no previsto sin que esto tenga impacto en el trabajo comprometido lo cual favorece el clima de trabajo y la imagen hacia el cliente.
Traducción de la velocidad horas de trabajo por día
Existe una tendencia en la que se mide la capacidad de trabajo de los equipos como el número de horas efectivas de trabajo por jornada, algo así como si mi jornada de trabajo es de "X" horas, se que tengo "Y" horas de trabajo efectivo y el resto es para tareas no controladas. A fin de cuentas, este cálculo es una particularización del cálculo de velocidad anterior: si un equipo tiene una velocidad del 75% y la jornada de trabajo es de 8 horas podemos decir que los miembros del equipo dedicas 6 horas al día a trabajo efectivo (75%) y 2 horas a tareas no programadas (25%).
¿Cuál es la medida de velocidad adecuada? Pues depende del equipo, del proyecto, de la empresa, etc. Generalizando mucho, un valor de velocidad del 80% es un dato muy bueno.
Utilizar la velocidad en el próximo Sprint
Ahora ya disponemos de un cálculo orientativo de la capacidad de trabajo del equipo y vamos a utilizarlo, siguiendo el ejemplo anterior, para determinar la cantidad de trabajo que el equipo podría asumir en el siguiente Sprint. Antes de planificar el Sprint debemos de tener en cuenta lo siguiente:
- Durante el próximo Sprint 2 miembros del equipo estarán de vacaciones durante una semana cada uno (5 días).
- La historia 5 estaba estimada en 5 puntos, pero como parte de esta historia fue abordada durante el primer Sprint (aunque no se completó), se realiza una re-estimación y se determina que su nuevo tamaño es de 2 puntos.
En el escenario descrito para el Sprint 2, vamos a proceder a determinar la capacidad de trabajo del equipo y a extrapolar este valor a las historias que podrán ser abordadas:
- Jornadas de trabajo disponibles: determinamos las jornadas de trabajo para el nuevo Sprint como las suma de las jornadas que cada miembro del equipo podrá dedicar con la información de la que disponemos en este momento.
- Aplicar la velocidad: ajuste de las jornadas disponibles.
- Selección de historias potencialmente abordables: determinamos cuales de las historias podrán ser abordadas durante el Sprint en base a su prioridad, estimación y jornadas efectivas calculadas.
- No respectar la prioridad, saltarse la historia H11 (20 puntos) y abordar en este Sprint la historia H12 (5 puntos), lo que suponen 37 puntos y es un valor razonablemente cercano a los 40 efectivos calculados.
- Dividir la historia H11 en varias historias más pequeñas, de forma que algunas de estas pueda ser abordada en el Sprint.
- Sustituir la historia H9 (13 puntos) por la H11 (20 puntos), lo que deja el total de puntos planificados en 39.
- Etc.
Jornadas previstas = 10 + 10 + 15 + 15 = 50 (descontando ausencias programadas)
Puntos abordables = 80% de 50 = 40
Suma de puntos de las historias H5 a H10 = 2 (*) + 8 + 2 + 2 + 13 + 5 = 32
(*) H5 re-estimada
Llegados a este punto tenemos un "problema" que solventar. Por una parte, si abordamos solo las historias de la H5 a la H10, al equipo le sobrarán 8 jornadas de trabajo real, lo cual es excesivo (semana y media de trabajo de un miembro del equipo o dos días no planificados para todo el equipo). Sin embargo, sin añadimos la siguiente historia en prioridad, la H11, la suma llega a 52, lo cual son 12 puntos por encima de las jornadas efectivas calculadas.
La solución depende del Product Owner, pero es el Scrum Master y el equipo quienes tienen que ayudarle a identificar las soluciones disponibles y a escoger la más razonable. Estas son algunas opciones:
Conseguir el compromiso del equipo con el trabajo planificado para el segundo Sprint
Muy Importante: la velocidad y el trabajo propuesto a partir de este valor deben considerarse una referencia y solo tendrán validez si el equipo declara su compromiso para la realización del trabajo previsto. Es decir, según las circunstancias, para un Sprint la velocidad nos puede decir que tenemos capacidad para X jornadas, pero el trabajo final comprometido debe ser aquel con el que el equipo se sienta a gusto y con garantías de poder completarlo.
Esto supone que el equipo tendrá la libertad para reducir o aumentar la capacidad teórica de trabajo de un Sprint de forma justificada y dentro de unos límites razonables, con el fin de garantizar su compromiso con el trabajo programado.
Si este aspecto no se respeta, el equipo perderá confianza y buscará argucias para autoprotegerse de la imposición de trabajo excesivo... y la más sencilla la podéis ver en la siguiente tira:
7 comentarios:
Hola Diego, Gracias por el aporte pero tengo una observación. Cuando se va a calcular la velocidad supongamos que se trabaje con las jornada ideal, entonces 44/60 = 0.73 se interpretaría que la velocidad del equipo es 73% en acciones concretas y 27% en otras acciones. ¿No debería ser mayor el porcentaje de acciones concretas? ¿La formula esta mal? o ¿como se trabajaría la jornada ideal y su interpretación?
Gracias
Antes de nada, ten en cuenta que el dato de la velocidad es en realidad una referencia que tiene como objetivo medir la capacidad de trabajo y medir tambien como evoluciona dicha capacidad.
Por lo tanto, no es tan importante la fórmula que utilices, como el hecho de que la mantengas constante a lo largo del tiempo para que las mediciones sean comparables.
Con respecto al ejemplo, creo que estás haciendo el cálculo sobre 60 jornadas de trabajo (4 desarrolladores y 15 días de desarrollo), sin embargo, durante dicho periodo hubo 5 ausencias, por lo que el número real de jornadas es de 55 y haciendo 44/55 ya te sale el 80%.
Espero haber aclarado tu duda.
Un saludo.
Como se calculan las jornadas?
y me ayudan con este ejemplo:
el equipo completo 7 hu, que suman 88 puntos, cual es la velocidad del equipo?
Muchas gracias
Hola Gloria,
El cálculo de las jornadas es la suma de los días en los que está cada desarrollador disponible para trabajar en el sprint.
Por ejemplo, si el sprint tiene 15 días de trabajo efectivo y tienes 2 desarrolladores, el total de jornadas será 30 (15 + 15).
Si en el caso anterior, uno de los desarrolladores se ha pedido 5 días libres, el total de jornadas de trabajo serán 25 (15 + 10).
Para hacer el cálculo de la velocidad en el escenario que comentas nos faltan al menos dos datos: la duración del sprint y el número de desarrolladores. Afinando más, también necesitaríamos saber si los desarrolladores estarán disponibles todos los días o no.
Vamos a suponer que el sprint tiene 15 días de trabajo efectivo y que tienes un equipo de 10 desarrolladores con dedicación completa y sin previsión de ausencias.
Siendo así, el número de jornadas de trabajo serán 15 * 10 = 150 jornadas.
Suponiendo que se han completado las 7 historias, que suman 88 puntos, la velocidad será 88(puntos) / 150(jornadas) = 0,59, es decir, un 59% de velocidad.
Si en vez de 10 desarrolladores, el equipo fuese de 7 desarrolladores, el total de jornadas serían 105 (15 * 7) y la velocidad sería 88(puntos) / 105(jornadas) = 0.84, es decir, un 84% de velocidad.
Espero haber aclarado tu duda,
Un saludo.
Claro que si muchas gracias Diego.
para el ejemplo solo estan las 7 Hu, que suman 88 puntos. las cuales se hicieron en dos iteraciones.
hola muy bueno tu publicación, pero te consulto como seria si las HU(por ejemplo divido en tareas las H1 y H2) como seria la estimación de las horas dedicadas a resolver las tareas de estas HU
Muchas gracias. Saludos
Diego, una duda, quisiera hacer ese cálculo por desarrollador, para colocarles una meta de productividad mayor o igual al 80% y con eso medirlos, pero con esa formula veo que no se podrá, por ejemplo si en un sprint de 2 semanas (10 días hábiles), suponiendo que falta 1 día (9 días trabajados) y un total de historias de 50 y que el developer completa todo lo que el podía hacer en el sprint es decir las 50, la fórmula me daría lo siguiente 50/9 = 5.55 , este valor no es muy lógico , que recomendas hacer para llegar a mi objetivo ?
Publicar un comentario