¿Qué es la velocidad en Scrum?

La velocidad es una forma muy sencilla pero poderosa de medir con precisión la rapidez con la que un equipo de desarrollo Scrum entrega valor empresarial con el tiempo. Proporciona una indicación de la cantidad promedio deBacklog del producto transformado en un incremento del producto durante cadaSprint por unequipo Scrum, con el equipo de desarrollo utilizando seguimiento. Por lo tanto, para calcular laÁgilvelocidad del equipo, simplemente sume las estimaciones de características, historias de usuarios, requisitos o elementos del backlog entregados con éxito durante una iteración. El equipo debería:

• Predecir el alcance que se puede entregar en una fecha específica.
• Predecir la fecha en la que se entregarán un número fijo de alcances.
• Entender nuestras limitaciones al definir cuánto alcance nos comprometemos a entregar en un Sprint.

Ejemplo de velocidad en Scrum

Antes de completar algunas iteraciones, hay algunas pautas sencillas para estimar la velocidad inicial de un equipo Scrum, pero después de eso, tu equipo puede usar métodos validados de estimación de velocidad histórica paraPlanificación del Sprint. Basado en una serie de Sprints anteriores, las estimaciones de velocidad suelen estabilizarse y proporcionan una base más confiable para mejorar la precisión de la planificación a corto y largo plazo para proyectos Scrum.

La velocidad mide la cantidad de trabajo que un equipo puede completar en un único Sprint y es una métrica clave en Scrum. Se calcula sumando los puntos de todas las historias de usuarios completamente completadas al final de un Sprint. Los puntos de historias parcialmente completadas o incompletas no deben incluirse en el cálculo.

Paso 1 – Calcular la velocidad de la primera iteración (Sprint)

Al final de cada iteración, el equipo suma las estimaciones de esfuerzo asociadas con las historias de usuarios completadas durante esa iteración. Este total se llama velocidad.

Un equipo Ágil ha comenzado una iteración, planeando completar la Historia A y la Historia B, estimadas en 2 puntos, y la Historia C, estimada en 3 puntos. Al final de la iteración, la Historia A y la Historia B están al 100% completas, pero la Historia C solo está al 80% completa. Los equipos Ágiles generalmente reconocen solo dos niveles de completitud: 0% o 100%. Por lo tanto, la Historia C no cuenta para la velocidad, y la velocidad para esta iteración es de 4 puntos.

Paso 2 – Usar la velocidad para estimar el número de iteraciones necesarias

Después de entender la velocidad del Paso 1, el equipo puede calcular (o revisar) la estimación de cuánto tiempo llevará completar el proyecto basándose en las estimaciones de las historias de usuarios restantes, asumiendo que la velocidad en las iteraciones futuras permanecerá aproximadamente igual. Esta es generalmente una predicción precisa, aunque rara vez sea exacta.

Suponga que las historias de usuarios restantes representan un total de 40 puntos; la predicción del equipo para el trabajo restante es de 10 iteraciones.

Relación entre velocidad y puntos de historia en Scrum

Puntos de historiase utilizan para medir el tamaño y la complejidad, esencialmente, cuánto tiempo llevará completar una tarea. Los puntos de historia son una medida relativa del tiempo necesario para completar una historia de usuario. Este concepto se ha tomado de XP. Se utilizan para evaluar la dificultad de una historia, no para comprometerse con cuánto tiempo llevará. Esto permite usar puntos de historia independientemente del tamaño del equipo o del tipo de tarea.

¿Cómo vincular la velocidad con los puntos de historia?

1. Los equipos a menudo utilizan la “velocidad” como métrica de productividad para informar a los externos exactamente qué tan rápido es un equipo Scrum.
2. Si las estimaciones de puntos de historia permanecen consistentes durante todo el proyecto, tiene sentido utilizar los puntos de historia para representar la “velocidad”.
3. Si se mantiene la consistencia no solo dentro de un equipo, sino también entre equipos e incluso en toda la empresa, permite medir la productividad y comparar el desempeño del equipo.
4. Si los valores de puntos de historia permanecen estables, pueden usarse como referencia para la planificación de lanzamientos. Puedes evaluar posibles cronogramas más adelante.

