Ganz egal, welches agile Vorgehensmodell Sie in Ihrem Team einsetzen – Portfolio for JIRA kann dabei helfen, eine realistische Roadmap für Ihre Produkte und Projekte zu erzeugen. Die vorherigen Beiträge zu Portfolio for JIRA haben sich hauptsächlich mit Scrum befasst. Man kann auf Umwegen jedoch auch Kanban mit Portfolio for JIRA verbinden. Dieser Artikel betrachtet, wie Kanban-Teams zuverlässig planen können.

Ein Hinweis: Derzeit ist Portfolio for JIRA nicht direkt dazu in der Lage mit Kanban umzugehen, aber es gibt eine simple Lösung. Es gibt eine Team-Konfiguration für Kanban, die sich wunderbar für die Planung einer Roadmap eines Kanban-Teams verwenden lässt. Diese Konfiguration orientiert sich zwar an der ursprünglichen Kanban-Praxis, ist aber nicht zu 100% akkurat. Atlassian hat einen Workaround entwickelt, mit dem man Roadmaps für Kanban-Teams kalkulieren kann. Wie mit jedem agilen Prozess und insbesondere Kanban wird die detaillierte, langfristige Planung jedoch immer zu einem Teil für die zuverlässige, konstante Auslieferung von hoher Qualität geopfert. Anforderungen und Geschäftsziele werden regelmäßig angepasst, was sich wiederum auf die Planung auswirken kann. Portfolio for JIRA ist zwar dazu in der Lage Veränderungen „on-the-fly“ in die Planungen der Roadmaps zu übernehmen und neue Szenarien und Änderungen automatisch einzupflegen, aber es liegt noch immer an Ihnen zu entscheiden, welche Commitments gemacht werden und was erreicht werden kann.

Was ist Kanban überhaupt?

Kanban ist eine lean agile-Methode, die sich aus dem Japanischen kan ban ableitet. Grob übersetzt bedeutet „kan ban“ in etwa „Karte, die man sehen kann“. Von der in der Toyota-Produktion eingesetzten Just-In-Time-Methode abgeleitet, lässt sich dieses Prozessmodell wunderbar auf die Entwicklung von Software und deren kontinuierlicher Auslieferung abbilden.

Kanban visualisiert alle anstehenden Arbeiten als ein in selbst geschlossenes System, in dem alle anstehenden Aufgaben als Karten auf einem Board in einer Anzahl von Spalten visualisiert werden. Das Team priorisiert eine Liste aller Aufgaben in der To-Do-Spalte und wenn an einer Aufgabe gearbeitet wird, wandert diese in die In Progress-Spalte.

Sobald die Arbeit an den Aufgabenpaketen voranschreitet, rutschen sie in den Workflow-Spalten weiter. In JIRA werden diese Spalten mit Backlog, Für Entwicklng ausgewählt, In Arbeit und Erledigt tituliert. Um weitere Planungs- oder Qualitätssicherungsmechanismen einzubauen, können die Spalten selbstverständlich auch feingranularer gestaltet werden. Sowohl Scrum als auch Kanban funktionieren gut als agile Methoden, wieso also ausgerechnet Kanban nutzen? Kanban ist ein viel schlankere agile Methodik, die sich für Teams mit klar definierten zu erledigenden Aufgaben eignet. Es wird mehr Augenmerk auf Sichtbarkeit, Flexibilität und der Erledigung von wertschöpfenden Aufgaben gelegt als auf das Management von Team-Prozessen.

portfolio-kanban-1

Das von Atlassian postulierte Vorgehen lässt sich in folgende Schritte unterteilen:

1. Ein Projekt oder Board in JIRA Software erstellen

Falls Sie vorhaben, Kanban in JIRA Software ohne ein bereits existierendes Projekt einzusetzen, müssen Sie zuerst ein neues Projekt oder Board mit der Kanban-Funktion erstellen. Es ist zwar nicht unbedingt erforderlich ein Kanban-Board zu benutzen (ein Filter oder Projekt würde genauso gut funktionieren) aber ein Kanban-Board stellt sicher, dass ein konsistenter Abgleich zwischen Portfolio For JIRA und JIRA Software möglich ist. Falls Sie bereits ein Board, Projekt oder Filter besitzen, dann können Sie direkt nach Portfolio for JIRA wechseln.

2. Einen Portfolio-Plan erstellen

