En cada interacción que tengo con un equipo ágil, siempre sale la conversación de la velocity y los story points. Siempre siempre siempre, no falla nunca.
Y siempre, eso en un punto de inflexión en la relación que tengo con el cliente o las personas que estén compartiendo una capacitación conmigo.
Básicamente, unen siempre story points y velocity a Scrum, cosa que no es cierta, ya que nunca han sido mencionados en la guía Scrum.
Dejadme explicar porqué recomendamos usar story points ni velocity en tus equipos explicando que son estos 2 conceptos.
¿Qué son los story points o puntos de historia?
Los equipos ágiles usan puntos de historia porque proporcionan una forma de estimar el tamaño relativo y la complejidad de una tarea o historia de usuario sin especificar la cantidad exacta de tiempo que llevará completarla.
Esto es importante porque permite que el equipo se concentre en el trabajo en sí, en lugar de atascarse en estimaciones de tiempo detalladas que pueden no ser precisas.
Los puntos de la historia también permiten que el equipo compare el tamaño relativo y la complejidad de diferentes tareas, lo que les ayuda a priorizar y planificar su trabajo de manera más eficaz.
Al usar una escala común, como la secuencia de Fibonacci, el equipo puede comprender más fácilmente el tamaño relativo y la complejidad de las diferentes tareas y hacer predicciones más precisas sobre cuánto trabajo se puede completar en un período de tiempo determinado.
Además, el uso de puntos de la historia ayuda a establecer una comprensión compartida del trabajo entre los miembros del equipo, lo que puede ayudar a mejorar la comunicación y la colaboración.
Al tener un lenguaje común para describir el trabajo, los miembros del equipo pueden discutir y comprender más fácilmente las tareas en cuestión.
Además, usar story points se utilizan para medir la velocidad del equipo, que es la velocidad a la que el equipo completa los puntos de la historia a lo largo del tiempo.
Esta métrica ayuda al equipo a comprender cuánto trabajo pueden realizar de manera realista durante un sprint y les permite planificar y priorizar su trabajo en consecuencia.
También les ayuda a identificar y abordar cualquier problema desde el principio, y garantizar que el proyecto se mantenga encaminado.
¿Qué es la Velocity?
En un entorno Agile, la Velocity es una medida de la velocidad a la que un equipo completa el trabajo durante un período de tiempo.
Por lo general, se mide en puntos de historia, que son un método para estimar el tamaño relativo y la complejidad de una tarea o historia de usuario.
La Velocity es una métrica clave utilizada para planificar y seguir el progreso de un proyecto.
Ayuda al equipo a comprender cuánto trabajo pueden realizar de manera realista durante un sprint y les permite planificar y priorizar su trabajo en consecuencia.
Al manejar su Velocity a lo largo del tiempo, el equipo puede identificar tendencias y hacer los ajustes necesarios para mejorar su desempeño.
La Velocity también se usa para pronosticar cuándo se completará un proyecto y para identificar cuándo el equipo se está retrasando. Esto ayuda al equipo a identificar y abordar cualquier problema desde el principio y garantizar que el proyecto se mantenga encaminado.
Es importante tener en cuenta que la velocidad no es una medida de qué tan rápido está trabajando el equipo, sino más bien una medida de cuánto trabajo puede completar el equipo en un período de tiempo determinado.
Además, es una métrica de equipo y no se utiliza para evaluar el desempeño individual.
¿Por qué la Velocity y los Story Points no son una buena práctica?
Ese lenguaje común del que hablamos, solo lo mantienen las equipos de desarrollo. El resto de la organización habla en horas, días, o otras unidades de esfuerzo.
Por eso, lo mejor y lo que recomendamos en Agile611, es que se usen métricas de flujo en lugar de usar story points.
Por naturaleza las métricas de flujo van muy vinculadas al progreso del trabajo y a la visualización.
Contar el tiempo de ciclo, cuanto tiempo una historia de usuario lleva siendo trabajada por un equipo, cuanto entra o cuanto trabajo sale es una cosa fundamental que va más allá de los puntos de historia y de la velocity.
En lugar de estimar, también hablamos de pronosticar con el modelo Montecarlo, mucho más basado en datos de tu equipo que en una convención y lenguaje común hecho por el equipo de desarrollo.
