¿Es posible pronosticar cuándo un equipo Scrum completará la cartera de productos?

Si puede obtener 2-3 sprints de velocidad, como recomienda DrewJordan, esta es sin duda la mejor manera. Dicho esto, la realidad a menudo nos encuentra frente a la gerencia que pregunta "¿Cuándo se puede terminar?", incluso antes de que el trabajo haya comenzado. Si esto sucede, hay un método que aprendí de Agile Learning Labs que funciona bien.

Advertencia: para hacer esto, debe hacer una estimación completa de la cartera de pedidos. Si está tratando de estimar el trabajo atrasado de un año completo, esto no será exacto. Nada puede estimar bien un año más producto. Sigue siendo mejor que los modelos actuales.

Paso 1: Elija un marco de tiempo de lanzamiento razonable. Si está haciendo ágil, entonces debería buscar lanzar cada tres meses como máximo. De lo contrario, perderá gran parte del valor de Agile y también le resultará difícil hacerlo cuando no haya comentarios reales. Esto también abordará directamente el desafío de la Advertencia mencionada anteriormente.

Paso 2: estimar el backlog. Como se menciona en la advertencia, esto debe suceder para poder pronosticar una fecha de lanzamiento.

Paso 3: Planifica un primer Sprint teórico. Ahora bien, esto no es que la administración asigne historias a un Sprint. Esto es honesto a la bondad de la planificación auto-organizada del equipo. Tome la primera historia de la cartera de pedidos y el equipo se pregunta: "¿Creemos que podemos hacer esto en el sprint (son dos semanas de duración, verdad? :)). Luego repita esto. Siga haciendo esto hasta que el equipo no lo haga". No se sienten ni cerca de sentirse cómodos de poder completar una historia. Esto es CLAVE. Si incluso una persona piensa que no se puede hacer, entonces deténgase y no agregue la historia. Es mejor subestimar que sobreestimar en esta etapa. .

Paso 4: Proyección. Suma los puntos de la historia de la planificación del sprint. Ahora divida el total de puntos de la historia en un lanzamiento (recuerde, su objetivo no es más de tres meses). En este punto, tiene cuántos sprints se necesitarán para completar el trabajo. Si eso es más de tres meses de trabajo, el lanzamiento probablemente sea demasiado grande y debería ver lo que realmente se necesita.

Paso 5 Reforzar esto es un PRONÓSTICO. Cuando proporcione el tiempo estimado, dígalo como "Tenemos un 60% de confianza en este cronograma". Luego siga esto con "Después de nuestro primer Sprint, eso debería subir al 70 % y después de nuestro segundo sprint al 80 %. Para nuestro tercer sprint, deberíamos tener un 90 % de confianza en cuál será nuestra fecha de envío final o en lo que habremos hecho si la fecha de envío debe fijarse en un determinado punto del calendario".

Nunca tendrás más del 90% de confianza, no lo intentes. A la madre naturaleza ya Murphy les encanta meterse con cualquiera que diga "tengo 100% de confianza".

Puede estimar una fecha de finalización, un rango de fechas, un sprint de finalización, etc. dividiendo el tamaño actual de la cartera de pedidos (en SP) por la velocidad actual de los equipos, pero...

1. Definitivamente recuerde a cualquiera que mire su pronóstico que es una estimación
2. Comprueba rápidamente qué tan variable es tu velocidad. ¿Cuál es la velocidad de las últimas 3 iteraciones del equipo? Iteración actual? ¿Duración total del proyecto? Una velocidad altamente variable debería incitarle a reducir su confianza en cualquier resultado de pronóstico a largo plazo.
3. Enumere todas sus suposiciones y el método que usó para derivar el pronóstico antes de presentar su(s) número(s). Asegúrese de que su audiencia comprenda el impacto de las suposiciones que tuvo que hacer.
4. Sea honesto acerca de su confianza al proporcionar el pronóstico
5. Intente proporcionar un rango de fechas en lugar de una fecha específica con números de mejor, medio y peor caso. Puede hacer todo tipo de fantasía con simulaciones de Monte Carlo y herramientas como Crystall Ball si lo desea.
6. Use sus escenarios como una oportunidad para escalar los riesgos
7. NO haga ningún compromiso de tiempo a largo plazo basado en sus números de pronóstico. El pronóstico debe usarse principalmente como una herramienta para discutir y resaltar los riesgos/deficiencias que deben abordarse para satisfacer las necesidades de alto nivel del cliente.

Vale la pena recordar que Scrum es un marco ágil y ágil se trata de responder al cambio.

Está bien y, a menudo, es útil usar la velocidad del equipo para pronosticar cuándo se completará un trabajo pendiente. Pero tenga en cuenta que durante el proceso de desarrollo estará esperando y dando la bienvenida al cambio. Al final de cada sprint, realiza una revisión del sprint en la que obtiene comentarios de su propietario del producto y las partes interesadas. El equipo debe esperar que esta retroalimentación ayude a acercar el desarrollo del producto a lo que las partes interesadas y los usuarios realmente quieren.

El resultado de este proceso iterativo es que es muy poco probable que los pronósticos a largo plazo sigan siendo los mismos. Incluso puede ser necesario revisar los pronósticos a largo plazo después de cada sprint.

Sí, eso es exactamente lo que debes hacer. Recomiendo usar al menos 2 sprints, y preferiblemente 3, para determinar una velocidad promedio.

También es importante enmarcarlo en términos de probabilidad: si tu velocidad es 5 y hay 20 puntos, entonces probablemente terminarás después de 4 sprints. Salvo que cambie el alcance, surja un imprevisto, se materialice un riesgo, etc.

Lo que haría es, para los elementos que no están completamente definidos, haz lo mejor que puedas. Proporcione un rango de pronóstico (es decir, digamos 4-6 iteraciones). Esto le da algo de espacio para cambios en el alcance o lo que pueda surgir, al mismo tiempo que le da a las partes interesadas una estimación de la finalización. Refuerce las ideas de que pueden cambiar la fecha de finalización en cualquier dirección en función de los requisitos o el alcance cambiantes si sienten la necesidad.

Si necesita algo que sea más científico, puede echar un vistazo a las fórmulas PERT . Esto puede darle una idea estadística de cuándo se realizará el proyecto y qué tan probable es esa estimación. Es útil cuando sus ejecutivos exigen más detalles que "4-6 sprints", pero también le permite recordarles que es una probabilidad, no un hecho.

Puede trazar la velocidad de sus equipos contra la acumulación y obtener fechas de lanzamiento optimistas y pesimistas.

La línea negra ondulada es la línea de quemado de su equipo: fluctúa porque la velocidad a menudo fluctúa. La línea verde es una estimación de su mejor quemado/velocidad y la roja es una estimación de su peor quemado/velocidad. Donde se cruzan con la línea de alcance fijo proporciona una estimación de la fecha de lanzamiento. Un video que explica esto está aquí .

Tengo buena experiencia con la estimación de Agile Monte Carlo, por ejemplo , https://agilemontecarlo.com . No basta con tener en cuenta la velocidad media para obtener el perfil de riesgo del proyecto. Especialmente para la comunicación con las partes interesadas, es bueno conocer la fecha de entrega simulada del 25 % y el 75 %.