Ce qu’on reconstitue à la main pendant les deux jours d’un PI Planning n’est pas arbitraire : ce sont exactement les informations que le référentiel ne contient pas. Jira porte le backlog, les estimations et une partie des dépendances. Il ne porte ni la capacité réelle par équipe et par itération, ni les dépendances entre trains, ni les contraintes de jalon externes. La thèse de cet article est que ces trois absences expliquent la forme même de l’exercice, et qu’elles sont de nature différente, ce qui appelle trois traitements différents.
Ce que Jira porte effectivement
Il faut commencer par ce qui est présent, parce que c’est substantiel. Jira contient le backlog structuré en epics et en stories, les estimations en points ou en jours, l’état d’avancement, l’affectation aux équipes, et les liens entre tickets, qui expriment une partie des dépendances.
Ces données sont fiables à proportion de la discipline de l’organisation, et elles sont tenues au jour le jour par les équipes, ce qui est leur principale qualité : elles ne sont pas une photographie périodique, elles suivent le travail. Un PI Planning qui ignorerait ce matériau travaillerait contre son propre référentiel.
La difficulté n’est pas là. Elle est que la préparation d’un PI requiert trois informations supplémentaires, dont aucune n’est un objet natif de l’outil.
La capacité réelle par équipe et par itération
La première absence est la capacité. Jira connaît la vélocité observée, c’est-à-dire le nombre de points fermés lors des itérations passées, qui est une mesure utile mais rétrospective. Il ne connaît pas la capacité de l’itération à venir.
Cette capacité dépend de données qui vivent ailleurs : les congés posés, les astreintes, les arrivées et les départs, la part de l’équipe consacrée au support du patrimoine existant, les engagements pris sur d’autres périmètres par des personnes partagées. Rien de tout cela n’est un champ de l’outil, et la vélocité passée ne les intègre que rétrospectivement, donc toujours avec un décalage.
En pratique, cette donnée est détenue par les responsables d’équipe, le plus souvent dans un tableur personnel, et elle est annoncée oralement au moment du PI. C’est une information de bonne qualité, mais qui n’existe nulle part sous une forme consolidée et comparable d’une équipe à l’autre, et qui disparaît après la séance.
Les dépendances entre trains
La deuxième absence est structurelle. Les liens entre tickets expriment correctement les dépendances à l’intérieur d’un périmètre où les équipes partagent des conventions de saisie. Entre deux trains, cette condition tombe.
Une dépendance inter-trains se négocie entre deux personnes qui ne travaillent pas sur le même backlog, parfois pas dans la même instance de l’outil, et dont les itérations ne sont pas nécessairement alignées. Elle prend souvent la forme d’un engagement de date plutôt que d’un lien entre deux tickets : un train s’engage à livrer une interface avant une certaine itération, sans que le ticket correspondant existe encore chez l’autre.
C’est la raison d’être du mur et des fils tendus entre les colonnes. Le dispositif physique matérialise une information qui n’a pas de représentation dans le référentiel, et qui se perd lorsque le mur est démonté. Les comptes rendus de PI conservent les engagements ; ils ne conservent pas la structure de dépendances qui permettrait de recalculer les conséquences d’un retard.
Les contraintes de jalon externes
La troisième absence est d’une autre nature. Un jalon externe est une date imposée de l’extérieur du train : une échéance réglementaire, une fenêtre de mise en production, la livraison attendue par un partenaire, une date contractuelle.
Ces dates ne sont pas des tickets. Elles ne sont pas estimables, elles ne sont pas déplaçables par l’équipe, et elles contraignent l’ordonnancement sans apparaître dans le backlog. Lorsqu’elles sont connues, elles vivent dans un support de direction, parfois dans un planning de type Primavera P6 si l’organisation en exploite un, souvent dans une présentation.
Leur absence du référentiel a une conséquence précise : le plan issu du PI peut être parfaitement cohérent du point de vue des capacités et des dépendances internes, et manquer une date imposée dont personne n’a vérifié la compatibilité au moment de l’engagement. La vérification se fait alors a posteriori, lorsque le jalon approche.
Trois absences, trois traitements
Ces trois manques n’appellent pas la même réponse. La capacité est une donnée à collecter et à maintenir : elle existe déjà chez les responsables d’équipe, le travail consiste à la consolider sous une forme comparable et à l’actualiser. Les dépendances inter-trains sont une donnée à produire : elles n’existent sous forme écrite qu’au moment du PI, et le travail consiste à leur donner une représentation qui survive à la séance. Les jalons externes sont une donnée à importer : ils existent ailleurs, et le travail consiste à les mettre en regard du plan.
Une fois ces trois données réunies, la question qui se pose au PI change de nature. Elle n’est plus « est-ce que cela rentre », à laquelle on répond par une appréciation collective, mais « quels plans respectent ces contraintes », qui est une question de calcul. Le mur garde alors sa fonction propre, qui est la négociation entre équipes, pendant que la vérification de cohérence est faite par ailleurs.
C’est le positionnement de Konatus : une surcouche qui lit le référentiel existant et le complète des données qu’il ne contient pas, sans s’y substituer. Jira reste le référentiel d’exécution ; lorsque l’organisation pilote son portefeuille dans un outil dédié, c’est ce dernier qui reste la source du planning. Une simulation AlignIQ dure cinq minutes, ce qui permet de la relancer pendant la séance plutôt qu’entre deux PI.
Sur votre dernier PI, laquelle de ces trois données a demandé le plus de temps à reconstituer ?
