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 Charts

In 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 Artikel "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.

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.

Neueste Posts

Die größten Akquisitionen von Google, Amazon und Apple und einige Learnings daraus!
Neue Ausgabe des eStrategy-Magazin verfügbar 360 Stories – ein Spiel für Teams Die B2B E-Commerce Pyramide
Digital Storytelling - ein Kurztrip in die Kreativität und wieder zurück

Archiv

Dezember November Oktober September August Juli Juni Mai April März Februar Januar
Dezember November Oktober September August Juni Mai April Februar Januar
Dezember November Oktober September August Juli Juni März Februar
Oktober September August Juli Juni Mai April März Januar
Dezember November Oktober September August Juli Mai April Februar
November Oktober September April Februar
Dezember September Juni Mai Februar Januar
Juli Mai April März Februar Januar
September August Juli März
Oktober September Juli Juni Mai März Februar
Februar

Kategorien

E-Commerce Unternehmensmeldung Online-Marketing Magento Commerce Neos TYPO3 SEO SEA Usability Digitale Transformation Agile Projektentwicklung Corporate Web Analytics Künstliche Intelligenz Mobile Marketing Social Media Veranstaltungen Research & Development

Unser Herz schlägt online -
Deins Auch?


Wir stellen uns jeden Tag neuen Heraus-forderungen des Online-Business – immer auf der Suche nach spannenden Lösungs-ansätzen und sinnvollen Technologien. Eine Vielzahl namhafter Kunden vertrauen auf das Online Know-how „Made in Kolbermoor / Rosenheim und München“. 

Lust auf TechDivision? Hier geht zu unseren Stellenanzeigen

eStrategy Magazin


Erfahren Sie mehr zu den Themen E-Commerce, Online-Marketing, Mobile, Projektmanagement, Webentwicklung und E-Recht in unserem kostenlosen Online-Magazin.

Jetzt herunterladen!

Whitepaper:
Agiles Projektmanagement


In unserem kostenlosen Whitepaper versuchen wir Basiswissen und Erfahrungen aus vielen Jahren täglicher Projekt- und Unternehmenspraxis zu vermitteln, mit denen Sie die Anforderungen des Arbeitslebens von Heute besser bewältigen können.

Jetzt herunterladen!

Autor

Haben wir Ihr Interesse mit unserem Blog geweckt?

Wir sind der richtige Partner für anspruchsvolle Projekte im Bereich E-Commerce, Corporate Web, Consulting und Online-Marketing. Sprechen Sie mit uns!

Autor

Josef Willkommer Geschäftsführer / CMO