¿Cómo asignar puntos de historia a una historia de usuario?

Un punto de historia es una unidad de medida relativa. El primer paso que debe dar su equipo es definir una historia como referencia para que puedan estimar otras historias en relación con esta referencia. Según la literatura, el equipo debería identificar la historia más sencilla del backlog y asignarle 1 punto de historia, luego usar esa historia como referencia para estimar otras historias.

Existen dos tipos de escalas utilizadas para crear estimaciones de puntos de historia:

• Escala lineal (1, 2, 3, 4, 5, 6, 7, …)
• Secuencia de Fibonacci (0.5, 1, 2, 3, 5, 8, 13, …)

Es una buena idea estimar su primera historia de usuario con la que el equipo está familiarizado y sabe cuánto tiempo tarda en completarse. Luego estime su siguiente historia de usuario. Si el equipo cree que tarda menos tiempo que la historia de referencia, colóquela a la izquierda de la referencia. Luego estime otra historia de usuario. Si el equipo decide que tarda menos tiempo que la historia de referencia pero más que la segunda historia, colóquela entre la referencia y la segunda historia. En este ejemplo, usamos la secuencia de Fibonacci para la estimación de historias:

Historia de usuario Puntos de historia

¿Cómo estimar la velocidad con mayor precisión?

En Scrum, la velocidad te ayuda a entender cuánto tiempo tarda un equipo en completar el backlog del producto. Sin embargo, normalmente se necesitan unos cuantos Sprints antes de que el equipo encuentre una velocidad más estable. Para estimar la velocidad del equipo con mayor precisión, podemos recurrir a los registros pasados de seguimiento del equipo. Esto predecirá con mayor precisión cuántas historias puede completar el equipo en un Sprint. Para fines de pronóstico, se debe usar el promedio de las últimas tres o cuatro velocidades de Sprint.

Supongamos que un nuevo equipo Scrum planea completar 41 puntos de historia en su primer Sprint. Al final, completan solo 38 puntos de historia y trasladan 6 puntos de historia al siguiente Sprint. Por lo tanto, su velocidad es 38, como se muestra a continuación:

Velocidad Scrum

Velocidad promedio basada en el seguimiento de Sprints anteriores

Como se mencionó anteriormente, los equipos no deben incluir trabajos parcialmente completos en la velocidad. Solo cuentan las historias de usuario marcadas como “Hecho”, incluso si solo queda una pequeña parte de la tarea.

La velocidad basada en un solo Sprint no es una métrica muy confiable para pronósticos. (Pero sí ayuda al equipo a entender cuánto trabajo puede comprometerse en un solo Sprint.) Sigamos rastreando su progreso en Sprints posteriores.

Ahora, el nuevo equipo continúa desarrollándose desde el Sprint 1 hasta el Sprint 4. Los puntos de historia completados en cada Sprint son: 38, 29, 38 y 39. La velocidad promedio después de cuatro Sprints es 36, como se muestra a continuación:

Velocidad Scrum a lo largo de los Sprints

Este promedio, basado en cuatro Sprints, es mucho más útil que una instantánea después de solo un Sprint. Es fácil imaginar que si el backlog ya tiene historias de usuario estimadas, podemos usar esta velocidad para pronósticos. Podemos predecir con qué rapidez el equipo completará todo el trabajo. Podemos hacer conjeturas informadas sobre qué características podemos entregar en el próximo lanzamiento.

Gráfico de velocidad

Si un equipo Scrum ha completado múltiples Sprints, el equipo puede usar el informe de velocidad para pronosticar fechas de lanzamiento y finalización del producto, y planificar mejor proyectos futuros. Basado en la velocidad de Sprints anteriores mostrada en el informe, puedes lograr lo siguiente:

• Rastrea la cantidad de trabajo completado por tu equipo en cada Sprint.
• Si la composición del equipo y la duración del Sprint permanecen sin cambios, estima cuánto trabajo del backlog puede manejar tu equipo en Sprints futuros.

Basado en el ejemplo anterior, el gráfico de velocidad muestra la cantidad de trabajo completado en cada uno de los 4 Sprints por el equipo Scrum:

Gráfico de velocidad Scrum