Aus JIRA grobe Lead Time Perzentile/Quantile erhalten

Ein How-To..

Wer seine Kanban-Metriken ernst nimmt, weiß: JIRA ist leider wirklich schlecht in diesem Punkt. Es gibt kein Lead-Time-Histogramm, also keine grafische Darstellung der Durchlaufzeiten, keine Tabelle, aus der man die Lead Times ablesen könnte, und das Control Chart zeigt nicht Daten, wie wir es erwarten würden, wie z.B. hier dargestellt.

Reminder: Durchschnitt und Median der Lead Times reichen nicht

Wenn man nicht die Option hat, ein JIRA Plugin zu verwenden oder Issue-Daten in ein anderes Tool zu exportieren, kann man die Perzentile (allg. Quantile) der Lead-Time-Verteilung nicht irgendwo ablesen. Und nochmal: Durchschnitt/Median der Durchlaufzeiten sind zum größeren Teil uninteressant. Wenn wir wissen, dass der Durchschnitt bei 18 Tagen liegt und der Median bei 3 Tagen, wie in der Verteilung mit dem “long tail” unten im Bild zu sehen... was dann? Können wir unseren Forecast, unsere Planung, geschweige denn unsere SLAs darauf basieren? Nein, können wir nicht.

Wenn wir die Verteilung nicht kennen, v.a. rechts von Durchschnitt/Median (eben genau den der “long tail”), sind wir blind. Wir können die zentrale Frage nicht beantworten: Wie lange wird es dauern, bis wir Issue X fertig haben?

Wie lange wird es dauern?

Gut, was wir wissen, ist: Mit einer 50/50 Chance wird das Issue in 3 Tagen fertig sein. Aber wollen wir unser Geld auf einen 50/50 Chance verwetten? Ich nicht. Ich wäre gern 80% oder 90% sicher, oder — basierend auf dem Impact, wenn wir zu spät liefern — vielleicht sogar 95% oder 99% sicher, dass wir pünktlich fertig sind. Und genau das sagen uns die Perzentile unserer Verteilung.

Die Lead-Time-Verteilung im Bild oben hat, wie gesagt, einen so genannten “long tail”. Das bedeutet, dass sich rechts vom Median — dem 50/50 Punkt über alle Leadtimes hinweg — noch sehr viele Issues befinden. Als Daumenregel: Je weiter Median und Durchschnitt (arithm. Mittel) auseinanderliegen, desto schiefer ist die Verteilung, und das kann bedeuten, dass man ein “Tail-Problem” hat.

Wenn ich nun meinem Kunden sage “Die durchschnittliche Lieferzeit ist 18 Tage”, würde er/sie möglicherweise nicht mit 83 Tagen (95. Perzentil) rechnen. Falls es uns weh tut, wenn wir zu spät liefern, würde ich deshalb vielleicht lieber 36 Tage kommunizieren, das 90. Perzentil. Nur einer von zehn Issues braucht länger als 36 Tage. Das ist, je nach Business und Rahmenbedingungen, evtl. ein akzeptables Risiko. Aber jetzt spüren wir unser “Tail-Problem”: Will ich 95% sicher sein statt 90% sicher (36 Tage), muss ich 83 Tage kommunizieren. Das ist eher unangenehm...

JIRA ist — sorry — kein gutes Kanban-Tool

Das Problem mit JIRA ist nun: Egal wie gut oder schlecht unsere Lead-Time-Verteilung ist, wie haben schlicht keine einfache Möglichkeit, diese Verteilung zu erkennen. Out of the box hat JIRA kein Chart hierfür und keine Tabelle, die uns Lead-Time-Perzentile zeigt. Das Control Chart gibt nur arithm. Mittel und Median an. Zudem funktioniert das Control Chart m.E. ohnehin nur vernünftig, wenn wir den gesamten Workflow betrachten, siehe Appendix B zu diesem Thema.

Aber abgesehen von Durchschnitt und Median sind wir als Vollblut-Kanbanistas stark interessiert am 80., 85., 90. oder —  je nach den Umständen — höheren Perzentilen. (Wie sicher müssen wir sein, dass wir immer termintreu liefern? 9 von 10 ist schon besser, als die meisten Projekte, die ich kenne, aber wie gesagt, der Schmerz ist kontextabhängig.)

Veni, vidi, numeravi

Die Lösung ist tatsächlich recht simpel. Man zählt die Issues auf dem Control Chart. “‘Ich kam, sah und zählte” sozusagen, das ist ein einfacher, schneller Ansatz, die Zahlen sind dabei zwar nicht exakt, aber für die meisten Zwecke gut genug.

