Saltar a contenido

PI Planning: qué es y cómo se ejecuta la planificación en SAFe

Ilustración de PI Planning

El PI Planning (Program Increment Planning) es el evento central de SAFe. Cada 8-12 semanas, todos los miembros del Agile Release Train —entre 50 y 125 personas— se reúnen para planificar el próximo incremento. Es un evento de 2 días que requiere preparación, ejecución y seguimiento. El PI Planning es donde la estrategia se convierte en planes concretos y donde 5 a 12 equipos se alinean, identifican dependencias y se comprometen colectivamente con objetivos comunes.

¿Por qué el PI Planning es tan importante?

El PI Planning no es una reunión más. Es el evento donde ocurre la magia de SAFe. En un solo evento, se logra:

  • Alineación: todos los equipos entienden hacia dónde va el producto y por qué
  • Planificación colaborativa: las dependencias se identifican y gestionan antes de empezar a construir
  • Compromiso colectivo: los equipos se comprometen con objetivos realistas, no impuestos desde arriba
  • Transparencia total: toda la organización ve lo que se va a construir y cuándo
  • Conexión estrategia-ejecución: los Business Owners ven cómo sus inversiones se traducen en trabajo concreto

Ejemplo práctico: Un ART de banca con 7 equipos (80 personas) se reúne para su PI Planning del Q3. El Product Manager presenta la visión: "Vamos a lanzar la funcionalidad de apertura de cuenta 100% digital". Durante el día 1, los equipos planifican sus iteraciones y descubren que el equipo de identificación digital necesita que el equipo de core bancario exponga una API que actualmente no existe. Sin el PI Planning, este descubrimiento habría ocurrido 4 semanas después, cuando el equipo de identificación estuviera bloqueado. En el PI Planning, se identifican el día 1 y se planifica la solución.

Preparación previa al PI Planning

Un PI Planning exitoso comienza 2-3 semanas antes del evento. La preparación incluye:

  1. El RTE prepara la logística: reserva el espacio, prepara las herramientas (físicas o virtuales), coordina los materiales
  2. El Product Manager prepara el Program Backlog: features priorizadas con WSJF, lista de objetivos del PI
  3. Los Business Owners preparan el business context: tendencias del mercado, métricas del PI anterior, prioridades estratégicas
  4. El System Architect prepara la visión arquitectónica: decisiones técnicas, enablers, estándares
  5. Los Product Owners preparan los team backlogs: historias preliminares basadas en las features propuestas

Agenda típica de 2 días

Día 1

Hora Actividad Descripción
8:00 - 8:30 Check-in y café Llegada, conexiones
8:30 - 9:30 Business Context Business Owners presentan el estado del negocio, métricas y prioridades estratégicas
9:30 - 10:30 Visión del producto Product Manager presenta la visión, las features propuestas y los objetivos del PI
10:30 - 11:00 Descanso Break
11:00 - 12:00 Arquitectura y Enablers System Architect presenta decisiones arquitectónicas y trabajo técnico planificado
12:00 - 13:00 Planificación por equipos (sesión 1) Los equipos se reúnen en breakout sessions para planificar sus primeras iteraciones
13:00 - 14:00 Comida Break
14:00 - 16:30 Planificación por equipos (sesión 2) Continúa la planificación. Los equipos identifican dependencias y las registran en el tablero de dependencias
16:30 - 17:30 Revisión de draft plans Cada equipo presenta su plan borrador. Se identifican riesgos y dependencias cruzadas
17:30 - 18:00 Ajustes basados en feedback Los equipos ajustan sus planes según el feedback recibido

Día 2

Hora Actividad Descripción
8:30 - 9:00 Check-in y retrospectiva del día 1 Breve retro para ajustar el día 2
9:00 - 10:30 Planificación (sesión 3) Equipos finalizan la planificación basada en ajustes y dependencias identificadas
10:30 - 11:00 Gestión de riesgos Revisión ROAM de todos los riesgos identificados
11:00 - 11:30 Descanso Break
11:30 - 13:00 Presentación de planes finales Cada equipo presenta su plan final: objetivos SMART, features planificadas por iteración, dependencias gestionadas
13:00 - 14:00 Comida Break
14:00 - 15:30 Compromiso del ART Votación de confianza (fist of five). Si hay equipos con confianza baja (< 3), se discuten los problemas
15:30 - 16:30 Plan de riesgos Asignación de dueños a riesgos no resueltos
16:30 - 17:00 Cierre Business Owners validan y aceptan el plan. Próximos pasos.

La técnica ROAM para riesgos

