Los user story points y la velocidad se han utilizado durante muchos años en la comunidad Scrum y Agile.
Se han arraigado tanto en la forma en que se hacen las cosas que la mayoría de la gente cree que son parte de Scrum.
Y no lo son.
La sabiduría aceptada es que se supone que los equipos Scrum deben usar historias de usuario por defecto, puntos de historia y velocity para medir su trabajo.
Hay una serie de cosas que creemos colectivamente que se requieren para hacer Scrum.
Estas han sido perpetradas por la perseverancia a largo plazo de los agile coaches / scrum masters que enseñan al mínimo común denominador y mantienen las cosas lo más simples posible.
Sin embargo, si vas a echar un vistazo a la Guía de Scrum y ves cuántas veces se hace referencia a cosas comunes que crees que son obligatorias en Scrum:
- Velocity: 0
- Puntos de historia: 0
- Burndown: 0
- Historias de usuario: 0
- Estimación original: 0
- Recuento de errores: 0
- Puntos completados: 0
¡La respuesta es cero! Estas son prácticas complementarias que pueden o no funcionar dentro de los límites de la complejidad de tu organización.
Todas estas son una indicación para mí de que tu organización apenas está comenzando su evolución hacia la agilidad. Está en sus primeros pasos.
Está bien que un equipo comience con Story Points y Velocity. Sólo faltaría.
Hay muchas cosas que cambian cuando un equipo pasa de las prácticas tradicionales de gestión de proyectos del pasado a las prácticas empíricas del futuro y, a veces, tenemos que elegir nuestras batallas. Una de esas batallas es la de los puntos de la historia y la velocity para pasar a otras métricas.
Quizás necesitamos aterrizan la tranquilidad en otras partes de la organización que aún no están listas para el cambio. Quizás tenemos un largo viaje y este es solo un lugar para comenzar.
Story Points & Velocity puede ser un buen punto de partida.
No estoy diciendo que no haya ningún valor en Story Points, Planning Poker o la velocity.
Cuando un equipo recién está comenzando, debe mantener las cosas simples e iterar hacia mejores resultados.
A menudo partimos de prácticas tradicionales típicas y Planning Poker se convierte en un buen punto de aprendizaje.
Los user story points utilizan un tamaño aproximado como una forma de analizar el trabajo y desglosarlo.
Porque en realidad, las puntuaciones se inventan y los puntos no importan. Es la conversación lo que es valioso de verdad.
Ese entendimiento compartido que se obtiene de los participantes al tener alguna forma de saber cuándo no entienden las mismas cosas. Eso es asombroso lo poderoso que eso es.
Sin embargo, los equipos ágiles intentan usar Story Points y Velocity para predecir el futuro y esto es una falacia.
Si bien estaría bien que un equipo lo use por un tiempo, si un equipo ágil sigue usando Velocity y Story Points después de tener 5 o 10 sprints en su haber. e
Entonces tendría serias preocupaciones sobre su capacidad para adaptarse al cambio y su sinceridad hacia ese cambio.
Lo que quiero decir es que simplemente no comprenden su trabajo o su naturaleza. ¡Esto es lo que quiero decir con inmadurez, y no que otra cosa sea un signo de madurez!
De hecho, como el equipo Scrum que usa Story Points realmente no tiene una referencia consistente, simplemente están disparando en la oscuridad igual que antes.
Si bien han adquirido una comprensión de los objetivos, todavía no comprenden el pronóstico sobre el trabajo y, por lo tanto, no confían en sus predicciones.
Necesitamos datos concretos para generar confianza con las partes interesadas de que sabemos de lo que estamos hablando.
La confianza se gana al comprender verdaderamente la incertidumbre de la entrega y tenerla en cuenta en nuestros pronósticos.
¿Qué tan seguro está de que podrá entregar? ¡No realmente! ¿Cuál es su nivel estadístico de confianza?
En el mundo empírico, donde se desconoce más que se sabe, no planificamos todo el trabajo (cambiará) y no podemos decirle cuándo se harán las cosas.
Excepto cuando podamos afirmar lo siguiente:
- El Incremento es la Confianza en la Transparencia del Futuro – Si tenemos un Equipo Scrum, entonces debería estar seguro de poder decir que tendremos un incremento utilizable al final de cada Sprint. Si eso es cierto, entonces podemos tener un 100% de confianza en que podemos ofrecer el resultado del último Sprint. ¡Funciona y está hecho!
- El Product Backlog es la Confianza de la Transparencia del Futuro – Dado que tenemos un Backlog que ha sido ordenado por el Product Owner, quien es responsable de maximizar el valor entregado, puedo estar seguro de que lo que hemos hecho representa las cosas más valiosas que hemos podría haber hecho.
Si ambos son ciertos, podemos tener un 100% de confianza en que tenemos los elementos más valiosos que la empresa necesita para completar y estar listos para implementar.
Cada Sprint adicional solo aumenta la cantidad de valor entregado.
Usando un diagrama de dispersión de tiempo de ciclo, podemos evaluar y encontrar nuestros niveles de confianza.
Incluso crear una Expectativa de nivel de servicio dentro de nuestros equipos, que nos permite medir el progreso.
Hasta podemos llegar a utilizar este rango de niveles de confianza para determinar nuestros niveles actuales de previsibilidad y supervisar el efecto de los cambios que realice en su sistema.
Si tienes un nivel de confianza del 85% en 16 días y estás en Sprints de 2 semanas, entonces tienes un problema.
Básicamente porqué no eres capaz de terminar nada en el tiempo de sprint que estas manejando con los user story points.