Sagen wir z.B., wir suchen das 90. Perzentil der Verteilung. Wie im Bild zu sehen, haben wir 83 Issues im Control Chart. Also zählen wir 9 Issues von oben runter (83 / 10 = 8.3 — wir runden auf, das ist konservativer). Der Wert in der Skala auf der linken Seite ist dann das (grobe) 90. Perzentil, ungefähr 15 Tage in unserem Fall.

 

 

Wenn man Cluster von Issues hat — die dicken, vollfarbig grünen Punkte — muss man zuerst herausfinden, wie viele Issues sich in einem Cluster befinden. Hierfür einfach Rechts-Klick auf den Cluster, dann zeigt JIRA die Details. 

 

 

Suchen wir nun das 80. Perzentil: Dafür zählen wir weiter runter, noch mal 9 Issues. Der Wert ist bei uns im Chart ca. 10 Tage.

 

 

So erhalten wir die folgende Tabelle von Lead Times.

Lead Time Verteilung

Median (50. Perz.)

Ariithm. Mittel

80. Perzentil 

90. Perzentil

7

8

10

15

Es ist ein wenig umständlich, die Werte auf diese Art aus dem Control Chart abzulesen, aber es funktioniert und man macht es ja nur ein Mal pro Zeitraum X, je nach den gewählten Kadenzen: Wenn unsere Retrospektive, also unser Delivery Review, ein Mal im Monat ist, machen wir es monatlich. Mehr als wöchentlich diese Zahlen zu sammeln, hat in den meisten Umgebungen keinen Sinn, würde ich behaupten. Die so gewonnenen, groben Zahlen sind m.E. gut genug, um Trends und Veränderungen über die Zeit zu beobachten.

Appendix A: Sollen wir arbeitsfreie Tage (Wochenende) mitberücksichtigen?

JIRA inkludiert von Haus aus nicht arbeitsfreie Tage (also Wochenendtage und JIRA bekannte Feiertage) bei der Berechnung von Lead Times. In manchen Fällen mag das eine gute Idee sein, in den meisten aber m.E. nicht. Wenn der Kunde uns fragt “Wann ist es fertig?” und wir ihm sagen “(Mit 90% Wahrscheinlichkeit ist es fertig...) ...in 15 Tagen”, dann will unser Kunde zum heutigen Kalenderdatum 15 hinzuzählen und basta: Heute ist der 3. Mai, also kriege ich es am 18. Mai. Jeweils die Wochenendtage wieder rein zu rechnen, ist zu kompliziert.

Außerdem: Wessen arbeitsfreie Tage? Deutschland hat 16 Bundesländer, kaum eins hat dieselben Feiertag wie ein anderes. Von internationalen Betrachtungen ganz abgesehen. 

Diese Diskussion ließe sich fortsetzen, aber für den Moment soll reichen: Wenn unsere Lead Times nicht extrem kurz sind, sollten wir arbeitsfreie Tage (non-working days) in der Kalkulation von JIRA mitzählen lassen. Das machen wir, indem wir die entsprechende Checkbox rechts unter dem Control Chart anhaken.

 

 

Appendix B: Wollen wir nicht den gesamten Workflow betrachten?

Achtung: Wenn die Lead Times, die wir analysieren wollen, nur einen Teil des Workflows umfassen — nicht den Workflow bis die Issues den Status Closed erreichen —, dann müssen wir ein zusätzliches Kanban Board in JIRA bilden, basierend auf demselben Filter, den unser “eigentliches” Kanban Board nutzt. Der Grund: JIRAs Control Chart macht merkwürdige Dinge wenn man es in der Konfiguration (direkt unter dem Control Chart) auf einen Teil des Workflows beschränkt. Das habe ich hier dargestellt.

Am Beispiel des im nächsten Bild dargestellten Workflow: Wir wollen die Lead Time wissen bis nach der QA wissen.Im JIRA workflow ist das Issue erst Done, wenn es die weiteren Status Ready to Merge, Merged und Released passiert. (Ich habe für mein Beispiel einen zufälligen Workflow hier geklaut.)

 

 

Deshalb müssen wir alle Status, die “stromabwärts” (downstream, also im Workflow nachgelagert) von QA liegen in die Done-Spalte unseres extra kreierten Boards mappen. Mit diesem Board können wir die Durchlaufzeiten dann wie oben beschrieben eruieren.