Durante el PI Planning, los riesgos se identifican y clasifican usando la técnica ROAM:

  • Resolved: El riesgo se resolvió durante el PI Planning. Por ejemplo, "Necesitamos acceso a la API de core bancario" se resuelve cuando el arquitecto confirma que el equipo de core ya tiene esa API planificada.
  • Owned: Alguien asume la responsabilidad de gestionar el riesgo. "No sabemos si el proveedor externo de identificación digital cumplirá los tiempos" — el RTE asume el seguimiento.
  • Accepted: Se acepta como riesgo asumido. Es un riesgo que el equipo decide aceptar conscientemente porque la probabilidad o el impacto es bajo.
  • Mitigated: Hay un plan de mitigación. "Si el proveedor no cumple, tenemos un plan B con un proveedor alternativo".

PI Planning presencial vs remoto

Aspecto Presencial Remoto
Energía y motivación Alta (el ambiente crea sinergia) Puede ser baja (fatiga de videollamadas)
Gestión de dependencias Natural (conversaciones espontáneas) Requiere herramientas específicas (Miro, Jira)
Participación Todos están presentes Riesgo de multitasking
Costo Alto (viajes, espacio, catering) Bajo (solo herramientas)
Duración 2 días completos 2-3 días (sesiones más cortas)
Breakout sessions Salas físicas paralelas Salas virtuales (Zoom, Teams)
Pizarras físicas Sí, muy efectivas Pizarras digitales (Miro, Mural)
Networking Alto Bajo

Desde la pandemia, muchas organizaciones han adoptado el PI Planning remoto con herramientas como Miro o Mural. La clave del éxito en remoto es: sesiones más cortas (no más de 90 minutos sin pausa), más breaks, y un facilitador dedicado por sala virtual.

Errores comunes en el PI Planning

  1. Preparación insuficiente: El Product Manager llega sin features bien definidas. Los equipos pasan el día 1 intentando entender qué deben construir.

  2. Equipos que no se conocen: Cuando los equipos no interactúan fuera del PI Planning, la identificación de dependencias es superficial. Fomenta que los equipos hablen entre sí durante el evento.

  3. Objetivos no SMART: "Mejorar la experiencia de usuario" no es un objetivo medible. "Reducir el tiempo de alta de usuario en un 30%" sí lo es.

  4. Business Owners ausentes: Si los Business Owners no están presentes, las decisiones sobre prioridades cambian durante el PI, y el plan se desmorona.

  5. Sobreplanificación: Intentar planificar cada historia de cada iteración del PI. El PI Planning planifica a nivel de features y objetivos. La planificación detallada de historias ocurre en el Sprint Planning de cada iteración.

  6. Votación de confianza sin consecuencias: Si un equipo vota 2 (confianza baja) y nadie investiga por qué, la votación pierde sentido.

Paso a paso para organizar tu primer PI Planning

  1. Fija la fecha con 6 semanas de antelación: Bloquea las agendas de 50-125 personas para 2 días completos.

  2. Prepara el contenido: El Product Manager debe tener el Program Backlog priorizado 2 semanas antes.

  3. Prepara la logística: Sala grande para plenarias, salas para cada equipo, pizarras, proyectores, catering.

  4. Comunica el propósito: Todos deben entender que no es una reunión informativa, sino una planificación colaborativa.

  5. Día 1: contexto + planificación: Sigue la agenda estándar. Los equipos planifican sus primeras iteraciones.

  6. Día 2: ajustes + compromiso: Finaliza planes, gestiona riesgos con ROAM, vota la confianza.

  7. Post-Pl: publica el plan: El RTE publica el plan del PI, los objetivos y los riesgos. Todos deben tener visibilidad del resultado.

¿Qué pasa si un equipo no logra comprometerse?

El "fist of five" es la herramienta de compromiso. Cuando un equipo presenta su plan, todos los miembros votan con los dedos:

  • 5 dedos: Totalmente comprometido, el plan es realista
  • 4 dedos: Comprometido, pero con pequeñas dudas
  • 3 dedos: Neutro, puede funcionar
  • 2 dedos: Preocupado, hay problemas que resolver
  • 1 dedo: No comprometido, el plan no es realista

Si hay votos de 1 o 2, el RTE debe investigar. Puede ser que el equipo tenga demasiado trabajo, que una dependencia no se haya resuelto o que falte claridad en los objetivos. Sea lo que sea, debe resolverse antes de cerrar el PI Planning.

Mi perspectiva personal sobre el PI Planning

He facilitado más de 20 PI Plannings y cada uno es diferente. El mejor consejo que puedo dar es: no sacrifiques la preparación. El 80% del éxito del PI Planning depende de lo que haces las 2-3 semanas antes, no de lo que haces durante los 2 días.

También he aprendido que el PI Planning es agotador. Dos días de planificación intensa con 80 personas dejan a cualquiera agotado. Es normal. Planifica un día de descanso después o al menos una mañana sin reuniones para que los equipos puedan procesar.

El PI Planning no es perfecto. Es caótico, ruidoso y a veces frustrante. Pero también es el evento donde la gente se alinea, donde las dependencias se descubren antes de que duelan y donde los equipos se comprometen con lo que van a construir. No hay otro evento en SAFe que genere tanto valor.