Im Portfolio For JIRA-Menü wählen Sie Plan erstellen, um den Plan-Erstellungs-Wizard zu starten. Seit Portfolio for JIRA 2.0 führt dieser Assistent durch die Erstellung eines neuen Planes in unter einer Minute. Dazu müssen zuerst der Name des Plans, die Vorgangs-Quelle und „Story Points“ als Schätzungsgrundlage gewählt werden. Über Releases geht es weiter zur Team-Seite. Auf der Seite zur Team-Definition muss für diesen Workaround eine Scrum-Iterationslänge von einer Woche gesetzt und die Velocity des Teams auf den Durchsatz des Teams gesetzt werden. Falls der Durchsatz des Teams nicht bekannt ist, wird weiter unten beschrieben, wie Sie diesen bestimmen.

Exkurs: Schätzungen in Kanban?
Im Gegesatz zu Scrum oder traditionellen Entwicklungsprozessen schätzen Kanban-Teams in der Regel Ihren Arbeitsaufwand nicht vorab. Kanban bricht stattdessen die Arbeit in kleinere Arbeitspakete herunter und benutzt die Durchlaufzeit als Metrik, um zu bestimmen, wie viele Aufgaben in einer Zeitspanne erledigt werden können.

Dieser Artikel behandelt zwar Kanban in seiner ursprünglichen Form, aber da Portfolio Schätzungen zum Terminieren von Plänen benötigt, nutzen wir gleich große Punkte als Basis. Mit ein bisschen simpler Mathematik auf Basis durchschnittlicher Durchlaufzeiten lassen sich akkurate Vorhersagen treffen. Falls Sie ein hybrides Kanban-System mit zeitbasierten Schätzungen benutzen, können Sie das Team auf *Kanban* schalten und Tag für Tag basierend auf den Wochenarbeitszeiten des Teams schätzen.

 

Keine Angst, falls Sie keinen Zeitplan sehen sollten. Wer Kanban einsetzt hat meist keine Schätzungen für Aufgaben zur Hand. Falls Sie von Neuem beginnen und Sie noch keine Vorgänge im Plan haben, wäre jetzt ein guter Zeitpunkt ein paar Tickets zu erstellen. Es lässt sich entweder auf einem höheren Level beginnen, indem zuerst Epics erstellt, die dann heruntergebrochen werden oder Sie listen einfach alle zu erledigenden Aufgaben als von Folge von Tasks auf. Falls Sie auf einer noch höheren Ebene als Epics planen, können Sie die Hierarchie in Portfolio for JIRA auch anpassen und um weitere Hierarchie-Ebenen ergänzen.

3. Den Durchsatz des Teams bestimmen

Der wichtigsten Wert den Portfolio For JIRA liefert, ist die Berechnung einer realistischen, datengestützten Zeitplanung für die Aufgaben Ihres Teams. Während der Algorithmus viele unterschiedliche Variablen benutzt, können alle Pläne auf Kosten, Umfang und Zeit reduziert werden. Diese Formel ist für Projektmanager nichts Neues. Kanban hat keine Sprints, demnach lässt sich nicht einfach die Definition von Velocity anwenden. Schätzungen werden ebenfalls in Kanban-Teams eher weniger genutzt, da jede Aufgabe den ungefähr gleichen Umfang aufweisen sollte. Wie können wir eine passende Metrik für langfristige Zeitplanung bestimmen?

Wir sollten mit einer realistischen Velocity, welche angibt, wie viel Arbeit Ihr Team in einer gewissen Zeitspanne zu leisten vermag, beginnen. Wir möchten den Durchsatz des Teams bestimmen, also die Anzahl an Aufgaben, die ein Team typischerweise in einer gewissen Zeit erledigen kann. Kanban-Teams, welche auf Story Points setzen können dies mithilfe ihrer Story Points bewerkstelligen, ansonsten lässt sich diese Zahl anhand der pro Woche erledigten Aufgaben ablesen. Falls Sie bereits mit JIRA Software arbeiten, können Sie diese Informationen aus Berichten ablesen. Mit dem Control Chart und Cumulative Flow Diagram lassen sich die Durchlaufzeit und in Arbeit befindlichen Pakete (Work in Progress-Items) ablesen. Umn de Durchsatz zu bestimmen, setzen wir auf Little’s Law: Durchsatz = Work in Progress / Durchlaufzeit .

Exkurs: Little’s law
Durchsatz = In Arbeit befindliche Aufgaben / Durchlaufzeit.
Nehmen Sie die durchschnittliche Durchlaufzeit einer Zeitspanne, die die zuverlässigste Annäherung der Teamleistung darstellt. Kalkulieren Sie einen Wochenfaktor auf Basis der Tage, bei einer durchschnittlichen Durchlaufzeit von 4 Tagen und 12 Stunden rechnet man mit 4.5 / 5 = 0.9. JIRA Software besitzt leider keine Funktion, um die durchschnittliche Durchlaufzeit automatisch zu bestimmen, deswegen muss man diese Metrik anhand eines Cumulative Flow Diagrams selbst annähern. Verfeinern Sie den Bericht mit den In Arbeit-Spalten (und allen weiteren Spalten dieser Art, wie Testing oder Review). In diesem Beispiel ist der durchschnittliche Work in Progress 8 Vorgänge zur selben Zeit. Daraus lässt sich der Durchsatz bestimmen 8/0.9 = 9. Der Durchsatz ist damit 9 und wird als Basis für die wöchentliche Velocity des Teams benutzt. Stellen Sie sicher, dass Sie diese Zahlen regelmäßig messen und validieren, damit Sie eine zuverlässige Zeitplanung erhalten.
portfolio-kanban-2

