Graphique d'Ancienneté WIP par Étape

Bon, imagine que t'as un tableau Kanban classique. Tu vois les tickets, tu vois les colonnes. Mais ce que tu vois pas, c'est depuis combien de temps chaque ticket est coincé là où il est. Le graphique d'ancienneté WIP, c'est exactement ça — il te montre l'âge de chaque élément en cours, étape par étape. Et franchement, c'est un game changer. Parce que contrairement au diagramme de flux cumulatif qui te donne une vue agrégée (utile, mais pas actionnable immédiatement), celui-ci pointe du doigt les éléments individuels qui posent problème. J'ai vu des équipes découvrir qu'un ticket traînait en Review depuis 22 jours sans que personne s'en rende compte. Avec ce graphique, impossible de passer à côté. C'est particulièrement pertinent si tu bosses en Kanban, en Scrumban, ou dans n'importe quel framework orienté flux continu.

Le truc que la plupart des gens comprennent pas, c'est que l'ancienneté WIP est un indicateur avancé. Le temps de cycle ? Tu le mesures après coup — le ticket est terminé, cool, mais trop tard pour agir. L'ancienneté WIP te crie dessus en temps réel. Daniel Vacanti l'a bien montré dans ses travaux : les équipes qui gardent une ancienneté WIP basse et régulière ont des temps de cycle plus courts et plus prévisibles. Et ça se tient. Parce que si tes tickets vieillissent dans une étape précise, c'est qu'il y à un goulot structurel. Pas un problème de motivation individuelle. Un vrai problème de processus. Du coup, au lieu de dire "il faut aller plus vite", tu peux dire "on à un problème en Review, voilà les données". C'est quand même plus convaincant en rétrospective, non ?

Les limites WIP, tu connais sûrement — c'est le nombre max d'éléments qu'on autorise dans chaque étape. Le but, c'est d'éviter de tout commencer sans rien finir. Mais au-delà des limites, il y a les seuils d'ancienneté. En gros : moins d'un jour, c'est frais, tout va bien. Entre un et sept jours, ça mérite un coup d'œil. Entre sept et quatorze, faut agir. Au-delà de quatorze ? C'est le bordel. Ce ticket est probablement bloqué et quelqu'un doit s'en occuper, genre maintenant. Le graphique te permet de voir tout ça d'un coup. Et l'analysé par étape est super importante : si tous tes vieux tickets sont en Test, le problème est clair. C'est pas qu'il faut zéro WIP, c'est qu'il faut un flux régulier où les tickets avancent à un rythme cohérent.

Premier réflexe : ouvre le graphique au standup. Au lieu du classique "hier j'ai fait ci, aujourd'hui je fais ça", commencé par les tickets les plus vieux. Ça recentre la discussion sur ce qui compte vraiment — les blocages. Ensuite, mets en place des règles d'escalade. Genre, si un ticket dépasse 7 jours, le Scrum Master doit investiguer. Au-dessus de 14 jours, ça monte au PO. Et si tu vois que plein de tickets explosent régulièrement le seuil de 14 jours, c'est un signal fort : tes limites WIP sont trop hautes ou t'as une étape qui manque de bras. Réduis les limites progressivement et regarde ce qui se passe. Mais surtout — et c'est là que j'ai vu beaucoup d'équipes galérer — combine le graphique d'ancienneté avec d'autres métriques. Le débit, le diagramme de flux cumulatif. Chaque métrique seule raconte une partie de l'histoire. Ensemble, elles te donnent la vue complète.