Retrospectiva (Sprint Retrospective)
26 diciembre, 2012
Caso de éxito de la migración a Azure de Nomaders en la web de Microsoft España
10 enero, 2013

Al igual que en mi anterior post, hago una breve introducción de lo que es Scrum por si hay algún iniciado en el tema:

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.

Una de las herramientas más utilizadas en Scrum es el diagrama Burn Down. Un diagrama burn down es una representación gráfica del trabajo que queda por hacer en un proyecto (o en un determinado Sprint) en el tiempo. Normalmente el trabajo a realizar se muestra en el eje vertical y el tiempo en el eje horizontal. Es decir, el diagrama representa una serie temporal del trabajo pendiente. Este diagrama es útil para predecir cuándo se completará todo el trabajo.

Si bien, el objetivo principal de este diagrama es mostrar el tiempo esperado para entregar las tareas comprometidas en un Sprint y su evolución, también es muy útil para detectar posibles problemas que pueden estar surgiendo durante el desarrollo del mismo.

En circunstancias normales un diagrama burn down debería tener un aspecto parecido al siguiente:

BurnDown

La línea roja muestra el progreso que debería seguir el Sprint en condiciones normales.

La línea azul muestra el progreso que sigue el Sprint después de ser actualizados los tiempos restantes para finalizar cada tarea por parte del equipo de desarrollo.

Como ya sabemos, el mundo no es perfecto y siempre surgen imprevistos. Algunos de ellos se pueden detectar echando un vistazo al diagrama de Burn Down.

Los más típicos son los siguientes:

  1. Hemos subestimado tareas:

BurnDown Subestimado

Posibles acciones: Quitar elementos de la pila del Sprint.

  1. Hemos sobreestimado tareas:

 BurnDown Sobreestimado

Posibles acciones: Añadir elementos de la pila del Sprint.

  1. El equipo está desarrollando tareas de baja importancia ignorando las de alta:

 BurnDown Tareas Baja Importancia

BurnDown Tareas Baja Importancia

Posibles acciones: Preguntar al equipo de desarrollo si existe algún impedimento por el cual no se estén haciendo las tareas de prioridad alta y si no existe, animarle que realice primero estas tareas.

  1. Existen impedimentos para no realizar ninguna tarea o se están realizando tareas no planificadas:

BurnDown Tareas No Planificadas

BurnDown Tareas No Planificadas

Posibles acciones: Averiguar cual es la razón por la que no se están desarrollando las tareas comprometidas. Si existen impedimentos para realizar las tareas, tratar de solucionarlos lo antes posible. Si es porque se están realizando tareas no planificadas, revisar la importancia de dichas tareas. Si estas tareas son más importantes que las del Sprint, habrá que eliminar elementos de la pila del Sprint y si por el contrario son más importantes las tareas del Sprint, incitar al equipo de desarrollo que realice éstas primero.

Como se ha podido comprobar, esta herramienta es muy útil para ver el progreso del Sprint, que es su principal cometido, pero también para detectar posibles problemas relacionados con el desarrollo y poder afrontarlos lo más pronto posible.

 

Compártelo: Share on FacebookTweet about this on TwitterShare on LinkedInPin on Pinterest

Comments are closed.

NEWSLETTER