Auf die Plätze, fertig, los und rein in den Sprint! Oder lieber einen Plan machen? Im folgenden Blogbeitrag erkläre ich Dir ganz genau wie eine professionelle Scrum-Sprintplanung abläuft. Bevor wir in die Theorie einsteigen, erläutere ich kurz das Szenario anhand dessen ich Dir die Abfolge der Planung näherbringen werde: Stell Dir vor, ein Projektteam in einer fremden Galaxie hat die Aufgabe den Millennium Falken aus Star Wars mit Lego nachzubauen - und der soll technisch gesehen intergalaktische Ausmaße haben. Das ist also die Aufgabe und natürlich klingt das für uns hier auf dieser Welt zuerst einmal recht banal - ist aber gar nicht so einfach zu bewältigen, wie Du gleich feststellen wirst. Also may the force be with you und viel Spaß beim Lesen!
Die vier Scrum-Events, die einen für Scrum typischen Ablauf beschreiben sind: Sprintplanung, Sprint-Review, Sprint-Retrospektive und Daily Scrum. Jedes dieser Events bietet die Möglichkeit, die Scrum-Artefakte zu inspizieren und adaptieren. Die Events sorgen für die dafür benötigte Transparenz.
Nun zu unserem Projekt-Szenario: Der Bau des technisch einmaligen Millennium Falken aus Lego ist ein großer Aufwand, der mit hohen Kosten und vielen Unsicherheiten verbunden ist: Lässt sich im Raumschiff der moderne Hyperantrieb installieren mit dem man sich schnell zwischen Galaxien bewegen kann? Ist die Materiallieferung (es wird sehr sehr viel Lego und anderes Equipment benötigt!) sichergestellt oder kann es auf irgendwelchen Planeten zu Lieferengpässen kommen? Haben die rechtschaffenden Planer*innen ausreichend Rücklagen, um einen jahrzehntelangen Bau finanzieren zu können oder besteht die Gefahr, dass vorher schon das Geld und die notwendigen Ressourcen zur Neige gehen? Verfügen das Team und die Auftraggebenden über das notwendige Know-how für den Bau des Falken oder müssen Externe überzeugt werden beim Bau zu unterstützen? Wie wird später die Versorgung für die Besatzung sichergestellt?
Über diese Schwierigkeiten und Herausforderungen hinaus ist weiter Folgendes gesetzt: Das "Product Goal", also das Ziel das mit dem Millennium Falken erreicht werden soll, sieht wie folgt aus: “Mit dem Falken sichern wir unsere Existenz und das Wachstum des Widerstandes, in dem wir schnell andere Welten erreichen.”
Soviel zur Ausgangssituation. Mit der Sprintplanung startet nun der Sprint. Ziel ist es, mit dem gesamten Team die Aufgaben für den kommenden Sprint zu identifizieren und zu planen.
Der Product Owner stellt sicher, dass alle Teilnehmenden vorbereitet sind, um über die wichtigsten Product Backlog Items zu sprechen. Andere Teilnehmende können vom Scrum Team eingeladen werden, um benötigte Informationen bereitzustellen.
In der Sprintplanung werden drei Fragen beantwortet. Welchen Wert bringt dieser Sprint? Was kann in diesem Sprint erreicht werden? Wie werden wir die gewählte Arbeit fertigstellen?
Der Product Owner erklärt, wie das Produkt seinen Wert im nächsten Sprint erhöhen kann. Anschließend arbeitet das gesamte Team gemeinsam daran, ein Sprint Goal festzulegen, das aussagt, welchen Wert dieser Sprint für die Stakeholder hat. Das Sprint-Goal muss dabei nicht direkt zu Beginn perfekt ausformuliert sein und kann im Laufe der Sprintplanung verfeinert werden. Vor Abschluss der Sprintplanung muss es jedoch final sein und das ganze Team sich darauf committen.
Im Gespräch mit dem Product Owner wählen die Entwickler Items aus dem Backlog, um sie in den kommenden Sprint aufzunehmen. Dabei besteht die Möglichkeit, dass die Items vom Scrum Team weiter verfeinert werden, um das Verständnis zu erhöhen.
Im letzten Schritt planen die Entwickler für jedes ausgewählte Item die notwendige Arbeit, um ein Inkrement zu erschaffen, welches der Definition of Done entspricht. Häufig werden die ausgewählten Items dafür in kleinere, konkrete Arbeitsschritte aufgebrochen. Wie etwas umgesetzt wird, liegt dabei komplett bei den Entwicklerinnen. Niemand schreibt jenen vor, wie ein nutzbringendes Inkrement aus den gewählten Items gemacht wird.
Das Sprintziel, die ausgewählten Item und der Plan, wie diese ausgeliefert werden, bilden zusammen den Sprint-Backlog.
Die Time-Box einer Sprintplanung ist 8 Stunden bei einem vierwöchigen Sprint. Bei kürzeren Sprints ist die Sprintplanung gewöhnlich auch kürzer.
Zurück also zu unserem Fallbeispiel: Das Ziel im ersten Sprint ist wie erklärt ein potenziell releasebares Inkrement. In unserem "Lego Millennium Falken Modell Beispiel" bedeutet dies, dass wir im ersten Sprint überlegen, was den rechtschaffenden Bewohnerinnen der freien Welten bereits jetzt einen Wert bringt und uns helfen kann unsere Annahmen zu validieren. Das Team legt sich im ersten Sprint auf das folgende Sprint-Goal fest: “Wir bauen einen Antrieb, der so stark ist, dass niemand unseren Raumschiffen folgen kann”. Es entscheidet sich also, den “Hyperraumantrieb” zu bauen, mit dem man den Raumschiffen des Imperiums entkommen und sich sogar schnell zwischen den Galaxien bewegen kann, wenn notwendig. Auch wenn der Antrieb noch nicht vollständig entwickelt ist und sich nur mit normaler Geschwindigkeit bewegt, können damit direkt mehrere Annahmen validiert werden: Reicht die Kraft des Hyperantriebs überhaupt, um einen (wenn auch kleinen) Planeten zu erreichen? Wenn nein, braucht man den Rest auch gar nicht mehr zu bauen und spart die jahrzehntelange Arbeit nur um dann festzustellen das der Antrieb gar nicht funktioniert. Hat dieser Antrieb bereits eine “überzeugende” Wirkung auf die Imperialen mit ihren Bestrebungen, alle Kommunikationsschiffe der Rebellen zu sabotieren. Wenn hier im Gespräch mit den Stakeholdern festgestellt wird, dass der Bau eines solchen Hyperantriebs eine eher gegensätzliche Wirkung zur Folge hat, ist anzunehmen, dass später Gruppierungen des Imperiums relativ schnell versuchen werden, diese Technologie zu zerstören, was im schlimmsten Fall zum Scheitern der gesamten Mission der freien Völker führen kann. Da die Gespräche mit den Stakeholdern nach dem ersten Sprint gezeigt haben, dass der Antrieb in der Tat eine imposante Wirkung hat, aber viele Stakeholder die Technik mit Lichtgeschwindigkeit noch nicht in den eigenen Schiffen einsetzen können, entscheidet sich das Team den bisherigen "Hyperantrieb" updatefähig zu gestalten und den Antrieb später bei Bedarf direkt mit einem Softwareupdate auszustatten, das die Raumschiffe mit Lichtgeschwindigkeit fliegen lassen kann. Als Sprint-Goal für den zweiten Sprint wird festgelegt: “Der bisherige Hyperantrieb soll updatefähig sein und auch von weiteren Raumschiffen eingesetzt werden, damit diese ebenfalls schnell den imperialen Gefahren entkommen können.”
Während des zweiten Sprints kommt es allerdings zu Problemen. Ein Lieferant, der für die Bereitstellung eines wichtigen Softwareanteils des Hyperraumantriebsoftwareupdates zuständig ist, kann zum gegebenen Zeitpunkt nicht liefern. Da der "Hyperantrieb" in diesem Sprint deshalb nicht mehr wie geplant updatefähig gemacht werden kann, überlegt das Team, welche Alternativen bestehen, um das Sprint-Goal doch noch zu erreichen. Nach dem Motto “Wenn wir den Antrieb schon nicht updatefähig bekommen, dann modifizieren wir ihn zumindest für den Einsatz in weiteren Raumschiffen” entscheidet sich das Team, die Benutzeroberfläche des "Hyperraumantriebs" so zu optimieren und Anpassungen vorzunehmen, dass der Antrieb in jedem anderen gewöhnlichen Raumschiff eingesetzt werden kann. Durch diese Entscheidung wird das Sprint-Goal “Der Hyperantrieb soll auch von weiteren Raumschiffen eingesetzt werden, damit auch diese schnell den imperialen Gefahren entkommen können.” erreicht, weil der Hyperantrieb jetzt auch in weiteren Raumschiffen eingesetzt werden kann, noch nicht aber direkt in den Schiffen der Stakeholder, wie eingangs geplant.
Vor dem dritten Sprint kommt die Cheftruppe der Rebellionsbewegung mit einer schlechten Nachricht auf das Team zu. Mehrere der Planeten haben keine Rohstoffe oder monetäre Mittel mehr, um das Projekt zu unterstützen, weshalb die Finanzierung der Updatefähigkeit und der Hyperraumfunktion nicht ausreichend gesichert ist. Der Product Owner entscheidet sich deshalb das Inkrement zu releasen. Da das Team in den letzten Sprints jedes Mal ein wertiges Inkrement geliefert hat, ist es kein Problem das Produkt jetzt schon zu veröffentlichen. Bis jetzt besteht das Inkrement aus einem "Hyperraumantrieb" der in jedem Raumschiff aufgebaut werden kann. Der Product Owner überlegt gemeinsam mit den Stakeholdern wie damit Geld verdient werden kann und entscheidet den "Hyperantrieb" an Raumschiffe als Antriebssystem zu vermieten. Weil der "Hyperraumantrieb" eine so mächtige Entwicklung ist, erfreut er sich auf vielen Planeten großer Beliebtheit und die Vorbestellungen gehen durch die intergalaktische Decke (soweit vorhanden). Dank der Einnahmen kann jetzt die Weiterentwicklung der Update- und Hyperraumfunktionalität für die Schiffe der Stakeholder finanziert werden. Wenn das Team nicht agil, sondern z.B. nach einem Wasserfallmodell gearbeitet hätte, wäre es zum einen durch den Lieferengpass vollumfänglich blockiert gewesen und die ganze Entwicklung hätte sich nach hinten verschoben und zum anderen hätte nach dem Aus der Finanzierung nur ein unfertiges und unbrauchbares Modell vorgelegen, mit dem niemand irgendwelche Einnahmen hätte erzielen können. Vielleicht wäre im späteren Entwicklungsverlauf aufgefallen, dass die Bordnetzarchitektur nicht mit dem neuen Raumschiff-Modell mit Hyperantrieb kompatibel ist und das ganze Grundgerüst deshalb neu geplant hätte werden müssen. Eventuell stellen die rebellischen Auftraggebenden auch während der Entwicklung fest, dass die Ziele auch auf einem anderen Weg erreicht werden können, z.B. durch mehrere ganz kleine Millennium Falken, um ein Klumpenrisiko bei einem Systemausfall oder die Zerstörung bei einem einmaligen Kampf zu vermeiden.
Aktuell jedenfalls sind alle Stakeholder in höchstem Maße zufrieden mit unseren Entwicklungen - und wer weiß? Eventuell heißt es ja bald: May the agile force be with you.
Übrigens: Alle weitere Methoden und Tools wie User Stories, Epics oder Story Points sind Complementary Practices. Das bedeutet Praktiken, welche den Scrum Guide ergänzen. Jedes Team sollte dabei seine eigenen Best Practices finden. Was in den einem Team gut funktioniert, ist vielleicht für ein anderes Team weniger geeignet. Auch her sind Experimente erwünscht. Mit dem Ziel, die Zusammenarbeit des Teams zu stärken und die Empirie zu fördern, können neue Techniken mit dem Team ausprobiert und erprobt werden. Das Beispiel mit dem Lego Millennium Falken kommt übrigens nicht von ungefähr: Mithilfe von Lego™ Serious Play™ begleiten meine Mitarbeitenden Teams und Organisationen als Facilitator bei der Findung von Strategien und Visionen. Ein gemeinsames Verständnis ist besonders in einem agilen Umfeld wichtig, um seine Entscheidungen und sein Handeln nach diesem auszurichten.
Wie Du gesehen hast, ist die Sprintplanung eine wichtige Installation innerhalb von Scrum. Wenn Du konkrete Fragen zu Deiner Sprintplanung hast, mehr über die Complementary Pracitces lernen oder einmal gemeinsam mit mir einen Sprint planen möchtest, schreibe mir eine Nachricht oder füge mich Deinem LinkedIn-Netzwerk hinzu. Selbstverständlich folgen demnächst auch weitere Blogbeiträge zu den Themen Scrum und Agile nach - bleib dran!