portfolio-kanban-3

4. Den Umfang bestimmen

Wer auf Kanban setzt, hat ungefähr gleich große Aufgabenpakete. Wir definieren 1 Story Point = 1 Vorgang, damit ist die Velocity des Teams äquivalent zum Durchsatz an Aufgaben. Für jeden Vorgang muss also ein Story Point zum Umfang des Plans hinzugefügt werden. Falls es Aufgaben geben sollte, die größer oder kleiner als sonst sind, kann dies durch herauf- bzw. herabsetzen der Schätzung dargestellt werden.

Beispiel: Falls eine Story nur die Hälfte der sonst üblichen Zeit in Anspruch nehmen wird, so setzt man deren Schätzung einfach auf 0.5. Falls man wohl doppelt so lange dafür braucht, setzt man die Schätzung auf 2.0. Wenn Sie jetzt die Zeitplanung berechnen, wird eine Vorhersage zu allen Vorgängen in der Planung bestimmt.

Bei der Schätzung von Epics, die noch nicht in Stories unterteilt wurden, liegt es an Ihnen zu schätzen, wie der ungefähre Aufwand bestimmt wird.

Atlassian arbeitet auch an Standard-Schätzungen (JPO-1483).

5. Meilensteine und Releases

Jetzt wo Portfolio for JIRA über alle Ressourcen und Umfänge informiert ist, muss der Abschnitt Zeit – genannt Releases – noch mit Informationen befüllt werden. Im Releases-Tab können Sie Releases und Meilensteine für jedes Projekt festlegen. Kanban-Releases sind eher ungeplanter Natur, da sie in der Regel einfach dann ausgeliefert werden, wenn ein Feature fertiggestellt ist. Falls dies bei Ihnen so gehandhabt wird, können Sie mithilfe der Dynamischen Release-Daten-Funktion Portfolio For JIRA automatisch bestimmen lassen, wann welches Feature zur Veröffentlichung bereit steht.

Vielleicht möchten Sie aber bestimmte Releases in gewissen Zeitrahmen festlegen. In diesem Fall lässt sich mit der fixen Endzeitpunkt-Funktion bestimmen, wann ein Arbeitspaket abgeschlossen sein muss. Portfolio For JIRA lässt Sie wissen, falls Sie in Gefahr laufen, ein bestimmtes Datum zu verpassen. Falls Sie davor stehen, eine Deadline zu verpassen, müssen Sie entweder den Umfang reduzieren oder mehr dem Team mehr Ressourcen zur Verfügung stellen. Portfolio For JIRAs einfache Commit/Rücksetz-Funktion für Änderungen lässt Sie ganz einfach mit „Was-Wäre-Wenn“-Szenarien spielen.

portfolio-kanban-4

6. Änderungen nach JIRA Software speichern

Bisher haben wir einen allgemeinen Zeitplan anhand von simplifizierten Daten des Teams bestimmt, um ein ungefähres Gefühl für die Auslieferungszeiten zu bekommen. Sind Sie mit dieser Granularität zufrieden, können Sie die Änderungen zurück nach JIRA Software speichern, um alle Planungsänderungen dem Team zugänglich zu machen. Hier steht es Ihnen frei, neue Vorgänge zu erstellen, die Priorität von Vorängen zu ändern, bestimmte Team-Mitglieder hinzuzufügen und ihnen bestimmte Vorgänge innerhalb des Portfolio-Plans zuzuweisen.

Mit Work Stages und Skills lässt sich die Planung noch viel detaillierter ausführen, Flaschenhälse visualisieren, Abhängigkeiten bestimmen und noch viel mehr.

Sobald Sie eine Änderung durchführen, lassen Sie Portfolio for JIRA einfach die Vorhersage für den Zeitplan aktualisieren und lassen die Änderungen zurück nach JIRA Software schreiben. Dank der „Was-Wäre-Wenn“-Szenarien in Portfolio, lassen sich Vorhersagen für Kanban-Pläne treffen. Sie können auch Kanban und Scrum im gleichen Plan verwenden – dies ermöglicht Ihnen maximale Flexibilität in der Planung.

Fragen? Wir helfen gerne!