¿Cuándo estará terminado el trabajo?

¿Cuándo estará terminado el trabajo?

Proyectar versus predecir

En el desarrollo de productos complejos existe incertidumbre porque la mayoría de las variables son desconocidas debido a los cambios que no se pueden predecir o controlar. Scrum ayuda a resolver problemas complejos usando el empirismo, este enfoque es una mentalidad cultural que se basa en aceptar el cambio y la incertidumbre.

La primera definición a considerar es que no se puede definir exactamente una fecha final para terminar. Aunque podemos proyectar, esta información no predice lo que se va a entregar en cada Sprint o cuando exactamente se terminará. Muchas empresas que usan Scrum todavía siguen usando la información de progreso y de termino como predicciones en lugar de proyecciones (forecast). Por ejemplo, cuando se trata de responder la pregunta de cuando estará terminado el trabajo para terminar los requisitos del producto, tratan de usar de forma equivocada la velocidad promedio como una predicción, para en base a eso reclamar el cumplimiento de compromisos en cada Sprint para lograr las fechas establecidas. Las proyecciones son posibilidades no certezas.

Recomendaciones cuando hablamos de fechas:

1. Expresar las fechas proyectadas en termino de posibilidades, probabilidades o rangos de posibilidades, evitar el compromiso con fechas exactas. Sugerencia usar algunos gráficos definidos en Kanban como Montecarlo, que se muestra en la figura para hablar en términos de probabilidades.
2. Introducir en la conversación el concepto de valor y contexto de negocio con métricas que provean transparencia. Una conversación solamente basada en fechas se vuelve improductiva para proveer foco y mejorar los resultados de negocio.
3. No usar los promedios, ni intentar estabilizar o estandarizar la velocidad en puntos de historia a través de influencia con incentivos externo. Esto puede llevar a falta de transparencia del progreso y microcontrol.
4. Usar Scrum y el enfoque incremental para validar las suposiciones más riesgosas primero con foco en la entrega de valor para mejorar el “Tiempo promedio para aprender”. Buscar mejorar la validación de la entrega de valor y la identificación de nuevas oportunidades para reducir la brecha de satisfacción.
5. Inspeccionar y adaptar el Product Backlog en cada Sprint junto con las fechas proyectadas.
6. Usar Kanban con sus métricas y gráficos de Kanban.