Inicialmente, el Product Backlog contenía 350 puntos de historia de PBI. Después de completar 7 sprints de desarrollo, el Product Backlog contiene 140 puntos de historia de PBI.
La velocidad media es de 30 por sprint. Entonces se necesitan 12 sprints para terminar todo el proyecto.
Después de Sprint 9, su cliente solicita agregar una nueva función. Su equipo estima que son 15 puntos de historia. Luego, después del Sprint 10, el cliente solicita que se agregue otra función. Usted estima que el tamaño de esa característica es de 9 puntos de historia. Suponiendo que la velocidad de su equipo no cambia, calcule estimaciones para el número total de sprints.
El alcance continuará aumentando a la tasa del promedio de los aumentos al final de los Sprints 9 y 10. Aumentará a esta tasa hasta que el Product Backlog se agote por completo durante un Sprint.
Aquí es donde me resulta difícil. No estoy seguro de cómo estimar el número de sprints necesarios en este caso. ¿Qué se supone que significa aumentar la tasa?
Dado que esto es solo una estimación, no creo que se necesite un cálculo difícil, ¿verdad?
Cualquier ayuda es apreciada.
Esto parece una especie de pregunta teórica, pero puedo dar algunos consejos sobre cómo abordar esto.
Ya has identificado:
La fórmula simple para "¿cuánto tiempo hasta que terminemos?" es Tamaño/velocidad de la cartera de pedidos. Esto le da el número de sprints.
Sin embargo, parece estar atascado en "¿Qué pasa si se siguen agregando nuevas historias?".
En este caso, tienes un tercer número:
Con este número adicional, la cartera de pedidos se está reduciendo más lentamente de lo que lo haría si no hubiera un aumento del alcance. Esencialmente, para obtener la tasa de reducción, debe restar el aumento del alcance de la velocidad para obtener la cantidad de puntos que reduce el Backlog:
Tamaño de la cartera de pedidos / (Velocidad - Alcance aumentado)
Entonces, si tiene 140 puntos en el backlog, tiene una velocidad de 30 y el alcance aumentado es 12 por sprint, básicamente está quemando 30-12 = 18 puntos de backlog por sprint, por lo que necesita un total de 140/18 = 8 sprints para terminar el proyecto.
Uno de los mayores peligros del alcance aumentado es que, a medida que se acerca a la velocidad, su tiempo total en el proyecto se disparará. Por ejemplo, si su alcance aumentado aumenta a 25 puntos por sprint, entonces su reducción se convierte en 30-25 = 5 por sprint, ¡y completar el proyecto requiere otros 28 sprints!
Una vez que iguala o supera la velocidad, nunca terminará el proyecto. Esto es intuitivo de entender; está generando más trabajo por sprint de lo que puede resolver en ese tiempo.
Dado que el crecimiento promedio de la cartera de pedidos es 12 y la velocidad es 30 en este ejemplo, parece que el punto final proyectado es de 15 sprints. El ejemplo parece poco realista ya que supone una tasa de crecimiento constante y predecible, probablemente improbable en la práctica.
Aquí es donde un gráfico de quemado puede ser una herramienta más útil que un quemado. Un gráfico de quemado muestra el cambio en el alcance del objetivo por separado de la línea de tendencia.
Todd A. Jacobs