Guía de Scrum | 34. Velocidad en Scrum – Velocidad del Equipo de Desarrollo

La velocidad en Scrum te ayuda a determinar la tasa a la que el Equipo Scrum completa tareas. Podemos definirla como el número promedio de Puntos de Historia completados en un Sprint. La velocidad también puede estimar la duración de un proyecto basado en el progreso del trabajo ya completado. Sin embargo, esto solo tiene sentido para un equipo maduro que trabaja a un ritmo uniforme y constante. ¡Echa un vistazo a qué es la velocidad y cómo hacer que funcione mejor para ti!

La velocidad en Scrum – tabla de contenido:

1. La velocidad en Scrum – Introducción
2. Velocidad actual y planificada
3. Dificultades y riesgos asociados con la velocidad en Scrum
4. Resumen

La velocidad en Scrum – Introducción

La velocidad es un método opcional pero popular para medir el ritmo de un Equipo Scrum. Esto se debe a que una velocidad estimada con precisión permite predecir, en una medida razonable, el tiempo necesario para completar un proyecto. Sin embargo, es una medida que solo se puede aplicar a un Equipo de Desarrollo dado, que realizará tareas que ha “valorado” a sí mismo utilizando una unidad familiar, como Puntos de Historia, por ejemplo.

La velocidad del Equipo de Desarrollo se presenta más a menudo en forma de un Gráfico de Velocidad. En el eje X se marcan los Sprints consecutivos. En el eje Y, por otro lado, encontraremos el número de Puntos de Historia u otras unidades correspondientes que se completaron en un Sprint dado. Con el Gráfico de Velocidad, el Equipo Scrum obtiene una visión clara de los cambios en el ritmo de su trabajo. Si la línea marcada en el gráfico está en ascenso, significa que el Equipo está optimizando su eficiencia o reduciendo el valor de los Puntos de Historia. Por lo tanto, tanto el Scrum Master como el Product Owner deben seguir cuidadosamente la línea que muestra la Velocidad del Equipo.

Velocidad actual y planificada

La Velocidad actual del Equipo de Desarrollo describe el ritmo de trabajo en el Sprint completado y se calcula al final de cada Sprint. Toma el valor de la suma de Puntos de Historia para todas las Historias de Usuario completadas. La Velocidad actual del Equipo de Desarrollo te permite planificar y estimar con cierta probabilidad el ritmo de las tareas futuras.

La Velocidad planificada, por otro lado, se estima en base a un valor promedio de la Velocidad actual. Requiere la suposición de que no hay cambios en el Equipo de Desarrollo. Es una herramienta interna importante para el Equipo de Desarrollo, que, basándose en ella, puede evaluar si la cooperación en el Equipo va bien y si se está manteniendo el ritmo de trabajo.

La Velocidad planificada también permite al Product Owner prever el tiempo de ejecución de Historias de Usuario bien definidas programadas para su ejecución en Sprints posteriores. Esto permite un cuidado más eficiente del Product Backlog, del que escribimos en este artículo. Sin embargo, la práctica de aplicar la Velocidad planificada para estimar las duraciones de los proyectos no es tan simple.

Dificultades y riesgos asociados con la velocidad en Scrum

La velocidad en Scrum a menudo se le da demasiada importancia sin considerar los siguientes factores:

• estimando conjuntos más grandes o el proyecto completo – mientras que el Equipo de Desarrollo puede estimar con precisión el número de Puntos de Historia que se asignarán a una tarea específica, es muy difícil o imposible describir conjuntos más grandes para la implementación futura en estas unidades
• cambios en el proyecto – cualquier cambio en el proyecto significa potencialmente un cambio en el número de Puntos de Historia necesarios para alcanzar el Objetivo del Producto. También puede ser que las tareas ya completadas necesiten ser modificadas o incluso no utilizadas en la versión final del Producto
• eventos imprevistos – predecir el ritmo de proyectos futuros basándose en los ya completados, es decir, traducir la Velocidad actual en Velocidad Planificada, puede resultar en estimaciones precisas. Sin embargo, cada proyecto tiene sus peculiaridades y una predicción precisa basada en la historia suele ser imposible.

Resumen

Usar la Velocidad como una métrica para evaluar la efectividad del Equipo de Desarrollo puede causar que su fiabilidad se degrade. También puede degradar la calidad de las estimaciones, de las que escribimos en más detalle en este artículo. Después de todo, para obtener los mejores resultados posibles en las métricas, el Equipo de Desarrollo puede sobreestimar la intensidad laboral de las tareas para aumentar la Velocidad. Esto es perjudicial ya que el equipo mismo pierde información valiosa para hacer mejoras y planificar sus tareas con mayor precisión.

La Velocidad en Scrum es útil principalmente como una medida interna utilizada por el Equipo de Desarrollo para evaluar el ritmo de su trabajo. Esto se debe a que le permite determinar cuántas tareas es capaz de completar durante un solo Sprint.

La Velocidad en manos del Product Owner se convierte en una herramienta útil para estimar el plazo para tareas más grandes.

Sin embargo, los mayores riesgos están asociados con el uso de la Velocidad como una métrica para evaluar al Equipo de Desarrollo. Esto se debe a que puede llevar a una disminución de su credibilidad e incluso a una sobreestimación deliberada de su valor para mejorar la evaluación externa del trabajo del Equipo Scrum.

Si te gusta nuestro contenido, únete a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.