Interpretando la velocidad: Recomendaciones y restricciones

La velocidad se define como "La medida de cuántos puntos completa el equipo en promedio en un Sprint determinado". La velocidad mide la cantidad de trabajo que se espera que complete un solo equipo durante una iteración. Cuando nos referimos a los puntos de historia, nos referimos a una unidad de medida que expresa el esfuerzo estimado requerido para implementar ese elemento de la lista de producto. Estos puntos de la historia son calibrados y decididos por el equipo.

Cálculo de la velocidad.

La estimación del esfuerzo se puede hacer en una variedad de unidades. La mayoría de las veces, en los equipos de Agile, se utilizan puntos de historia o tallas de camisetas para estimar el esfuerzo. Si usas tallas de camiseta, tu equipo asignará esas tallas a un valor numérico con el fin de calcular la velocidad del equipo.

Cuando tu equipo comience a ejecutar Sprints o iteraciones, no podrán determinar con precisión la velocidad porque no tendrán una base histórica sobre la cual calcular una cantidad promedio de puntos completados en un Sprint. En su primer Sprint, tu equipo hará una estimación aproximada de cuántos elementos pueden completar solo para comenzar. Una vez que se hayan completado algunos Sprints, tu equipo tendrá una buena medida de su velocidad y usarán ese número para determinar qué elementos incluir en la lista del Sprint. Esto debería ser fácil de hacer si tu equipo tiene una lista correctamente priorizada y estimada sobre la cual trabajar, este proceso se denomina refinamiento de la lista.

Buen uso de la velocidad.

Al interpretar la velocidad, es importante tener en cuenta algunas cosas. Puedes sentirte inclinado a compartir la velocidad con miembros fuera de tu equipo o usar la velocidad como una métrica de rendimiento o comparación. También puedes sentirte inclinado a usarla para determinar una fecha de entrega proyectada. Sin embargo, algunos expertos de Agile advierten sobre estas prácticas. Veamos por qué.

Recomendación: Ten cuidado al compartir la velocidad con interesados externos.

La velocidad puede ser útil para personas ajenas al equipo de Scrum, pero ten mucho cuidado al compartirla con personas que no sean miembros del equipo. Dado que la velocidad es diferente para cada equipo, es posible que un interesado no tenga suficiente contexto para interpretarla. Asegúrate de compartir los materiales de apoyo relevantes para agregar contexto. Un buen ejemplo de esto es compartir la velocidad con un intervalo de fechas correspondiente y una visualización que indique las tendencias en el tiempo. Puede haber caídas y picos en la velocidad que aporten información y fomenten las mejoras en proyectos futuros.

Restricción: No uses la velocidad como una métrica de rendimiento.

Es lógico que las personas quieran cuantificar el rendimiento a través de los datos, pero puede ser perjudicial para un equipo sentir ese tipo de presión durante los Sprints. Puede haber ejecutivos, patrocinadores o interesados que deseen utilizar la velocidad como medida de rendimiento, pero esto solo perjudicará al equipo al fomentar tácticas como la intimidación. Si al equipo le preocupa que su velocidad haga parecer que su rendimiento es bajo, la cultura del equipo puede verse perjudicada como resultado.

Restricción: No uses la velocidad como métrica de comparación.

Si lideras varios equipos de Scrum diferentes, puedes verte tentado a comparar la productividad de los dos equipos en función de su velocidad. Puedes tener el impulso de verificar qué equipos están completando la mayor cantidad de puntos de historia por iteración. Sin embargo, la ponderación de los diferentes puntos de historia es subjetiva porque es establecida por el equipo. Un equipo puede considerar que una historia vale cinco puntos, pero otro equipo puede considerar que está más cerca de los tres puntos. Por lo tanto, juzgar la productividad únicamente en función de la velocidad no es exacto ni justo. Además, la velocidad no es una medida de valor. La velocidad de un equipo puede diferir de la de otro equipo, pero esta variabilidad está bien siempre que ambos equipos brinden valor a los interesados.

Recomendación: Procede con precaución al usar la velocidad como métrica para la fecha de entrega del proyecto.

Usar la velocidad para estimar la fecha de entrega de un proyecto que abarca numerosos Sprints puede ser complicado. Los interesados externos que desean establecer una fecha para el lanzamiento de un producto pueden utilizar la velocidad como un punto para ejercer presión. La velocidad también puede crear falsas expectativas y una cultura duramente competitiva cuando el equipo no cumple con las fechas estimadas. Proyectar fechas de entrega es perjudicial porque un equipo puede tardar varios Sprints en comprender realmente lo que son capaces de entregar en cada iteración. Además, si asignas demasiadas fechas con anticipación, no podrás tener en cuenta los cambios ni los problemas que surgirán. Por lo tanto, asegúrate de tener cuidado de no utilizar las fechas de entrega estimadas como compromisos.

Fuente:
Coursera-Gestión de Proyectos de Google.