SAFe aplicado 2: PI Planning en SAFe. Cómo alinear equipos y stakeholders en un plan común

En este segundo post veremos en profundidad el PI Planning, el evento que inicia el trabajo coordinado del ART y marca el inicio de un ciclo de trabajo con un verdadero propósito colectivo. Veremos cómo los Business Owners y el Product Manager presentan la visión de negocio y producto, cómo el System Architect establece la dirección técnica, y cómo el RTE facilita la interacción y el intercambio de puntos críticos entre equipos. Analizaremos los métodos para visualizar dependencias, gestionar riesgos y consensuar objetivos mediante artefactos como el Program Board y los PI Objectives, ente otros.

PI PLANNING, ALINEAR A TODOS LOS EQUIPOS EN UN PLAN COMÚN

El PI Planning es el evento central de la organización del trabajo en un ART. Es un evento de dos días (por lo general), presencial o virtual, que da inicio a cada Program Increment. Todos los miembros vinculados al ART participan: todos los equipos (con sus Product Owners y Scrum Masters), el Product Manager, el Release Train Engineer (RTE), el System Architect, los Business Owners y otros stakeholders. El objetivo es alinear qué entregará el ART en el próximo PI, comprometerse con objetivos compartidos y hacer visibles y planificar las dependencias y riesgos.

CÓMO LOS PRINCIPALES ROLES CONTRIBUYEN DURANTE EL PI PLANNING

Business Owners y Stakeholders:
El PI Planning suele comenzar con una presentación del contexto a cargo de los stakeholders senior. Un Business Owner o ejecutivo presenta el Business Context: la visión general, los temas estratégicos y los hitos o plazos regulatorios que enmarcan este PI. Esto ayuda a todos los equipos a entender por qué el trabajo es importante. Durante toda la planificación, los Business Owners permanecen disponibles para responder preguntas y aclarar prioridades. Su presencia demuestra la importancia que el trabajo del tren tiene para la organización.

Product Manager:
El Product Manager presenta la Product Vision y las Top Features para el PI. Puede compartir una breve declaración de visión o una hoja de ruta que muestre hacia dónde se dirige el producto, y luego repasar las Features de alta prioridad del Program Backlog que deben entregarse para hacer realidad esa visión. Por lo general, el PM destaca unas diez features principales (a veces llamada “lista de las 10 principales features” que se usa como insumo para el PI Planning) junto con el valor de negocio que se espera que cada una entregue. Explica el contexto de cada feature y cualquier insight relevante del cliente para que los equipos comprendan qué se está pidiendo. Esto establece la base de contenido para la planificación. (En un entorno remoto, el PM puede usar una pizarra en Miro o diapositivas para mostrar cada feature, a menudo con enlaces a Jira o Rally donde la feature está descrita en detalle).

System Architect/Engineering:
Después de la visión, el System Architect suele presentar la charla sobre Architectural Vision y Development Practices. Esto cubre cualquier cambio en la estrategia tecnológica, el runway de arquitectura o las guías técnicas que los equipos deben tener en cuenta al planificar. Por ejemplo, el arquitecto puede repasar los enablers arquitectónicos próximos (trabajo de infraestructura, refactorizaciones, actualizaciones de seguridad, etc.) que están planificados para este PI o nuevos estándares técnicos (como un nuevo diseño de API) que los equipos deben cumplir. El arquitecto garantiza que los problemas técnicos transversales se identifiquen desde el principio. También puede señalar dónde los equipos necesitan colaborar en historias de tipo enabler. Esta presentación ayuda a los equipos a planificar teniendo en cuenta las consideraciones técnicas.

Release Train Engineer (RTE):
El RTE facilita el evento de PI Planning de principio a fin. Inicia el Día 1 presentando la agenda y los ponentes (Business Owners, PM, System Architect) y establece el tono y las reglas básicas. Una vez compartido el contexto y la visión, el RTE coordina la transición a las sesiones de trabajo por equipos. Durante los breakouts, el RTE se encarga de controlar los tiempos (por ejemplo, asegurándose de que los equipos tengan programada la revisión del plan preliminar, etc.), circular entre los equipos para ayudar a resolver problemas o dependencias y convocar reuniones improvisadas de tipo Scrum of Scrums si varios equipos se encuentran con una dependencia que requiere discusión. En esencia, el RTE es el coordinador principal: se asegura de que los equipos se comuniquen cuando es necesario, facilita la resolución de dependencias y mantiene la energía del evento. El RTE también facilita la Management Review al final del Día 1 (donde la dirección analiza ajustes si el alcance no cumple los objetivos del negocio) y lidera las actividades del Día 2: revisiones finales de los planes, análisis de riesgos mediante la técnica ROAM (Resolve, Own, Accept, Mitigate), la Confidence Vote y la retrospectiva final de planificación. Supervisa de cerca los tableros generales de planificación y de riesgos para garantizar que no se pase por alto nada crítico.

