Hola Habr! Les presento la traducción del artículo
"Por qué no uso los puntos de historia para la planificación de Sprint" por Mike Cohn.
Como se describe en Agile Estimating and Planning, soy un gran admirador de los puntos de historia para evaluar los retrasos en los productos. Sin embargo, también recomiendo evaluar el retraso del sprint en horas en lugar de los puntos de la historia. ¿Por qué es esta aparente contradicción? Anteriormente escribí sobre las razones. Recomiendo usar diferentes unidades de medida (puntos y horas) para diferentes atrasos.
Pero a menudo me hacen una pregunta relacionada, que quiero hacer aquí:
Tengo curiosidad por qué no estás usando puntos de historia para la planificación de sprint. Pensé que el punto de medir la velocidad en los puntos de la historia era, en parte, determinar cuánto podemos tomar (o arreglar) en el sprint. ¿Utiliza solo puntos de historia para la planificación a largo plazo (por ejemplo, planificación de lanzamiento)?No uso puntos de historia para la planificación de sprint porque los puntos de historia son una medida útil a largo plazo. Pero los puntos no son útiles a corto plazo.
Sería apropiado que el equipo dijera: "Tenemos una velocidad promedio de 20 puntos de historia, y nos quedan 6 sprints, así que terminaremos unos 120 puntos de historia en estos seis sprints".
Sería inapropiado para el equipo decir: "Tenemos una velocidad promedio de 20 puntos de historia, así que terminaremos en el próximo sprint". Esto no funciona
Supongamos que el equipo de baloncesto está en la mitad de su temporada. Hasta la fecha, han jugado 41 juegos y anotaron un promedio de 98 puntos por juego. Sería apropiado decir: "Probablemente, anotaremos un promedio de 98 puntos por juego en el resto de la temporada". Pero no deberían decir antes de ningún juego específico: "Tenemos un promedio de 98, por lo que tomaremos 98 hoy". Por eso digo que la velocidad es un predictor útil a largo plazo, pero no un predictor útil a corto plazo.
La velocidad variará de sprint a sprint.
Es por eso que quiero que los equipos planifiquen sus sprints mirando la cartera de productos, eligiendo una de las cosas más importantes que podrían hacer, dividiendo este elemento / historia de usuario de la cartera de productos en tareas y evaluando las tareas, preguntándose si pueden tomar compromisos para liberar este elemento del producto atrasado y luego repetir hasta que se llenen. Sin discusión de puntos de la historia. No hay discusión de velocidad. Es solo una cuestión de obligaciones, y decidimos cuánto podemos cumplir separando los puntos del trabajo atrasado del producto en tareas y evaluándolos.
Cuando el equipo termina de planificar el sprint de esta manera, es probable que el número de puntos de historia que persiguen sin saberlo esté cerca de su valor promedio, pero cambiará.
También será cierto que el equipo realizará aproximadamente la misma cantidad de horas de un sprint al siguiente. Utilizo el término "capacidad" para referirme a este número de horas porque la velocidad está reservada para referirse a una medición del volumen de trabajo planificado o completado, como se indica en las unidades utilizadas para evaluar el trabajo atrasado del producto (que recomiendo usar puntos de historia )
Sobre el autor: Mike Cohn es uno de los autores de la metodología de desarrollo de software Scrum. Es uno de los fundadores de Agile Alliance y Scrum Alliance. Se especializa en ayudar a las empresas a implementar y mejorar el uso de procesos y métodos ágiles para crear equipos de alto rendimiento.
Referencias:
Estimación y planificación ágiles , Mike Cohn, 2005.
PD: ¿Calificas la acumulación de sprint en horas o puntos de historia?