PI Planning : définition, déroulé et agenda
Le guide complet de l'événement clé de SAFe — et l'alternative légère quand PI Planning est trop lourd pour votre organisation.
Le PI Planning (Program Increment Planning) est l'événement central du framework SAFe : sur 2 jours, toutes les équipes d'un Agile Release Train planifient ensemble le prochain incrément de 8 à 12 semaines, identifient leurs dépendances et prennent un engagement collectif. C'est un rituel d'alignement puissant, mais lourd, qui opère au niveau des équipes — pas de la direction.
Qu'est-ce que le PI Planning ?
Le PI Planning, ou Program Increment Planning (planification par incrément de programme), est l'événement fondateur du framework SAFe (Scaled Agile Framework). Il réunit, en présentiel ou à distance, l'ensemble des équipes d'un Agile Release Train (ART) pour planifier le prochain Program Increment — une période de 8 à 12 semaines regroupant plusieurs sprints.
L'idée est simple : plutôt que de laisser chaque équipe planifier dans son coin, on réunit tout le monde au même moment, dans la même pièce (physique ou virtuelle), pour construire un plan partagé, visualiser les dépendances et s'engager collectivement sur des objectifs communs.
PI = Program Increment. C'est l'unité de planification de SAFe au niveau du train agile : typiquement 5 itérations (4 de développement + 1 d'innovation et de planification, dite « IP »).
À quoi sert le PI Planning ?
Le PI Planning poursuit quatre objectifs principaux :
- Aligner toutes les équipes sur une vision et des objectifs communs pour l'incrément à venir.
- Identifier les dépendances entre équipes et les rendre visibles (le fameux « program board »).
- Faire émerger les risques tôt et décider comment les traiter (ROAM : Resolved, Owned, Accepted, Mitigated).
- Obtenir un engagement collectif — matérialisé par un vote de confiance des équipes sur les objectifs du PI.
Le déroulé et l'agenda type d'un PI Planning
Un PI Planning classique s'étale sur 2 jours. Voici l'agenda de référence (pour le détail heure par heure, voir l'agenda PI Planning et les templates et program board) :
| Moment | Séquence | Objectif |
|---|---|---|
| Jour 1 — matin | Contexte business & vision produit | Le management présente le contexte, les priorités et la vision. |
| Jour 1 — matin | Contexte architecture & pratiques | L'architecte et le RTE cadrent les contraintes techniques. |
| Jour 1 — après-midi | Team breakouts (1er tour) | Chaque équipe estime sa capacité et ébauche son plan par itération. |
| Jour 1 — fin | Draft plan review & management review | Revue des plans, identification des problèmes, ajustements. |
| Jour 2 — matin | Ajustements du planning | Le management arbitre le périmètre et les priorités. |
| Jour 2 — matin | Team breakouts (2e tour) | Les équipes finalisent objectifs et dépendances. |
| Jour 2 — après-midi | Final plan review & vote de confiance | Présentation des plans finaux et engagement collectif (vote). |
| Jour 2 — fin | Rétrospective du PI Planning | Amélioration continue de l'événement lui-même. |
Les rôles clés
- Release Train Engineer (RTE) — le facilitateur en chef de l'événement.
- Product Management — porte la vision et priorise les features.
- Product Owners — déclinent les features en stories avec leurs équipes.
- Scrum Masters — facilitent les breakouts de chaque équipe.
- Business Owners — attribuent la valeur métier aux objectifs du PI.
- Équipes de développement — estiment, planifient et s'engagent.
Les limites du PI Planning
Le PI Planning est un rituel puissant… mais exigeant. Beaucoup d'organisations, en particulier les ETI, se heurtent à ses limites :
Il est lourd. Deux jours pleins, 50 à 125 personnes mobilisées : le coût organisationnel est considérable, tous les 8 à 12 semaines.
- Il suppose une maturité agile élevée — trains constitués, rôles SAFe en place, backlog mûr. Rare hors des grandes DSI déjà « scalées ».
- Il opère au niveau des équipes, pas de la direction. Il planifie comment livrer, mais n'arbitre pas ce qu'on devrait faire à l'échelle du portefeuille.
- Il peut devenir rigide — une grosse cérémonie qui tourne pour elle-même, déconnectée des vrais arbitrages business.
C'est le retour d'expérience de nombreux dirigeants : « On avait essayé SAFe, ça n'a pas marché. Trop lourd, trop de rôles, trop de cérémonies. »
L'alternative légère : le Quarter Plan
Si votre besoin n'est pas d'orchestrer un train agile mais de reprendre le contrôle de votre portefeuille au niveau direction, une approche plus légère existe : le Quarter Plan.
Là où le PI Planning synchronise des équipes de développement, le Quarter Plan installe une gouvernance d'exécution trimestrielle pour DG et DSI : on décide ce que l'organisation s'engage à livrer sur 90 jours, on arbitre par la capacité réelle, et on tient ses engagements — sans framework complexe ni certification.
Un trimestre = un engagement = un arbitrage assumé. Deux heures de COMEX par trimestre au lieu de deux jours de cérémonie tous les deux mois.
Pour comparer les deux approches en détail, voir : PI Planning vs Quarter Plan. Pour découvrir la méthode : la méthode Quarter Plan.
Pour aller plus loin
- Agenda PI Planning — le déroulé détaillé, heure par heure.
- Template & program board — les artefacts et outils à préparer.
- PI Planning vs Sprint Planning — les deux échelles de planification.
- PI Planning vs Quarter Plan — l'alternative légère au niveau direction.
Questions fréquentes sur le PI Planning
Qu'est-ce que le PI Planning ?
Le PI Planning (Program Increment Planning) est l'événement clé du framework SAFe : sur 1 à 2 jours, toutes les équipes d'un Agile Release Train planifient ensemble le prochain incrément de programme (8 à 12 semaines), identifient les dépendances et prennent un engagement collectif.
Combien de temps dure un PI Planning ?
L'événement dure généralement 2 jours complets et se tient tous les 8 à 12 semaines, à chaque nouvel incrément de programme (PI). À cela s'ajoute un temps de préparation en amont (contexte business, backlog priorisé, capacité des équipes).
Quelle différence entre PI Planning et Sprint Planning ?
Le Sprint Planning planifie un seul sprint (1 à 4 semaines) pour une seule équipe. Le PI Planning planifie un incrément entier (8 à 12 semaines) pour toutes les équipes d'un train à la fois, avec un focus sur l'alignement inter-équipes et les dépendances.
Qui participe au PI Planning ?
Toutes les équipes de l'Agile Release Train : développeurs, Product Owners, Scrum Masters, ainsi que le Release Train Engineer (RTE), les Product Managers, les architectes et les Business Owners. L'événement peut réunir de 50 à 125 personnes.
Le PI Planning est-il adapté à une ETI ou une direction générale ?
Pas directement. Le PI Planning opère au niveau des équipes de développement d'un train agile. Pour arbitrer un portefeuille au niveau direction (DG/DSI), une approche plus légère comme le Quarter Plan — un arbitrage trimestriel par la capacité — est souvent plus pertinente.
Prêt à passer de l'intention à l'exécution ?
Étude exclusive · 15 ans de données · 9 295 DSI