Agile Teams (Product Owners y Scrum Masters):
Después de las presentaciones iniciales, los equipos (desarrolladores y testers junto con sus POs y SMs) entran en las sesiones de trabajo para crear sus planes. Cada equipo toma las features que se presentaron (normalmente cada feature se asigna a un equipo específico o se divide entre algunos) y las descompone en user stories y tareas que el equipo pueda entregar durante sus iteraciones. El Product Owner lidera la descomposición de las stories, asegurándose de que el equipo entienda los criterios de aceptación de cada feature y las divida en historias manejables. Estas historias se añaden al Team Backlog (a menudo en Jira o Rally) y se priorizan por iteración. El PO también identifica cualquier dependencia: por ejemplo, si el Equipo A necesita una API del Equipo B para entregar una historia, el PO marcará esa dependencia y probablemente coordinará con el PO del otro equipo durante la planificación.
El Scrum Master facilita la sesión de trabajo de su equipo: mantiene el foco en las estimaciones y en una planificación realista, controla el tiempo y garantiza que, si el equipo se bloquea por una dependencia externa, se escale el tema (quizá al RTE o directamente al SM del otro equipo). El Scrum Master también puede encargarse del tablero de planificación (en la pared o en una pizarra digital), colocando las historias en las iteraciones y dibujando líneas o conectores hacia las historias de otros equipos donde existan dependencias.

Gestión de Dependencias y Riesgos:
Una parte fundamental del PI Planning es hacer visibles todas las dependencias entre equipos. A medida que planifican, cada vez que los equipos descubren una dependencia con otro, ambos la marcan en el Program Board: un gran tablero visual (físico o en Miro) que muestra la línea temporal de iteraciones para el PI y qué equipo entregará qué feature, con cuerdas o líneas conectando el trabajo dependiente. Por ejemplo, si la feature del Equipo 1 no puede completarse hasta que el Equipo 2 entregue un componente en el sprint 2, eso se indica en el Program Board entre los ítems de ambos equipos. El RTE y los SMs suelen recorrer la sala (o las salas virtuales) para asegurarse de que las dependencias se estén identificando y anotando. Todos los riesgos identificados también se registran (a menudo en un rotafolio o documento compartido) para tratarlos más adelante. El RTE facilita luego una revisión de riesgos, donde se discute y clasifica cada riesgo según el modelo ROAM: Resuelto (Resolved), Asignado (Owned), Aceptado (Accepted) o Mitigado (Mitigated). Esta discusión abierta de riesgos a nivel de programa garantiza que no haya sorpresas más adelante y que existan planes de mitigación para los problemas principales.

Revisión de Planes en Borrador:
A mitad de la planificación (normalmente al final del Día 1), los equipos presentan sus planes preliminares al resto del tren. El RTE facilita estas revisiones equipo por equipo. El Product Owner (o un representante) resume lo que el equipo planea entregar, normalmente enumerando sus PI Objectives (los resultados clave que pretende lograr) y los principales hitos o dependencias. También menciona riesgos o inquietudes (por ejemplo: “tenemos una dependencia con el Equipo X en la Iteración 2 que aún no está confirmada”). Los Business Owners y otros equipos escuchan y pueden hacer preguntas u ofrecer ayuda. Esta sesión ayuda a asegurar la alineación de los planes y expone los problemas de manera temprana. Si algo importante no encaja, por ejemplo, si el plan de un equipo no cumple una feature crítica, los Business Owners y el Product Manager pueden pedir ajustes (lo que podría implicar cambios de alcance o reasignar trabajo entre equipos en el Día 2). El RTE, el Product Manager y el System Architect suelen reunirse después del Día 1 para discutir estos planes preliminares y decidir si se necesitan replanificaciones o compromisos para el Día 2.

