Una buena planificación es fundamental para el éxito.

Mucha gente piensa que en agile no se planifica, lo cual es rotundamente falso: no se planifica en detalle a largo plazo (como hacen p.ej. los famosos Diagramas de Gantt que casi nunca se cumplen), pero sí se planifica en detalle a corto y medio plazo, y alto nivel a largo plazo con los Roadmaps.

Este artículo desglosa en detalle las funciones, similitudes y diferencias entre PI Planning y Sprint Planning.

Entendiendo PI Planning y Sprint Planning

Vamos a explorar que son y como funcionan ambos eventos.

¿Qué es PI Planning?

El ‘PI Planning’ (traducido, ‘Planificación de Incremento de Programa’) es una piedra angular del marco de trabajo SAFe (Scaled Agile Framework).

Es un evento de planificación que reúne durante dos días completos donde se reúnen todos los integrantes de todos los equipos que componen un tren (Agile Release Train, también conocido por sus siglas: ART).

Sirve para alinear objetivos y planificar sus entregables del siguiente Program Increment, o sea para las próximas 8 a 12 semanas. Este evento es crucial para garantizar que todos los equipos estén alineados y sincronizados.

Fundamentos del Sprint Planning

El Sprint Planning es una de las 4 ceremonias o eventos clave en la metodología Scrum, la más usada y conocida con diferencia de las que forman parte del mindset Agile. Este evento marca el inicio de cada sprint, que típicamente dura entre dos y cuatro semanas.

Durante el Sprint Planning, el equipo de desarrollo, junto con el Product Owner y el Scrum Master(como “facilitador”), selecciona las historias de usuario o elementos del Product Backlog que se compromete como equipo a completar durante el sprint.

En el Sprint Planning el equipo debe plasmar claramente el objetivo del sprint y un plan para alcanzarlo. Como buena práctica primero se definiría el Objetivo del Sprint y posteriormente se seleccionarían los PBI (Product Backlog Item) que permitirán a priori alcanzar ese objetivo.

Duración y Ciclos en Agile Sprints

La elección de la duración de los sprints en Agile tiene una gran influencia en cómo trabajará el equipo.

El objetivo es elegir la duración más corta posible, porque eso permite a los equipos adaptarse rápidamente a los cambios en las necesidades del cliente, manteniendo el foco en la creación frecuente de valor. Sin embargo, una duración demasiado corta obliga al equipo a ser capaz de “romper” o desglosar las historias de usuario en historias más pequeñas que a pesar de ser pequeñas aporten valor por sí mismas y sean un entregable real que se pueda mostrar para recabar feedback en el Sprint Review. Este desglose de historias en otras más pequeñas no siempre es fácil o incluso no siempre es factible, esa es la razón por la que no siempre se elige la duración de Sprint más corta. También puede suceder que en Sprints “demasiado cortos” el equipo no tenga la capacidad de entregar nada, pero esto ya lo hablaremos en otro momento.

¿De qué duraciones estamos hablando, qué es una duración corta o larga?

Según el Manifiesto Agile dice en su tercer principio “Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible”. Scrum en la guía Scrum lo acota más, ya que prescribe sprints “de un mes o menos”.

Por todo ello, lo más común es que los sprints duren de dos a cuatro semanas. Pero lo común no tiene que ser lo mejor para todos los equipos.

La naturaleza iterativa de los sprints facilita la mejora continua, el aprendizaje y la adaptación, características esenciales de Agile.

Diferencias Clave entre PI Planning y Sprint Planning

Ambos son eventos de planificación en marcos Agile, pero tienen diferencias clave.

No son eventos excluyentes sino complementarios:

• si estamos en un equipo “aislado”, haremos Sprint Planning.
• si ese equipo no está aislado, sino que forma parte de un tren, haremos también PI Planning, adicionalmente.

Enfoque Estratégico vs. Enfoque Táctico (ver artículo)

El PI Planning (Planificación de Incremento de Programa) en SAFe es el evento de planificación del tren, siendo este un equipo de equipos, para el siguiente periodo de 8-12 semanas.

Es una planificación focalizada en alinear los equipos en torno a una visión y unos objetivos comunes, y es de alto nivel, no se baja al detalle. Tiene por tanto un enfoque estratégico.

Por otro lado, el Sprint Planning se realiza al comienzo de cada sprint, que suele durar de 2 a 4 semanas.

En este evento, el equipo detalla el objetivo de ese sprint, y el trabajo (las historias de usuario) que terminará durante el mismo, basándose en las estimaciones y prioridades del Product Backlog, y en la capacidad del equipo. Es una planificación de detalle, más táctica que estratégica.

Escala y Alcance de la Planificación

La escala y el alcance de la planificación difieren considerablemente entre PI Planning y Sprint Planning.

PI Planning se realiza a un nivel más alto, involucrando a varios equipos (en algunos casos eso puede suponer toda la organización), lo que facilita una visión global y coordinada del proyecto. Esta planificación incluye conversaciones sobre dependencias entre equipos, riesgos potenciales y estrategias para su mitigación, lo que requiere una visión amplia y a largo plazo. Normalmente se habla de entregables.

En contraste, el Sprint Planning se centra en un solo equipo y su trabajo inminente. Su alcance está limitado al siguiente sprint, con el objetivo de definir entregables específicos. Este nivel de detalle y enfoque inmediato ayuda a los equipos a responder rápidamente a los cambios. Normalmente se habla de PBIs.

Involucramiento del Equipo y Roles

El involucramiento del equipo y los roles también son diferentes entre ambos eventos.

En el PI Planning, la participación es amplia, incluyendo a todos los miembros del Agile Release Train (ART), líderes de negocio y stakeholders. Este enfoque colaborativo garantiza que todas las partes interesadas tengan voz en la planificación y estén comprometidas con los objetivos.

