Was ist ein WIP-Altersdiagramm?
Also, stell dir ein normales Kanban-Board vor. Du siehst die Tickets, du siehst die Spalten. Aber was du nicht siehst ist, wie lange jedes Ticket schön dort festsitzt. Das WIP-Altersdiagramm zeigt dir genau das — das Alter jedes laufenden Elements, Phase für Phase. Und ehrlich gesagt, das ist ein Game Changer. Weil im Gegensatz zum kumulativen Flussdiagramm, das dir eine aggregierte Sicht gibt (nützlich, aber nicht sofort handlungsrelevant), zeigt dir dieses Diagramm die einzelnen Elemente die Probleme machen. Ich habe Teams gesehen, die erst dadurch entdeckt haben dass ein Ticket seit 22 Tagen in Review feststeckt, ohne dass es jemandem aufgefallen ist. Mit diesem Diagramm? Unmöglich das zu übersehen. Besonders wertvoll wenn du mit Kanban, Scrumban oder irgendeinem Flow-basierten Framework arbeitest.
Warum WIP-Alter ein Strategischer Indikator ist
Was die meisten Leute nicht kapieren: WIP-Alter ist ein Frühindikator. Zykluszeit? Die misst du erst hinterher — das Ticket ist fertig, cool, aber zu spät zum Handeln. WIP-Alter schreit dich in Echtzeit an. Daniel Vacanti hat das in seiner Forschung klar gezeigt: Teams die ihr WIP-Alter niedrig und konstant halten, haben kürzere und vorhersagbarere Zykluszeiten. Und das ergibt Sinn. Weil wenn deine Tickets in einer bestimmten Phase alt werden, dann hast du einen strukturellen Engpass. Kein Motivationsproblem. Ein echtes Prozessproblem. Statt also zu sagen "wir müssen schneller arbeiten" kannst du sagen "wir haben ein Problem in Review, hier sind die Daten". Das ist halt überzeugender in der Retro.
Schlüsselkonzepte und Alarmschwellen
WIP-Limits kennst du wahrscheinlich — das ist die maximale Anzahl an Elementen die gleichzeitig in einer Phase sein dürfen. Das Ziel: nicht alles anfangen ohne was fertig zu machen. Aber über die Limits hinaus gibt es Altersschwellen. Unter einem Tag? Frisch, alles gut. Zwischen einem und sieben Tagen? Verdient einen Blick. Zwischen sieben und vierzehn? Handlungsbedarf. Über vierzehn? Das ist echt nicht gut. Das Ticket hängt wahrscheinlich fest und jemand muss sich drum kümmern, und zwar jetzt. Das Diagramm zeigt dir all das auf einen Blick. Und die Analyse nach Phase ist krass wichtig: wenn alle alten Tickets in Test stecken, ist das Problem klar. Es geht nicht darum, null WIP zu haben — es geht um einen gleichmäßigen Fluss wo Tickets in einem vorhersagbaren Tempo durchlaufen.
Best Practices für die Tägliche Nutzung
Erster Reflex: Diagramm im Standup öffnen. Statt dem klassischen "gestern hab ich dies gemacht, heute mach ich das", fangt mit den ältesten Tickets an. Das lenkt die Diskussion auf das was wirklich zählt — die Blockaden. Dann: Eskalationsregeln aufstellen. Wenn ein Ticket über 7 Tage alt wird, muss der Scrum Master nachforschen. Über 14 Tage, geht es an den PO. Und wenn du siehst dass regelmäßig mehrere Tickets die 14-Tage-Schwelle sprengen, ist das ein starkes Signal: deine WIP-Limits sind zu hoch oder du hast eine Phase die zu wenig Kapazität hat. Reduzier die Limits schrittweise und beobachte was passiert. Aber vor allem — und hier hab ich viele Teams strugglen sehen — kombinier das Altersdiagramm mit anderen Metriken. Durchsatz, kumulatives Flussdiagramm. Jede Metrik allein erzählt nur einen Teil der Geschichte. Zusammen geben sie dir das komplette Bild.
