La checklist minimale pour être efficace au PI Planning

Le blog KōKan > Agilité à l'échelle > La checklist minimale pour être efficace au PI Planning

Le 11 avril 2025, nous avons partagé des clés concrètes lors du KōKan Talk pour réussir son PI Planning.

👉 Vous pouvez revoir l’événement sur notre chaîne YouTube [KōKan-fr].

En complément, voici un takeaway : une checklist minimale pour aborder le PI Planning avec efficacité, dès le premier team breakout.


Un PI Planning, ça se joue le jour J. Pas avant.

De fait, le PI Planning est un moment décisif. Il permet d’aligner les équipes sur le quoi, de converger vers un comment, et de s’accorder sur un quand. Tout cela, ensemble, sous un même toit.

Mais attention : entre être prêt et être sur-préparé, la frontière est fine. Trop souvent, l’épuisement arrive avant même le jour du match, parce qu’on a tout joué d’avance.

Préparer un PI Planning, ce n’est pas faire le match avant l’heure. C’est d’abord s’assurer que les lacets sont faits : qu’on est bien équipé, que chacun connaît sa foulée, et que tout est prêt pour performer ensemble.

Cela nécessite d’avoir sur étagère des éléments clés :

  • Les business process, les intentions architecturales ou encore les rôles des composants sont clairs
  • Les éléments de performance, de disponibilité, vélocité ou encore les allocations sont clairs
  • Sur étagère sont disponibles ces data, l’outil de management visuel affiche les PBI, les formations sont digérées et des directives pas à pas sont accessibles pour chaque étape
Liste des objectifs et actions par parties des team breakouts
Exemple d’un planning pas à pas détaillé

Checklist minimale de préparation PI Planning

Une équipe efficace est une équipe juste prête. Ci-après, découvrez une la checklist minimale pour être efficace au PI Planning.

  • Connaître la capacité par sprint et par allocation :
    • Connaître le vélocité moyenne de l’équipe (ou débit)
    • Connaître le volume de jour et les éventuelles passations
    • Connaître les allocations de capacité 
  • Avoir des intrants complets :
    • Les liens vers les études d’architectures, schémas, spécifications, assets graphiques etc. rangées dans la GED se trouvent dans la feature
    • Les backlogs sont raffinés, les features “not ready” ont été mises de côtés
    • Chaque feature identifie clairement les équipes contributrices à chaque besoin
    • Toutes les équipes requises pour une feature ont la bande passante pour la traiter : Si une équipe clé n’a pas la bande passante, la feature ne doit pas être au PI Planning
    • Le reliquat du PI n-1 est connu
  • Guider sur le management visuel et y intégrer les sujets :
    • Tout le monde a testé son accès au board de management visuel, une session a présenté les nouveautés en amont
    • Afficher le reliquat en termes de features et stories, ainsi que les nouvelles features apparaissent au tableau
    • Lister dates des événements business majeurs
    • Pour se rôder aux PIP (le niveau Shu, de Shuhari), décrire les actions attendues et les objectifs à atteindre pour chaque team breakout
  • Tous les nouveaux arrivants depuis le PI n-1 ont suivi une formation pour comprendre l’intention, le déroulé, les rôles, les livrables et surtout leur contribution au PI Planning

Conclusion

En définitive, le PI Planning n’est pas un livrable. C’est un moment collectif, un cadre de dialogue pour forger des convictions communes et prendre des engagements solides.

En suivant cette checklist, vous augmentez vos chances d’être efficaces dès la première minute du Team Breakout. Ainsi, vous co-construisez un plan réaliste, aligné, fluide et sans improvisation inutile.

Certes, tout ne sera pas 100% maîtrisé. Il restera des zones d’ombre. Mais avec une bonne préparation, les équipes se poseront les bonnes questions au bon moment, avec les bons éléments en main.

Enfin le jour J, la vraie partie commence — ensemble, et bien chaussés.

Pour poursuivre votre lecture, après le PI Planning, découvrez comment structurer votre Product Backlog. L’objectif : un produit fiable, durable, alimenté par des Features et Enablers bien définis.

About the author

Nelson commence sa carrière en tant que développeur puis rejoint Xebia en 2016 pour réaliser des produits data et digitaux.  Il intervient dans des entreprises telles que BNP, Galeries Lafayette, Société Générale, Orange jusqu'à assumer la direction de l'ingénierie d'une partie du PMU.  Ses 12 ans d'expérience et son rôle de Release Train Engineer de 14 équipes, lui ont confirmé l'importance de garder au coeur des préoccupations et à tout niveau de l'entreprise : la qualité logicielle, la mesure et le release management. En 2023, il rejoint le collectif KōKan pour renforcer ce pure player en agile delivery management sur Paris et Rennes.

Articles connexes