Finalización de los PI Objectives y Valor de Negocio:
En el Día 2, los equipos incorporan cualquier feedback de la dirección y finalizan sus PI Objectives. Cada objetivo de PI es una meta concreta (a menudo formulada como un resultado o una declaración de valor) a la que el equipo se compromete para el PI, por ejemplo: “Mejorar el rendimiento del checkout en un 20 %” o “Entregar la Feature X para el grupo de clientes Y”. El Product Owner se asegura de que los objetivos estén redactados con claridad (no solo enumerando features, sino expresando el propósito de esas features). Luego, los Business Owners revisan los objetivos de cada equipo y asignan una calificación de Business Value (generalmente del 1 al 10) para cada objetivo, reflejando su importancia para el negocio. Esta colaboración es fundamental: alinea al equipo y al negocio en lo que significa el éxito. Los Business Owners literalmente otorgan una puntuación que indica cuánto valoran cada objetivo, lo que ayuda a los equipos a priorizar en caso de conflictos durante la ejecución. También proporciona una manera de medir, al final del PI, cuánto del valor previsto se entregó realmente.

Confidence Vote:
Finalmente, el RTE facilita una votación de confianza tipo “fist of five” con todos los participantes para medir la confianza general en cumplir los PI Objectives. Cada persona (miembro del equipo o stakeholder) califica su confianza del 1 (sin confianza) al 5 (muy alta confianza). Si la confianza promedio es baja (o si muchas personas votan 1 o 2), el RTE inicia una discusión abierta para entender las preocupaciones, y los equipos pueden ajustar los planes o compromisos hasta alcanzar un nivel razonable de confianza. Esta actividad fomenta la honestidad y genera confianza en que los equipos no están sobrecomprometiéndose. Solo cuando el tren alcanza consenso y los Business Owners aprueban, el plan del PI se considera comprometido.

Resultado del PI Planning:
Al finalizar el PI Planning, el ART sale con tres artefactos clave:

1. Un conjunto de PI Objectives por equipo (y consolidados a nivel de programa) con los que todos están alineados.

2. Un Program Board que muestra todas las features y dependencias programadas para el PI.

3. Una lista de riesgos identificados junto con la forma en que se manejarán.

Los equipos también tienen sus planes de iteración detallados para los primeros uno o dos sprints (las iteraciones posteriores pueden planificarse a alto nivel y revisarse más adelante). Toda esta información suele registrarse en herramientas: por ejemplo, los backlogs de los equipos (user stories) se introducen en Jira o Rally, el program board y los objetivos se documentan en Jira Align o Confluence, y las notas o decisiones se guardan en documentos compartidos. El RTE se asegura de que cualquier salida física de la planificación (notas adhesivas, cuerdas en tableros, etc.) se transcriba a formato digital para referencia continua si se trabajó con material físico. En este punto, el ART tiene una misión compartida para el PI y está listo para ejecutar.

Un ejemplo de Program Board de una sesión de PI Planning (en una pizarra digital). Cada tarjeta representa una Feature (extraída del Program Backlog) programada en una iteración específica para un equipo determinado, y las líneas o conexiones visualizan las dependencias entre los trabajos de los equipos.
Este gran tablero visible se crea durante el PI Planning para que todos puedan ver de un vistazo las dependencias entre equipos.

A la derecha se muestra un resumen de la Confidence Vote (votación de confianza) de los equipos sobre sus PI Objectives. Después de la planificación, los miembros de los equipos y los stakeholders votan su nivel de confianza en cumplir los objetivos; si la confianza es baja, el ART aborda esas preocupaciones antes de comprometerse formalmente.

Estos tableros visuales, ya sean físicos o digitales mediante herramientas como Miro, ayudan al RTE y a los equipos a garantizar la alineación y a resolver problemas antes de que comience la ejecución.

Tras el compromiso generado en el PI Planning, el ART está listo para poner en marcha sus planes y traducir los objetivos y dependencias identificadas en entregables concretos. La ejecución será el terreno donde se pondrán a prueba la colaboración, la adaptabilidad y el seguimiento continuo, asegurando que el progreso no solo se mantenga sino que responda de manera ágil a los cambios.

En el siguiente post veremos cómo los equipos trabajan iterativamente, gestionan el avance y la información relevante, ajustando el rumbo cuando surgen nuevos retos y oportunidades.

POSTS DE LA SERIE SAFe APLICADO

1. Organiza tu SAFe ART paso a paso: roles, preparación y claves de éxito

2. PI Planning en SAFe: cómo alinear equipos y stakeholders en un plan común

3. Ejecución eficiente de un Program Increment: gestión, seguimiento y comunicación en SAFe

4. Inspect & Adapt en SAFe: mejora continua y retrospectiva efectiva de ARTs

5. Artefactos y herramientas SAFe: claves para la alineación y transparencia en equipos ágiles

6. Checklist definitivo y recapitulación: cómo sobrevivir y triunfar en tu primer PI SAFe