¿Cómo es una agenda y el juego de tableros para una Pre-PI Planning?

Solution Train, del tema Solution Train cortesía de © Scaled Agile, Inc.

En este post quiero compartiros como ejecutamos las Pre-PI Plannings en nuestro contexto de un Solution Train con nueve trenes (ARTs). SAFe® nos da una guía muy general sobre este evento ya que, dada complejidad a este nivel, cada organización ha de encontrar su solución, siempre alineada con los 10 principios.

Recordemos que la Pre-PI Planning ayuda a construir un plan alineado entre ARTs para el próximo PI, adaptando la demanda de la solución a las capacidades de los ARTs individuales. También es la ocasión ideal para identificar dependencias, para aclarar qué ART necesita qué de quién y para cuando. Alinea a los Product Managers, arquitectos de sistemas y otras partes interesadas de los trenes (ARTs) alrededor de una visión común. Su objetivo principal es:

• Informar sobre los resultados de las planificaciones e iniciativas de negocio
• Informar sobre la visión y habilitadores (enablers) del Solution Train
• Discutir objetivos derivados del Solution Train
• Aclarar dependencias y su manejo para el siguiente PI
• Alinear las prioridades del Solution Train para el próximo PI

La agenda que nosotros manejamos es como sigue:

7:30 a 8:00 - Bienvenida

El momento ideal para una taza de café y socializar :-)

8:00 a 10:00 - Contexto de negocio y visión del Solution Train

• El CEO o ejecutivo senior describe el estado actual de la empresa, comparte la visión empresarial y presenta el estado actual de la solución y el portfolio
• STE presenta:
  • Resultados de la ejecución del PI anterior
  • Resultados de la Solution Demo
  • Agregación de las medidas de predictibidad a nivel de solución
• Solution Managment presenta la visión actual de la solución
• El Solution Architect proporciona la cantidad justa de orientación de arquitectura y experiencia del usuario

10:00 a 10:45 - Solution Backlog

El Solution Manager, junto con los Product Managers, presentan las capabilities principales y les asignan ART para el próximo PI.

10:45 a 11:00 - Descanso

11:00 a 13:00 - Breakouts

Previamente a la Pre-PI Planning habremos efectuado un taller para identificar a grandes rasgos qué breakouts son necesarios. En éstos breakouts aquellos ARTs que tengan dependencias se reúnen para:

• Identificar, discutir, acordar, documentar dependencias significativas
• Rellenar el tablero de objetivos por ART

13:00 a 14:00 - Comida

14:00 a 15:00 - Revisión del Solution Planning Board

Product Management presenta los resultados de la planificación con foco principalmente en:

• Features clave
• Dependencias significativas
• Visiones de los ARTs actualizadas

15:00 a 15:45 - Identificación de objetivos principales

En base al Solution Planning Board identificamos los objetivos preliminares del Solution Train. Son preliminares ya que en Post-PI Planning confirmaremos o ajustaremos éstos objetivos en base a los resultados de las PI Plannings individuales.

15:45 a 16:39 - Cierre y retrospectiva

Cerramos con una retrospectiva para recoger feedback del evento, por ejemplo un tablero con "qué ha ido bien", "qué no ha ido bien" e "ideas".

Tablero Pre-PI Planning (Solution Planning del tema Pre- and Post-PI Planning cortesía de © Scaled Agile, Inc.)

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

¿Cómo entender la diferencia entre criterios de aceptación y definición de hecho?

Para considerar una historia terminada

Los que estamos familiarizados con la Agilidad sabemos que las cosas están terminadas o no terminadas, no hay término medio... un 99% terminado en esencia es NO terminado. Si tenemos cosas grandes las dividimos en partes menores de manera que cada una de ellas aporte valor, y éstas las vamos terminando al 100% para agregar valor de forma paulatina.

Esas cosas pequeñas las conocemos como historias de usuario. La manera de medir si están terminadas es utilizando los criterios de aceptación, que responden a la pregunta ¿cuál es comportamiento que ha de mostrar la historia de usuario específica?, y la definición de hecho (DoD), que responde a ¿qué tiene que cumplir cualquier historia para que se considere terminada?

Definition of Done vs. Acceptance Criteria

Los criterios de aceptación describen comportamientos que hace el producto cuando se complete la historia de usuario, por tanto no son cosas que el equipo de desarrollo haga sobre producto. La definición de hecho es un conjunto de actividades obligatorias que el equipo ha de efectuar para cada historia de usuario.

La imagen de la derecha, que inicialmente encontré en un post en LinkedIn, y que luego descubrí que proviene del artículo "Definition of Done vs. Acceptance Criteria" de Michael Küsters, arroja muchísima claridad sobre la diferencia entre criterios de aceptación y la definición de hecho.

	Criterio de aceptación	Definición de hecho
Describe...	lo que el producto hace	lo que el equipo hace
Calidad del...	producto desde el punto de vista del usuario	trabajo desde la perspectiva del proceso
Aplica a...	a una historia de usuario específica	generalmente a todos los elementos de la pila de producto
Se cumple cuando...	se verifica los test	acuerdo del equipo