1. La velocidad en Agile: concepto

La velocidad o velocity es un número que indica la capacidad del Equipo para completar trabajo en un determinado Sprint. Representa la cantidad de trabajo terminado (de acuerdo con la Definición de Hecho) durante un Sprint, como sumatorio de las estimaciones asociadas a cada elemento del Product Backlog seleccionado para el Sprint. Por tanto, dado que estas estimaciones son realizadas por los Desarrolladores, es un numero que “pertenece” a estos.

Es una medida de la eficiencia del Equipo, esto es, indica cuánto trabajo por unidad de tiempo puede completar un Equipo, donde los Sprints son la unidad de tiempo.

La velocidad variará de Sprint a Sprint, por diversas circunstancias: cambios en la composición del Equipo, problemas con un proveedor externo, incidentes, vacaciones, faltas por enfermedad de miembros del Equipo, etc.

2. Lo que la velocidad no es

La velocidad estimada no es un compromiso. En Scrum, el compromiso es para con el Sprint Goal, no con la proyección que los Desarrolladores hagan para el Sprint. No nos confundamos.

Por otra parte, por tentador que resulte a muchos “jefes” acostumbrados a métodos más tradicionales, la velocidad tampoco nos sirve para comparar el rendimiento de un Equipo con otro. Es una medida de eficiencia interna al Equipo, y que solo es útil en su contexto concreto.

Hay que decir también que, en Scrum, la velocidad se entiende como una práctica complementaria. Su medición puede ser útil para el Equipo, pero no es obligatoria dentro del framework.

3. Para qué sirve la velocidad

La velocidad nos sirve para hacer proyecciones (con todas las cábalas que implica el hacerlas, recordemos aquí el cono de la incertidumbre).

Si disponemos de datos históricos, esto es, del dato de la velocidad en Sprint pasados, podemos utilizar la media, o la moda, para proyectar nuestra capacidad futura. O puede que utilicemos la velocidad del Sprint anterior, como quien utiliza el tiempo de ayer para predecir el tiempo de hoy.

El dato de velocidad histórica nos ayudará a determinar:

• Si solo podemos financiar X Sprints adicionales, cuánto seremos capaces de entregar en estos.
• Si tenemos un Product Backlog estimado, cuántos Sprints necesitaríamos para completarlo. Lo conveniente será utilizar un intervalo de confianza, más que dar una fecha concreta de entrega.

4. Cómo mejorar la velocidad

En realidad, cuando “un jefe” quiere aumentar la velocidad, lo que quiere decir es «¿cómo podemos entregar más valor, más frecuentemente?»

Mejorar la velocidad no significa entregar más rápido, encontrando “atajos” que vayan en detrimento de la calidad y que nos lleven, inexorablemente, a acumular deuda técnica. Significa eliminar impedimentos y despilfarro, o mejorar la capacitación del Equipo o su dimensión. Por ejemplo:

• Aumentar el tamaño del Equipo (aunque, seguramente, al principio habrá una caída de la productividad).
• Anadir otro Equipo que trabaje sobre el mismo producto.
• Formar a miembros del Equipo para que desarrollen nuevas habilidades (fomentando quizás la multifuncionalidad y las “habilidades en forma de T”).
• Contar con un sistema de deployment continuo, al entorno de prueba y a producción.
• Automatizar tests de regresión.
• Mejorar los ways of working para hacer un mejor refinamiento de producto.
• Cambiar al proveedor de pagos por otro con mejor soporte y menos incidencias.
• En general, la supresión de estos obstáculos liberará al Equipo, que podrá dedicar más tiempo a la creación de valor.

5. Pongamos el foco en el valor y no en la velocidad

En todo caso, más que centrarnos en la velocidad, en cuánto entregamos, conviene centrarnos en medir si lo que entregamos sirve para algo. Debemos poner el foco en el valor de los Incrementos de producto. Para ello, usaremos las llamadas métricas de valor: ingresos por usuario, recurrencia de uso, satisfacción del cliente, reducción de costes, etc.

Imagen por OpenClipart-Vectors, Pixabay