Velocidad: cómo interpretarla para mejorar la productividad de tu equipo ágil. 1 de 3: Sabores de velocidad

Velocidad es una métrica comúnmente utilizada en equipos ágiles. Es una métrica que es útil debido a su aparente simplicidad. Sin embargo, a menudo veo equipos sacando conclusiones equivocadas basados en interpretaciones erróneas de la métrica, lo que resulta en una menor productividad.
Esta publicación es el comienzo de una serie de tres partes para transmitir mi comprensión de cómo darle sentido a la información que la velocidad, como métrica, puede proporcionar a un equipo ágil. Y  – sobre todo, como utilizar esta información para mejorar la productividad.

¿Qué entiendo por Velocidad?

No se cual es la primera referencia a Velocity, como métrica. Claramente, está íntimamente vinculado a los equipos que utilizan Scrum con historias de usuarios. Sin embargo, no hay ninguna referencia explícita a la velocidad en las Guías de Scrum actuales.

El artículo original de Schwaber en OOPSLA 95, menciona casualmente los conceptos de “velocidad y aceleración del proyecto”, pero no se refiere específicamente a ellos como una métrica. Y en el libro “Estimación y planificación ágiles”, el uso de Velocity está bien desarrollado y este libro ha sido el libro de texto que he utilizado en mis cursos estimación en proyectos ágiles en la Universidad.

En esta serie transmitiré mi comprensión y uso de la velocidad como métrica para mejorar la productividad de los equipos ágiles.

Medición, medida y métrica

Antes de comenzar con Velocity, debemos aclarar nuestro lenguaje sobre la medición de software. Medición, medida y métrica son tres palabras que representan tres conceptos diferentes y, sin embargo, a menudo veo que estas palabras se usan como sinónimos. Y es importante diferenciar estos conceptos para hacer un buen uso del proceso de medición del software.

Medición: Este es el acto de comparar una atributo distinguible de una entidad contra un patrón acordado.

Medida: Es el resultado del acto de medición y debe expresarse mediante un número y una unidad.

Los conceptos de entidad y atributo son claves para la comprensión de la medición:

Entidad es el objeto que se está midiendo.

Atributo son las características de la entidad que se está midiendo.

La Métrica, reúne todos estos conceptos en un constructo que se identifica con un nombre y define la entidad y atributo que se mide, el proceso y unidad de medición y el indicador.

Usaré el siguiente formato para definir una métrica en esta serie:

Nombre	<Nombre de la métrica>
Entidad	<Nombre de la Entidad>
Atributo	<Nombre del atributo>
Medición	<Una descripción del proceso de medición y la fórmula>
Unidad	<Nombre de la Unidad>
Indicador	<Una descripción de los criterios para el uso de la métrica>

Con esto, estamos listos para definir la Velocidad.

¿Velocidad, o Velocidades? Tres variaciones

Siguiendo esta comprensión de Medida, medida y métrica, podemos observar que Velocidad es un término sobrecargado. Por lo tanto, necesitamos eliminar la ambigüedad de los tipos de métricas relacionadas con la velocidad.

Primero, velocidad diaria:

Nombre	Velocidad diaria
Entidad	Equipo
Atributo	Productividad
Medición	Diariamente en el Sprint: 1) Suma de puntos de Historias de Usuario completadas 2) Restar del total de puntos de historia de usuario en el sprint 3) Agregue el punto del día en el gráfico de evolución
Unidad	Puntos de historia/día
Indicador	Una comparación con la velocidad ideal para el sprint. Generalmente se representa en un gráfico de evolución

Es en Burndown chart donde se pueden observar los conceptos de velocidad y aceleración (mencionados en el paper original de Scrum). La velocidad diaria es la distancia entre dos puntos consecutivos y la aceleración es la pendiente.

La interpretación ingenua es que, en los días en que la velocidad diaria está por encima de la velocidad ideal del espíritu, entonces la pendiente es mayor que la pendiente de la velocidad planificada para el sprint.

La aceleración se observa cada vez que la pendiente cambia de ángulo.

Normalmente, al observar los gráficos de evolución, los equipos tienden a centrarse en el trabajo restante y la diferencia entre él y la tendencia ideal, no en la velocidad. Como resultado, ponen mucho más énfasis del necesario en estar cerca de la línea de tendencia ideal.

Cumplir con la estimación no es el objetivo (más sobre esta falacia la próxima semana), particularmente porque ni la velocidad ni el trabajo restante son medidas de valor. 

Pasando a la velocidad de sprint:

Nombre	Velocidad en el Sprint
Entidad	Sprint
Atributo	Trabajo realizado
Medición	Al final del sprint: Suma de puntos de historias de usuarios terminadas
Unidad	Puntos de historia/Nombre del Sprint  o número del Sprint
Indicador	Comparación con los puntos de historia estimados en el sprint (*)

Este tipo de velocidad es útil para revisar el sprint recién finalizado. Sin embargo, esta no es una métrica que sea particularmente significativa de forma aislada. Los equipos deben evitar calificar el éxito de sus sprints únicamente según esta métrica.

Finalmente, la velocidad promedio:

Nombre	Velocidad media
Entidad	Equipo
Atributo	Productividad
Medición	La suma de puntos de la historia de sprints anteriores / Número de sprints considerados (**)
Unidad	Puntos de historia por sprint
Indicador	N / A

Esta métrica se utiliza para informar la planificación, por lo tanto, nunca he trabajado con un indicador para esta métrica.

Puntos de la historia

Los puntos de la historia son la última pieza. Los puntos de la historia son la unidad con la que se miden las historias de usuario. Debería ser una unidad para medir complejidad – de la entidad Historia de usuario. Sin embargo, veo muchos equipos que usan los puntos de historia como unidad de esfuerzo o como un proxy al esfuerzo que lleva realizar una historia de usuario.

Este es un error común, donde N Story Points se equiparan a un día de trabajo. Los equipos que hacen esto efectivamente se impiden observar una de las dimensiones de la gestión de proyectos.

La escala más utilizada con los puntos de historia es la Escala de Fibonacci. Sin embargo, el factor de confusión es que en la estimación ágil utilizamos esta escala para codificar dos conceptos (medida y precisión) en el mismo número. 

En la secuencia de Fibonacci, cuanto más grande es el número, más grande es la diferencia con el anterior. Es decir, cuanto más grande es el número, menor es la apreciación. 

 El correcto uso de este dato es que comunica incertidumbre. Entonces, si la complejidad de mi punto de historia es 3. Entonces mi incertidumbre está entre 2 y 5. Pero si mi punto de historia es de complejidad 13, entonces mi incertidumbre está entre 8 y 21.

Resumen

Este post ha sentado las bases para la discusión sobre cómo utilizar Velocidad en procesos de desarrollo ágil de software. La próxima semana publicaré sobre cómo interpretar estas métricas, seguido de una breve publicación de preguntas y respuestas la semana siguiente.