En cambio, el Sprint Planning implica solo al equipo Scrum: el Product Owner, el Scrum Master y el equipo de desarrollo. Si bien es cierto, que en algunas ocasiones pueden participar personas de otros equipos en calidad de expertos para dar soporte al equipo. Esta reunión se centra en el compromiso del equipo para alcanzar un objetivo durante el siguiente sprint.

Integrando PI Planning y Sprint Planning en Agile

Como hemos comentado, ambos eventos no son excluyentes, todo lo contrario son complementarios!

Cómo Complementan PI Planning y Sprint Planning tu Metodología Agile

El PI Planning, o Planificación de Incremento de Programa, es una estrategia de alto nivel que permite a múltiples equipos que trabajan en el mismo producto/solución alinear sus esfuerzos y objetivos para los próximos meses. Se centra en establecer una visión y planificación compartida y en identificar riesgos y dependencias inter-equipos temprano en el proceso. Este enfoque estratégico es crucial para productos grandes y complejos, donde la cohesión y colaboración  entre múltiples equipos es esencial.

Por otro lado, el Sprint Planning se ocupa de la planificación táctica a corto plazo. Cada sprint, que suele durar de dos a cuatro semanas, comienza con una sesión de planificación donde el equipo fija un objetivo y selecciona del backlog las historias de usuario que se compromete a completar. Este proceso garantiza que el equipo se mantenga enfocado y adaptable, con metas claras y alcanzables que se ajustan a la estrategia más amplia establecida durante el PI Planning.

Juntos, PI Planning y Sprint Planning crean un marco de trabajo robusto que combina visión estratégica a largo plazo con agilidad operativa a corto plazo.

Esta dualidad permite perseguir grandes objetivos estratégicos sin perder la rápida adaptación a los cambios del mercado.

Casos de Uso: Cuándo Utilizar PI Planning sobre Sprint Planning

Ante todo hay que recordar que no son eventos excluyentes sino complementarios: si estamos en un equipo “aislado”, haremos Sprint Planning y no PI Planning. Si ese equipo no está aislado sino que forma parte de un equipo de equipos, haremos ambos eventos de planificación.

Un equipo Scrum tiene por definición un máximo de 11 integrantes, incluyendo PO y Scrum Master. Cuando el producto/solución es más complejo, y son necesarias muchas más personas. SAFe propone en su marco de trabajo crear un nivel superior, el tren o equipo de equipos, con sus propios eventos y roles, y lo propone para casos de mínimo 50 personas aproximadamente.

La elección es un tema de la complejidad a gestionar.

Por tanto, en Agile, concretamente en Scrum, seguramente siempre haremos Sprint Plannings para planificar cada sprint. No vamos a añadir complejidad innecesaria. Y si el producto/solución es tan grande como para requerir 50 personas o más, escalaremos Agile usando el recurso  de SAFe, y por tanto agregaremos nuevos eventos como el PI Planning.

Maximizando la eficacia en la planificación Agile

Te ofrecemos algunas estrategias clave para optimizar ambos eventos de planificación.

Mejores Prácticas para PI Planning

• Preparación: Antes de un PI Planning, el RTE como facilitador del mismo debe asegurarse de que el PM tenga listos los 2 inputs del mismo: la Visión y el ART Backlog priorizado (al menos sus elementos más prioritarios, aprox. los 10 primeros). También debe preparar y comunicar bien las herramientas de trabajo colaborativo (p.ej. Miro, Teams, Zoom, etc), poniéndose en el lugar de un integrante nuevo del tren para asegurarse de que no le asaltarán dudas del proceso durante el propio PI Planning, lo cual ralentizaría al resto del tren.
• Objetivos claros: Establece objetivos claros y alcanzables para el PI.
• Comunicación efectiva: Fomenta un ambiente abierto donde todos los miembros compartan ideas, preocupaciones y soluciones.
• Revisión y ajuste: Al final del PI Planning, haz un voto de confianza de todos los integrantes del tren y ajusta según sea necesario para asegurar que los objetivos sean ambiciosos pero alcanzables.

Consejos para un Sprint Planning Efectivo

• Priorización del backlog: el Product Owner es responsable de que el Backlog esté frecuentemente actualizado y priorizado; lo ideal es que haga este Refinamiento apoyándose en el equipo.
• Objetivo del sprint: el equipo, tras seleccionar las historias que terminará en el sprint, debe consensuar un objetivo del sprint, que escribirá en un lugar muy visible, en aras de la transparencia y el alineamiento entre sus integrantes.
• Claridad en el trabajo a realizar: cada historia de usuario debe tener criterios de aceptación claros y ser entendida por todos los miembros del equipo, para evitar ambigüedades o malentendidos acerca de cuándo estará terminada.

Herramientas software para apoyar ambas planificaciones

Algunas herramientas software recomendadas para facilitar y optimizar la planificación son:

• Miro: es una pizarra electrónica, un lienzo infinito sobre el que realizar todo tipo de tablas, diagramas, post-its. Es la mejor pizarra electrónica por funcionalidades y facilidad de uso.
• JIRA: un software de gestión de proyectos totalmente orientado a agile y totalmente personalizable.
• Confluence: es una Wiki, ideal para documentar los resultados del PI Planning; está fuertemente integrado con Jira (está desarrollado por la misma empresa, Atlassian).
• Trello: es una herramienta muy visual y simple para gestionar proyectos y tareas. Trello puede ser especialmente útil para equipos pequeños.
• Microsoft Teams o Slack: son plataformas de comunicación integrables con muchas otras herramientas; son esenciales para mantener a los equipos conectados, especialmente en entornos de trabajo remoto.