¿Cómo se realiza la planificación de release?

Actualmente estoy diseñando la planificación de release para una compañía que tiene un plan estratégico de transformación ágil. Para ello me he basado en una serie de prácticas usuales en Agilidad y en otras que son directas de Scrum, diseño que quiero compartir en este post.

La planificación de release se encuentra en el tercer nivel de la planificación ágil y consta de dos partes, la obtención inicial de un proceso de negocio (Value Stream Mapping), de una pila de producto (User Story Workshop), con una estimación inicial, y la replanificación de la misma (User Story Refinement) cuando esta se refina y reestima, evento que ocurre con la misma frecuencia que los sprints. El ciclo de los eventos de la planificación se muestra en la siguiente figura:

Ciclo de eventos de la planificación de release

Recordemos que por encima de la planificación de release tenemos la hoja de ruta del producto, y cuando se toma la decisión de abordar una nueva etapa, se ha de desgranarla en sus flujos de valor (procesos de negocio) y efectuar el User Story Workshop para obtener una primera proyección a futuro del producto. Periódicamente, usualmente una vez por sprint, se efectúa el User Story Refinement que tratará los cambios acaecidos, permitirá replanificar y ajustar la proyección a futuro manteniendo el proyecto lo más cercano posible a la realidad.

User Story Workshop

Obtenidos los diferentes flujos de valor a través de talleres Value Stream Mapping, se realiza un User Story Mapping sobre cada uno de los procesos desde los diferentes puntos de vista de quienes interactúan con el sistema (es muy útil hacer una User-Persona de estos para establecer empatía con los mismos). Asisten a este evento, liderado por el Propietario del Producto, quienes conocen el negocio, entre ellos usuarios, así como parte o todo el equipo de desarrollo. Las actividades y conversaciones que se producen tienen un gran beneficio porque abren canales de comunicación entre las personas de negocio y tecnología.

Tableros User Story Mapping y Release Planning de ejemplo

En la imagen se ve un ejemplo que representa un proceso de venta desde el punto de vista del cliente que compra un libro por la web, punto 1. En un carril del tablero, marcado con un 2, se desglosa el proceso en sus pasos y en la zona 3 se desarrolla cada paso en sus funcionalidades en forma de epics e historias de usuario. 

Habiendo obtenido los elementos de la pila de producto, estos se trasladan al tablero de Release Planning, flecha 4, priorizando las historias de usuario en función de la release de la que se pretende que formen parte (carril 5 y sucesivos). Resaltar que con esta actividad se está planificando la ejecución del proyecto en forma de entregas, a diferencia de como se suele concebir ejecuciones de proyectos en cascada que suelen ser en capas horizontales pensadas para construir el proyecto de inicio a fin o entre hitos.

En caso de múltiples flujos de valor se realiza un User Story Mapping independiente para cada proceso, sus historias de usuario y epics se trasladan y consolidan después en un solo tablero de Release Planning.

Varios procesos de negocio requieren cada uno su tablero para User Story Mapping correspondiente

El siguiente paso consiste en la colorización que trata de la añadidura de historias técnicas por parte del equipo. Muy posiblemente la primera release requiera preparar un entorno de producción, arquitectura... historias sin las que sería imposible que funcionara el software construido. El término colorización viene de la idea de utilizar colores distintos en los post-its para historias de usuario e historias técnicas.

Juntando las diferentes historias de usuario de los diferentes flujos de valor, y también las de la pila de producto, si esta existiera, se obtiene la pila de producto actualizada y priorizada por releases. Es el momento de estimar hasta donde sea posible, probablemente todas las historias de usuario hasta donde aparezcan las funcionalidades en forma de epics. La estimación la debe de realizar el equipo en la unidad de tamaño establecida y en la que se mide la velocidad (puntos de historia, horas ideales...)

A partir de aquí el Propietario del Producto realiza el gráfico de producto o gráfico "burnup", esta es su herramienta de planificación por excelencia y que presenta visualmente la evolución previsible del producto, proyectando en base a la velocidad del equipo y en el tiempo la construcción del producto. Este toma a continuación la pila de producto con las releases previstas, en el caso del ejemplo tiene previsto lanzar la versión 1.0 cuando disponga de las cuatro primeras historias, que tienen un esfuerzo estimado de 950 puntos (150+250+250+300):

Pila de producto con releases, cortesía de Scrum Manager

Para trazar la previsión, este sitúa cada versión en el eje vertical en la posición correspondiente al esfuerzo estimado para construir todas las historias que incluye. Los puntos de corte que marca esta posición con las líneas de velocidad del equipo (pesimista, realista y optimista) proyectan en el eje horizontal la fecha o sprint en el que se completará la versión. Finalmente el Propietario del Producto habrá obtenido el "burnup" o gráfico de producto que proyecta de la forma más realista posible la construcción del software:

"Burnup" o gráfico de producto, cortesía de Scrum Manager

Para poder explicar fácilmente lo que se va a crear en la siguiente release y para cuando se tiene previsto que estará lista se puede utilizar el siguiente patrón:

LA <nombre de la release>

QUE ESTA PREVISTA PARA EL <fecha prevista de la release>

Y SE CARACTERIZA PRINCIPALMENTE POR <característica principal>

PERMITIRÁ A <beneficiario principal>

LOGRAR <beneficio obtenido>

User Story Refinement

La pila de producto es un documento vivo, posiblemente varíe de sprint en sprint, o bien porque el cliente haya madurado y concrete sus necesidades a medida que tomen importancia, o bien porque este debe de adaptarse a variaciones en su negocio y a las oportunidades de mercado. Por tanto el "burnup" o gráfico de producto, también es un documento vivo cuya evolución preestablece la del producto. Como herramienta ágil no debe considerarse para representar planes estables, sino las previsiones tras cada evolución de la pila de producto. 

Este evento suele producirse a mitad de cada sprint, en este el Propietario del Producto presenta al equipo las variaciones, la repriorización y los posibles desgloses de epics en historias de usuario. El equipo debe de reestimar la pila de producto hasta dónde sea posible y así el Propietario de Producto podrá realizar el gráfico de producto o gráfico "burnup" actualizado, que representará una proyección realista de ese momento.

Se puede complementar la planificación de release con un tablero para irradiar la información y reforzar la visibilidad y transparencia, como la imagen que sigue con un ejemplo. Es importante resaltar a todos los interesados que el tablero refleja la situación actual y que variará a medida que se avance en el proyecto.

Tablero Release Planning, gracias Alberto

Cierro con una frase de Mike Beedle:

"Quién predice sin medir, se equivocará"