Kanban (und Scrum): Ausreißer, Cycle Times, Streuung analysieren

Zwei der Kanban-Core-Praktiken sind „Visualize“ und „Manage Flow“. JIRA bietet eine einfache Möglichkeit, grundsätzliche Analysen des Flow zu machen: Control Charts.

Control-Chart

Control Charts

Included-ColumnsIn Control Charts wird für jedes Ticket auf der y-Achse die Zeit abgetragen, die auf das Ticket verwendet wurde, bis es DONE war, das ist die sogenannte Cycle Time. Bzw., schließt man die TODO-Spalte mit ein in den Report, die sogenannte Lead Time. Lead Time ist also die Zeit von der „Entstehung“ des Tickets bis DONE, Cycle Time ist die Zeit vom Berabeitungsanfang bis DONE. Bei Support-Kanban ist es sinnvoll, die Lead Time anzuschauen, weil der Kunde ja ab Meldung des Issues möglichst schnell die Lösung will. Bei Projekten, wo Tickets umpriorisiert und schon mal „auf Vorrat“ gegroomt werden, ist die Cycle Time sinnvoller, weil ein Ticket ja durchaus länger im Zustand TODO sein kann, ohne dass das ein Problem ist, zum Beispiel einfach im Backlog weiterer unten.

Im Control Chart sieht man nun noch ein paar weitere visualisierte Informationen:

  • Den Mittelwert der Cycle Time (oder Lead Time), die rote Linie
  • Den rollenden Mittelwert, das ist der Mittelwert, wie er sich über die Zeit hinweg ändert, die blaue Linie
  • Die Standardabweichung, die die Streuung der Durchlaufzeiten darstellt: Breite hellgraue Fläche vertikal um den Mittelwert heißt viel Streuung, also sowohl superschnelle als auch superlangsame Tickets. Schmale hellgraue Fläche heißt wenig Streuung, heißt, die Tickets haben ungefähr gleich lange gedauert in der Bearbeitung.
  • Einfach zu sehen sind auch sogenannte Ausreißer, also Tickets, die deutlich länger als der Rest bzw. Durchschnitt gebraucht haben.

Control Chart analysieren und nach Verbesserung streben

Was ist nun gut? Wonach sollte man streben? Das Folgende gilt für Scrum ebenso wie für Kanban  – es gibt ja verschiedene Ansätze, Scrum um den Lean-Ansatz zu erweitern, z.B. Scrumban und Lean Agile.

Ausreißer sind schlecht, weil in Kanban nach einem gleichmäßigen Flow gestrebt wird. Sie sind aber generell schlecht, weil sie oft bedeuten, dass etwas nicht gut gelaufen ist. Wenn ein Ticket sehr viel länger gebraucht hat, sollte man prüfen, warum. Vielleicht war es einfach ein „fettes“ Ticket. Vielleicht lag es aber auch an Kommunikationsproblemen, an Engpässen bei Spezialisten, ohne die man das Ticket nicht abschließen konnte, an unerwartet auftretenden technischen Problemen, die man in Zukunft vermeiden kann usw. All dies sind dann Anlässe, zu prüfen, ob man solche „Sonderfälle“ in Zukunft verhindern kann, um einen gleichmäßigen Flow, eine smoothe Bearbeitung und eine gute Planbarkeit zu gewährleisten.

Breite Streuung sagt, dass die Tickets sehr unterschiedlich lange brauchen, bis sie DONE sind. Wenn eine vernünftige Schätzung vorliegt, ist das nicht ganz so problematisch, weil man natürlich weiß, dass eine 13er-Story länger braucht als eine 3er-Story. In Kanban an sich wird aber gar nicht geschätzt, sondern versucht, einen verlässlichen Flow zu erreichen, so dass man statistisch abgesichert sagen kann: Ein Ticket dauert bei uns mit 95% Sicherheit 5 Tage (Beispiel). Aber auch, wenn man schätzt, ist es interessant, die Streuung zu betrachten. Es ist nämlich grundsätzlich nicht wünschenswert, sehr große Tickets zu haben, wie wir ja im Scrum auch schon gemerkt haben. Dagegen ist es grundsätzlich sinnvoll, daran zu arbeiten, möglichst „kleine“ und dabei möglichst „werthaltige“ Issues zu haben. Nur so funktioniert Agilität, das zeigt ein Extrembeispiel: Das Ticket „Als Shopbetreiber will ich einen Shop, damit ich viel Geld verdiene“ ist sinnlos. Es ist zu groß und (deshalb!) völlig unterspezifiziert. Und wäre es ausspezifiziert, wäre es ein Pflichtenheft. Die Erfahrung zeigt: Je kleiner ein Issue, desto besser das Verständnis / die Spezifizierung / die Feedbackgeschwindigkeit usw. Siehe auch Arikel „Inkrementell und iterativ“. Den Überblick zu behalten ist dabei die eigentlich Kunst (wofür es Epics, Story Maps, Milestones und Roadmaps gibt).

Der rollende Mittelwert sollte sich über die Zeit verkleinern. Der Grund: Wir wollen lieber kleine Tickets zuverlässig und schnell durchschleusen, als große Tickets lange bearbeiten oder noch schlimmer, Tickets in Wartestellung rumliegen haben.

Fazit: Optimize Flow!

Control Charts bzw. die Messgrößen, die uns JIRA damit gibt, sind ein guter Weg, quantitativ an Kaizen herazugehen. Also die letzte Core Praktik aus Kanban auszuführen, nämlich Improve collaboratively, evolve experimentally (using models and the scientific method). So wendet man einfache Prinzipien aus dem Lean an, egal, ob man Kanban macht oder Scrum: Die Durchlaufzeiten verbessern, die Ausreißer minimieren.Standard_deviation_diagram

Die Betrachtung von Ausreißern wie oben beschrieben erfolgt einfach nach Augenschein… Der statistische Ansatz sagt, dass alles außerhalb der 2-Mal-Standardabweichung um den Mittelwert ein Prozessproblem darstellt und man das dann als Ausreißer betrachten muss. Zwei Mail Standarabweichung decken 95.4 Prozent aller vorkommenden Fälle ab, das benutzt Kanban dann um – wie oben erwähnt – zu sagen: Mit 95% Wahrscheinlichkeit wird ein Ticket in x Tagen DONE. Je kleiner die Streuung, desto kleiner ist dann das x, das ist das Ziel. Für unsere Zwecke, denke ich, reicht es, erst einmal einfach mit gesundem Menschenverstand auf die Ausreißer zu kucken und nach Gründen und Verbesserung zu suchen.

Kommentar abgeben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.