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

Velocity in Scrum lo ayuda a determinar la velocidad a la que el Equipo Scrum completa las tareas. Podemos definirlo como el promedio de Story Points completados en un Sprint. Velocity también puede estimar la duración de un proyecto en función del progreso del trabajo ya completado. Sin embargo, esto solo tiene sentido para un equipo maduro que trabaja a un ritmo uniforme y constante. ¡Eche un vistazo a qué es Velocity y cómo hacer que funcione mejor para usted!

Velocidad en Scrum – índice:

1. Velocidad en Scrum – Introducción
2. Velocidad real y planificada
3. Dificultades y riesgos asociados con Velocity en Scrum
4. Resumen

Velocidad en Scrum – Introducción

Velocity 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 determinado, que realizará tareas que él mismo ha “valorado” utilizando una unidad familiar, como Story Points, por ejemplo.

La velocidad del equipo de desarrollo se presenta con mayor frecuencia en forma de gráfico de velocidad. En el eje X están marcados Sprints consecutivos. En el eje Y, por otro lado, encontraremos la cantidad de Puntos de Historia u otras unidades correspondientes que se completaron en un Sprint determinado. 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 sube, significa que el Equipo está optimizando su eficiencia o reduciendo el valor de los Story Points. Por lo tanto, tanto el Scrum Master como el Product Owner deben seguir cuidadosamente la línea que muestra la velocidad del equipo.

Velocidad real y planificada

La Velocidad real 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 Story Points para todas las User Stories completadas. La Velocidad real del Equipo de Desarrollo le 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 real. Requiere la suposición de ningún cambio en el Equipo de Desarrollo. Es una herramienta interna importante para el Equipo de Desarrollo que, a partir de ella, puede evaluar si la cooperación en el Equipo va bien y si se mantiene el ritmo de trabajo.

Planned Velocity también permite que el propietario del producto pronostique el tiempo de ejecución de historias de usuario bien definidas programadas para su ejecución en Sprints posteriores. Esto permite una crianza más eficiente del Product Backlog, sobre el cual escribimos en este artículo. Sin embargo, la práctica de aplicar la velocidad planificada para estimar la duración de los proyectos no es tan simple.

Dificultades y riesgos asociados con Velocity en Scrum

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

• estimar totalidades más grandes o todo el proyecto : si bien el equipo de desarrollo puede estimar con precisión la cantidad de puntos de historia que se asignarán a una tarea específica, es muy difícil o imposible describir totalidades 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 la cantidad de Story Points necesarios para lograr el objetivo del producto. También puede ser que las tareas ya completadas deban modificarse o incluso no usarse en la versión final del Producto
• eventos imprevistos : predecir el ritmo de proyectos futuros en función de los que ya se han completado, es decir, traducir la velocidad real en velocidad planificada, puede generar estimaciones precisas. Sin embargo, cada proyecto tiene sus peculiaridades y una predicción precisa basada en la historia suele ser imposible.

Resumen

El uso de Velocity como una métrica para evaluar la eficacia del equipo de desarrollo puede hacer que su confiabilidad se degrade. También puede degradar la calidad de las estimaciones, sobre lo que escribimos con 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 sobrestimar la intensidad de trabajo de las tareas para aumentar la velocidad. Esto es perjudicial ya que el propio equipo pierde información valiosa para realizar mejoras y planificar sus tareas con mayor precisión.

La velocidad en Scrum resulta útil principalmente como 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.

Velocity en manos del Product Owner se convierte en una herramienta útil para estimar la fecha límite para tareas más grandes.

Sin embargo, los mayores riesgos están asociados con el uso de Velocity como métrica para evaluar al Equipo de Desarrollo. Esto se debe a que puede conducir 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 le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autora: Carolina Becker

Como Project Manager, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo la presión del tiempo la convierten en la mejor persona para convertir proyectos complicados en realidad.

Ver todas las publicaciones

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos