¿Cuándo acabará? El Gráfico Burndown Release

El trabajo estará acabado cuando esté acabado. Exigir que un nuevo producto, servicio o actualización se termine el 23 de enero de 2016 simplemente no es útil. Los plazos arbitrarios simplemente causan exceso de estrés y angustia para todos – desarrolladores, clientes y gerentes. Las personas que hacen el trabajo pasan largas horas lejos de su familia para alcanzar un objetivo inalcanzable, los gerentes y altos dirigentes aceptan estrés innecesario para cumplir con un objetivo que nadie cree y los clientes sufren por recibir productos de baja calidad.

Entiendo que las empresas necesitan tener una idea de las fechas de entrega ya que los clientes, usuarios y socios necesitan saber cuándo estará listo para recibir el nuevo producto. Sin embargo, nuestro historial de entrega sobre un ámbito fijo, con fecha fija y con un presupuesto fijo es horrible. Hay demasiados cambios en el desarrollo de software para aceptar ésto como una condición previa. Como industria, tenemos que reconocer que nuestro patrón de realizar compromisos por adelantado con la esperanza de que por arte de magia demos en el blanco en una fecha concreta tiene que cambiar.

En lugar de apuntar nuestro cañón hacia un blanco estacionario y anticipar que daremos en la diana, nuestra meta debe ser la de dirigir el proyecto hacia el éxito paso a paso. Si tenemos nuestro destino en mente y traemos a nuestros clientes al proyecto como pasajero, alterar el curso cada dos semanas no sería tan difícil. Con el fin de hacer esto con éxito, tenemos que saber cómo lo estamos haciendo en relación  con el alcance original y ahí es donde un gráfico de burndown release viene muy bien. Para ver más gráficos Burndown Release, eche un vistazo a este artículo de 2010 (inglés).

Gráfico Burndown Release

Objetivo: mostrar el progreso incremental del ámbito completado y proporcionar una mayor visibilidad cuando se añade alcance.

Variaciones: ninguna.

Audiencia: Gerentes, Product Owners, ScrumMasters, Stakeholders, líderes senior.

Modo de empleo: al comienzo del lanzamiento, el equipo viene con una lista inicial de elementos de trabajo que van a completar y presenta una suma de todas las estimaciones. Al final de cada iteración, el equipo proporciona una actualización de la cantidad de alcance que se completó. En el diagrama de un comunicado con fecha de lanzamiento dividido en ocho iteraciones de igual tamaño, esto está representado por los bloques verdes, mientras que los bloques rojos representan el alcance sin terminar.

Cuando se añade un nuevo alcance en la iteración #4, se indica mediante un bloque amarillo. Como resultado, la altura total de la barra sube mostrando que el alcance ha aumentado para este proyecto. En la iteración #5, vemos la altura de los aumentos de bloques de color rojo para indicar el nuevo alcance (sin terminar).

Al igual que las gráficos Burndown y Burnup, utilizamos proyecciones lineales para ver si el equipo va a completar el alcance en la fecha de vencimiento (en este caso en el cierre de la iteración #8). En las iteraciones de la #1 al #4, el equipo estaba haciendo un buen progreso, tal vez incluso pudiendo terminar por adelantado. Sin embargo, la adición de nuevos alcances en la iteración #4 ha cambiado el panorama. Si tuviéramos que trazar una línea recta que uniera a los puntos centrales de la parte superior de los bloques rojos de las iteraciones #5 y #6, veríamos completar el proyecto algún tiempo después de la iteración #8.

En consecuencia, en la iteración #7 algo de alcance fue retirado del proyecto (representado por el bloque morado). El alcance eliminado se toma normalmente del alcance sin terminar, por lo que la altura del bloque rojo disminuye en la iteración #7. También tenga en cuenta que el alcance total entregado al final de la iteración #8 fue inferior a lo que se ha había comprometido originalmente durante la iteración #1 y cierto margen permanece inconcluso al cierre. En función de una serie de circunstancias – las necesidades del negocio, relaciones con los clientes, obligaciones contractuales – esto puede, o no, ser aceptable.

Cuándo no utilizar: para proyectos donde la mayor parte del trabajo es exploratorio o cuando adiciones alcance, o sustracciones, superen el 50% de las estimaciones iniciales.