Dieser Beitrag ist auch verfügbar auf:
In einer Serie von Beiträgen dieses Blogs möchte ich auf eine zentrale Frage von Stakeholdern eingehen, die POs und Scrum-Teams oft hören: „Wann wird das denn fertig?“ In deren Verlauf stelle ich hier ein mini-Framework für eine empirische Produktziel-Planung für Scrum vor. Dieses wird gerade in mehreren Teams und Projekten entwickelt und getestet, zusammen mit mehreren Agile Coaches und POs.
Bevor ich auf die Details eingehe, möchte ich die Eigenschaften der Lösung skizzieren. Warum? Weil diese sehr gute Argumente liefern, die helfen, den PO von diesem Verfahren zu überzeugen. Denn, obwohl vor allem der Kunde davon profitiert: der PO ist die zentrale Person dabei, ohne die es sich nicht umsetzen und wirksam werden lässt.
Empirische Produktziel-Planung für Scrum direkt über das Product-Backlog
Fokus unseres Ansatzes ist es, eine Planungsansicht für den Stakeholder, den PO und das Scrum-Team bereitzustellen. Diese soll mit möglichst geringem Aufwand ständig aktuelle Informationen über die Priorisierung und den voraussichtlichen Fertigstellungszeitpunkt größerer Vorhaben (aka „Produktziele“) des Scrum-Teams liefern.
In unseren Projekten hat sich JIRA als Koordinations- und Planungstool bewährt. Daher gebe ich hier ein Beispiel, wie wir es mit JIRA umsetzen konnten, eine solche Planungsansicht auf Epic-Ebene bereitzustellen:
Genauso könnte man hier auch noch größere Planungsebenen darstellen, wie „Initiativen“ etc.
Der Charme dieser Darstellung und unseres Konzeptes für
- die Stakeholder: die Darstellung ist intuitiv zu verstehen. Auf einen Blick ist erkennbar, wann welches größere Vorhaben voraussichtlich fertig wird
- den PO: Änderungen an der Priorisierung im Product Backlog sind sofort sichtbar in der Dashboard-Darstellung. Außer einem – gut gepflegten – Product Backlog und etwas Disziplin und Fokus bei der Einplanung von Aufgaben wird kein weiteres Tool benötigt, um diese hochtransparente Darstellung zu erreichen.
- den Scrum Master: es wird keine separate App oder aufwendige Programmierung und Pflege benötigt. Die technische Umsetzung gelingt einfach mit Bordmitteln von JIRA; mit simplen Filtern und dem Product Backlog. Etwas Arbeit ist jedoch regelmäßig nötig, um Kapazitätsberechnungen für zukünftige Sprints zu machen, und um den PO beim Planungsprozess zu unterstützen. Insbesondere bei der Einführung des Konzeptes.
- das Scrum Team: es bekommt idealerweise Produktziele, zusammengefasst durch einzelne oder alle der dort dargestellten „großen“ Aufgaben, übersichtlich präsentiert. Es gewinnt damit wertvolle Informationen über die Ziele des PO. Dazu muss das Team nichts tun, was es nicht sowieso machen sollte. Insbesondere soll es den PO beim Refinement und bei der Planung und Priorisierung von Aufgaben im Product Backlog unterstützen.
Diese Dashboard-Ansicht lässt sich sowohl für Cloud-JIRA, als auch für die On-Premise-Version von JIRA analog umsetzen.
Die Lücke in der empirischen Projektplanung bei agilen Projekten
Für mich ist eine empirische Projektplanung eine Art „heiliger Gral“ für agile Projekte. Und eines ihrer größten Schwachstellen und „Lücken“ in der Praxis. Dort, wo ich als Coach tätig war, wurde eine Vorhersagbarkeit in der längerfristigen Planung immer wieder gefordert von den Auftraggebern, aber nie empirisch bereitgestellt. Meist spricht der PO mangels empirischer Daten „aus dem Bauch heraus“. Oder es werden „Schätz-Workshops“ durchgeführt, um die „Erfahrung“ des Teams mitzunehmen, wann größere Dinge (oft bezeichnet als „Epics“), fertig werden. Oder die Planung wird vom PO als „Wasserfall-Vorgehen“ abgetan und ganz verworfen („Warum planen, wir sind doch agil!“). Ferner sind planungsrelevante Informationen oft auf viele Quellen verteilt, statt im Product Backlog zusammengefasst zu sein.
Wenn eine Planung vorliegt, findet nur Weniges davon sich später im Product Backlog wieder. Und nur Weniges wird rechtzeitig gepflegt, wenn sich neue Erkenntnisse ergeben. Im Product Backlog kann man oft froh sein, wenn zumindest für den folgenden Sprint eine mehr oder weniger realistische Planung vorliegt – meist planen die Teams dort viel zu optimistisch.
Das Ergebnis oben beschriebener Methoden ist daher eher statisch und potentiell erratisch. Denn es hat nur wenig oder nichts mit der empirischen Realität zu tun, auf deren Basis wir in Scrum-Projekten entscheiden sollten. Eher erinnert es an einen „optimistischem Blindflug“ durch die Wolken des agilen Himmels.
Ein neuer agiler Fokus auf die Produktziel-Planung für Scrum
Tatsächlich scheint dieses Problem auch vielen Agile Coaches bisher nicht bewusst oder wichtig zu sein. Meiner Erfahrung nach fokussieren sich diese eher auf die kurzfristige Vorhersagbarkeit im Rahmen des jeweils nächsten Sprints, aber kaum darüber hinaus. Dies wird oft rein in der Domäne des PO gesehen, aber ohne konkrete Ideen, ihn dabei zu unterstützen. Und ja, auch ich habe jahrelang kein „Rezept“ gefunden, um diese Problematik gut anzugehen.
Was ich nun konkret bei einigen Teams unterstütze einzuführen: eine empirisch gestützte Projektplanung und Produktziel-Planung für Scrum über sechs 2-Wochen-Sprints (oder über 4-5 Sprints bei monatlichen Sprints). Natürlich ist die Anzahl der in die Zukunft interpolierten Sprints erstmal ein Parameter. Wir experimentieren aktuell mit der konkreten Länge: Sie soll einen für die Stakeholder ausreichenden Zeitraum abdecken. Und gleichzeitig nicht so lange sein, dass die Vorhersagbarkeit zu schlecht wird oder der – potentiell nicht wertschaffende – Planungsaufwand zu groß.
Details zur konkreten Umsetzung folgen… bald!
Unser Konzept zur Umsetzung ist so klar beschreibbar, dass man die Kernelemente einem PO oder Coach in ca 20 Minuten erklären kann. Es nachzuhalten, und die Feinheiten und Zusammenhänge dauerhaft zu etablieren, erfordert jedoch eine weitergehende Begleitung und Einsicht und würde diesen Artikel sprengen. Wie die hier skizzierte Produktziel-Planung für Scrum konkret funktioniert, beschreibe ich daher auch nicht gleich in diesem ersten Artikel, sondern schrittweise in den nächsten Wochen. Natürlich werden auch konkrete Fallstudien mit unseren Teams nach und nach hier im Blog veröffentlicht. Bereits zu den ersten Eindrücken, lieber Leser – liebe Leserin – die dieser Artikel hinterlassen hat, freue ich mich aber über Fragen und Anregungen!
WERBUNG in eigener Sache: Möchten Sie eine Unterstützung durch einen agilen Coach? Dies ist bereits ab ca einem Tag pro Woche möglich, durch Rolf Wendolsky & Partner. Wir bieten über unsere Digitalagentur JonDos ferner das Staffing und den Aufbau ganzer Entwicklungsteams für ihre Projekte an. Vorzugsweise organisiert als Scrum-Teams, aber nicht nur: wir haben auch viel Erfahrung in der agilen Organisation „kleiner“ „Teilzeit“-Projekte mit nur 2-3 Entwicklern.