Informar a la dirección con el Burn Up

El uso de Agile junto con Scrum u otros métodos, no elimina la necesidad de visualizar la que está ocurriendo a las capas superiores, a los clientes internos, e incluso a la dirección. El Burn Up es una herramienta sencilla que nos ayudará en esta tarea.

Desde mi experiencia es muy recomendable que cualquier equipo Scrum o área de IT o departamento que implemente Agile con Scrum, que construya un producto a medio y largo plazo, establezca una serie de métricas claras y medibles, que eviten las sorpresas futuras cuando tengamos que informar a la dirección o las capas intermedias.

Además, es útil el uso de herramientas que automaticen las explotación de los datos necesarios para mostrar esas métricas, como pueden ser JIRA o Kanbanize. Evitaremos que llegado el momento de mostrar que está ocurriendo en nuestro equipo o equipos, tengamos que ponernos a hacer «minería de datos» y generar informes con prisas y poco fiables.

Contenido del Burn Up

En mi experiencia hay siempre tres conceptos clave que el Burn Up nos va a ayudar a medir y mostrar:

      • Valor Estimado: cuánto valor esperamos que aporte a la empresa y/o las clientes el producto una vez completado. Puede ser un beneficio económico, un aumento de ventas, clientes satisfechos, o una combinación de varios objetivos de negocio.  Si no tenemos más remedio, porque no tengamos el valor que aporta cada elementos del Backlog, podremos hacerlo en base a puntos de historia o de historias de usuario.
      • Fecha Estimada: en qué fecha consideramos que deberíamos haber entregado producto que aporte el Valor Estimado.
      • Valor aportado: cuánto valor estamos aportando en cada sprint para conseguir el Valor Estimado. Se irá acumulando Sprint a Sprint.

Con estos tres conceptos podemos mostrar a cualquiera el avance del producto, cuánto llevamos y cuánto nos queda. Y las desviaciones que se producen, tanto positivas como negativas, por cambios de alcance o cambios de fecha.

Este es un Burn Up típico:

Burn Up

Utilización del Burn Up

Mientras nuestro Burn Up esté siempre actualizado con lo que va ocurriendo Sprint a Sprint, nos será muy sencillo mostrar el avance, y utilizar la información que emerge del mismo para reportar a la dirección.

Visualiza rápidamente si con el ritmo actual llegaremos a cubrir el valor estimado para la fecha que espera la dirección

Dado que registramos cuánto valor vamos acumulando Sprint a Sprint, en 2 ó 3 Sprints podremos hacer una primera predicción sobre si llegaremos o no al valor estimado en el tiempo estimado. Según vayan pasando los Sprints los datos recogidos en base a la realidad de lo que ocurre, harán que sea más fiable la predicción.

Nos permite calcular rápidamente la inversión realizada hasta el momento, y estimar cuánto tendremos que invertir para entregar el producto completo, basándonos en lo ya invertido. En dinero, en tiempo, en personas, etc…

De nuevo con la inversión que hemos tenido que realizar en 2 ó 3 Sprints y la estimación de cuántos vamos a necesitar para entregar el producto completo, rápidamente podremos estimar la inversión futura, y contrastarla con la que teníamos prevista.

Nos ayudará a visualizar el impacto que tienen los cambios de alcance, ya sea para incluir o eliminar funcionalidad al producto.

Cada vez que tengamos un cambio de alcance en el producto, nuestro Burn Up sufrirá un cambio en el Valor Estimado, a la alza o la baja. En ese momento, podremos decidir si mantenemos la fecha prevista reduciendo el alcance, o si alargamos la fecha manteniendo el alcance, revisar si con el presupuesto que disponemos es posible realizar el producto con las nuevas funcionalidades. De manera rápida y sencilla observaremos el impacto de los cambios.

Nos ayudará a tomar decisiones sobre si negociar con el alcance o con el tiempo, en caso de que las necesidades de la empresa cambien: time-to-market, reducción de la inversión, nuevas necesidades del mercado, etc..

Todo lo anterior nos llevará a tener información más fiable, ya que se basa en la realidad de lo que está ocurriendo en nuestro producto, y tomar mejores decisiones respecto a aumentar o disminuir el alcance, o si seguir invirtiendo o no llegados a un punto del producto, o si nos interesa alargar la fecha de entrega del producto.

 

El Burn Up está vivo, no está escrito a fuego en piedra y es inamovible. Irá variando con el tiempo, según la realidad nos vaya mostrando si nuestra estimación era acertada o estaba desviada, pero siempre nos ayudará a tomar decisiones basadas en datos objetivos.

 Cuéntanos tu experiencia

Cuéntanos cómo estás usando el Burn Up, si le has visto otros usos además de los que exponemos nosotros. Y como siempre, si necesitas ayuda para construir uno, no dudes en ponerte en contacto con nosotros.

También te puede interesar.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Plan para formar a Scrum Master propios de la empresa

En todo acompañamiento en la transformación a la agilidad con Scrum, llega un momento en que los Agile Coach y Scrum Master externos a la empresa deben dejar al Cliente que siga su camino. Y con garantías de que no se va a perder lo conseguido y se va a seguir fomentando la mejora continua y el customer centric.

En que punto del proceso consideramos el Producto como Entregable

Escoger dentro de nuestro proceso de generación de producto entregable el punto adecuado, puede ser muy complejo cuando dependemos de terceros.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies