Le PI Planning est l’un des rituels les plus puissants du cadre SAFe® : deux jours pour aligner jusqu’à 125 personnes sur une vision commune et un engagement collectif. En théorie, c’est une machine à créer de la clarté. En pratique, beaucoup d’organisations en ressortent avec des plans fragiles, des dépendances non résolues et un vote de confiance de façade.
Le problème n’est pas le format. C’est la préparation, l’outillage et le suivi qui font la différence entre un PI Planning transformateur et un événement qui consomme du budget sans produire d’alignement durable.
1. Un backlog mal affiné à l’entrée du PI Planning
Les équipes passent la moitié du Jour 1 à comprendre les features au lieu de les planifier : les questions fusent, les Product Managers improvisent, le temps file. Le PI Planning n’est pourtant pas un événement d’affinage. Chaque feature présentée doit arriver avec :
- Un énoncé clair de la valeur métier attendue
- Des critères d'acceptation définis
- Une estimation grossière de taille (T-shirt sizing)
- Les dépendances connues identifiées en amont
Instaurer un « Definition of Ready for PI Planning » — aucune feature n’entre dans l’événement sans validation préalable par le Product Manager et le System Architect.
2. Des dépendances identifiées mais jamais résolues
Le Program Board se couvre de fils rouges entre équipes. Tout le monde les voit, personne ne les traite, et on passe au vote de confiance en espérant que « ça ira ». Mieux vaut distinguer trois catégories de dépendances :
- Résolvables immédiatement — réordonnancement du backlog ou réaffectation de stories.
- Nécessitant une décision — escalade pendant la Management Review du Jour 1.
- Acceptées comme risques — classifiées dans le ROAM (Resolved, Owned, Accepted, Mitigated).
Dédier 90 minutes au « Dependency Resolution Workshop » entre les sessions Breakout du Jour 1 et la plénière du Jour 2. Chaque dépendance doit avoir un propriétaire nommé et une date de résolution.
3. Confondre PI Objectives et liste de tâches
Les objectifs PI ressemblent à « Terminer les stories 1 à 15 du backlog ». Aucune valeur métier n’est exprimée, et les Business Owners ne peuvent pas évaluer l’ambition du plan. Un PI Objective efficace est orienté résultat, pas output :
- Implémenter le module de paiement
- Permettre aux utilisateurs de finaliser un achat en moins de 3 clics, réduisant le taux d’abandon de 20 %
Chaque objectif doit avoir une Business Value assignée par les Business Owners (échelle 1-10) : cela force l’alignement entre ce que les équipes planifient et ce que l’organisation valorise réellement.
4. Ignorer la capacité réelle des équipes
Les équipes s’engagent sur 100 % de leur capacité théorique. Dès le Sprint 1, les imprévus (bugs, support, absences) créent un retard qui s’accumule sur tout le PI. Mieux vaut appliquer un facteur de charge réaliste :
- Capacité brute = nombre de story points historiques par sprint.
- Capacité nette = capacité brute × 0,80 (réserve de 20 % pour imprévus). C’est la recommandation officielle de Scaled Agile lui-même : ne jamais planifier à 100 % de la capacité théorique.
- Objectifs non engagés (anciennement « Stretch » avant SAFe 5.0) = au-delà de la capacité nette, explicitement exclus du calcul de prédictibilité.
Remplir le Sprint IP (Innovation and Planning, le dernier de chaque PI) avec des tâches planifiées. C’est un anti-pattern documenté par Scaled Agile — ce sprint doit rester à charge nulle (Load = 0) pour absorber l’imprévu, l’innovation et la préparation du PI suivant. Le charger revient à supprimer la seule vraie marge de manœuvre de l’ART.
5. Un PI Planning 100 % présentiel dans un monde hybride
Les équipes sont distribuées, mais le format n’a pas évolué. Les participants distants subissent une expérience dégradée : micro coupé, Program Board illisible en visio, breakout sessions chaotiques. Passer au format « digital-first » signifie :
- Un Program Board numérique partagé en temps réel
- Des breakout rooms outillées avec un board dédié par équipe, synchronisé avec le backlog
- Un timer visible et un facilitateur dédié au canal distant
- Des votes de confiance anonymes via un outil numérique
Un même environnement numérique partagé pendant et après l’événement évite le double travail de ressaisie et de mise à jour manuelle du plan — la principale source de temps perdu pour les RTE et Scrum Masters dans les ART distribués.
6. Pas de suivi après l’événement
Le PI Planning produit un plan. Puis les équipes retournent dans leur sprint quotidien. Le Program Board n’est jamais mis à jour, et au PI suivant, les mêmes problèmes réapparaissent. Le PI Planning est pourtant le point de départ d’un cycle de pilotage :
- Semaine 1-2 — Scrum of Scrums / ART Sync pour valider que le plan tient.
- Chaque sprint — System Demo pour mesurer l’avancement sur les PI Objectives.
- Mi-PI — revue intermédiaire des risques (ROAM actualisé).
- Fin de PI — Inspect & Adapt avec mesure du % d’objectifs atteints.
Le « PI Predictability Measure » — valeur métier livrée / valeur métier planifiée sur les objectifs engagés. Cible officielle SAFe : 80 % ou plus pour un ART mature. Un ART qui démarre atteint souvent 40-60 % ; l’amélioration vers 80 %+ se fait généralement sur 3 à 4 PI, pas du jour au lendemain.
7. Utiliser des outils déconnectés du quotidien des équipes
Le PI Planning se déroule sur Miro, Excel ou des post-its. Puis les équipes retournent dans Jira. Résultat : deux sources de vérité, aucune synchronisation, un Program Board obsolète dès le lundi suivant. L’outillage du PI Planning doit être intégré à l’outil de gestion quotidien :
- Le Program Board doit refléter les issues réelles du backlog
- Les dépendances doivent être des liens entre tickets, pas des fils sur un tableau
- Les PI Objectives doivent être traçables vers les features et stories
- Les métriques (velocity, load, predictability) doivent se calculer automatiquement
C’est précisément ce que permet Agile Hive : transformer Jira en plateforme complète de PI Planning, avec un Program Board synchronisé, une gestion visuelle des dépendances et des rapports automatisés.
Conclusion : le PI Planning est un investissement, pas une formalité
Deux jours × 100 personnes = 200 jours-homme. C’est l’un des investissements les plus coûteux du cadre SAFe. Mal exécuté, c’est du temps perdu. Bien préparé, correctement outillé et rigoureusement suivi, c’est le moment où une organisation passe de « équipes qui travaillent en parallèle » à « équipes qui livrent ensemble ».
Les 7 erreurs décrites ici ne sont pas des fatalités. Ce sont des problèmes d’organisation, de méthode et d’outillage — et chacun a une solution concrète.
Nos experts SAFe et Atlassian vous accompagnent dans la mise en place d’un environnement optimisé.