Planung findet im Geschäftskontext auf ganz unterschiedlichen Ebenen statt. Sie reicht von der Ebene strategischer Planung bis hinunter zur Tagesplanung. Dabei ist von zentraler Bedeutung, dass Planung auf jeder Ebene immer mit jener auf den darüberliegenden Ebenen vereinbar ist. So wird eine Firma keine Produkte entwickeln, welche ihrer Unternehmensstrategie zuwiderlaufen. Dieses Prinzip der Planung auf verschiedenen Ebenen wird oft auch in einem zwiebelförmigen Schalenmodell dargestellt. Die Schale strategischer Planung umschliesst die darunterliegenden, welche im agilen Kontext oft mit Portfolio, Produkt, Release, Sprint (oder Iteration) und Tag überschrieben werden.
Was Sie hier lernen:
Die Planungszwiebel
Die Planning Onion ist ein sehr eingängiges Bild, um darzustellen, wie jede Planungsentscheidung auf einer Ebene sich wiederum auf die benachbarten Ebenen auswirkt. Auch hier spielten Feedback-Loops zwischen den verschiedenen Ebenen mit. Dabei ist wichtig zu verstehen, dass nicht alle Planungsebenen von denselben Personen verantwortet werden. Während die Strategie- und Portfolioplanungen meist von der Geschäftsleitung oder nahe daran angesiedelten Rollen wahrgenommen werden, fallen die darunterliegenden Ebenen zumindest teilweise in den Aufgabenbereich von Mitgliedern des Scrum-Teams.
Release-Planung
Abhängig vom entwickelten Produkt und anderen Umgebungsfaktoren kann Releaseplanung sehr unterschiedlich aussehen. Finden in manchen Projekten stündlich mehrere Releases statt, tun sich manche anderen Projekte schon schwer damit, jährlich einen Release herauszubringen. Ein wichtiger Gesichtspunkt bei der Planung von Releases stellt insbesondere die Fähigkeit und Möglichkeit des Kunden (und Endbenutzers) dar, den Release zu nutzen und entsprechendes Feedback zu geben, welches es erlaubt, daraus zu lernen und die erzielten Lehren wiederum für eine wertoptimierte Weiterentwicklung des entstehenden Produktes zu nutzen. Wo immer möglich werden kurze Releasefolgen bevorzugt, da damit ein früheres Feedback von den Endbenutzern erreicht werden kann.
Die Releaseplanung wird oft vom Produkt Owner verantwortet und meist auch selbst in Absprache mit dem Kunden durchgeführt. Dabei kann der Kunde ein externer Kunde oder ein interner Kunde in der eigenen Organisation sein. In letzterem Fall wird die Rolle des Kunden oft durch das Programm oder Portfolio-Management wahrgenommen.
Wie es der Rolle des Product Owners entspricht, ist dabei ein zentraler Gesichtspunkt für den Kunden, schnellstmöglich einen maximalen Geschäftswert zu generieren. Genauso wie auf der Ebene der Einzelanforderungen solche Backlog Items mit hoher Wertschöpfung für den Kunden priorisiert werden, geschieht dies auch mit den Releases und ihren Inhalten.
In vielen Fällen hat es sich im Kontext von Scrum-Entwicklungsprojekten als erfolgreich erwiesen, etwa alle 3 Monate einen Release auszuliefern. Damit wird in vielen Fällen ein guter Kompromiss zwischen der Belastung des Kunden und dem Wunsch nach zusätzlichem Feedback für die Produktoptimierung gefunden.
Wie jede agile Planung ist auch die Releaseplanung flexibel und jederzeit basierend auf Feedback und Erkenntnisgewinn anpassbar. Entsprechend gilt es auch beim Aufwand für die Releaseplanung einen Just-in-Time-Ansatz zu nutzen und die Planungstiefe immer auf einer angebrachten Detaillierungsebene zu belassen. Entsprechend hält die Releaseplanung oft nur ein angegangenes «Thema», geplante Releasedaten und die wichtigsten enthaltenen Features fest. Dies ist auch jene Ebene, auf welcher Releases kommuniziert werden sollten. Wer sich bei der Kommunikation von Releaseplänen in Details verliert, läuft Gefahr, diese laufend aktualisieren und korrigieren zu müssen.
Ein Release umfasst immer mindestens einen, meistens aber mehrere Sprints, wohingegen ein Sprint immer nur einem Release zugeordnet werden kann.
Sprint-Planung
Die Planung der einzelnen Sprints erfolgt während des Sprint Planungs-Meetings zu Beginn jedes Sprints. In ihm werden das Sprint-Ziel gesetzt, die Backlog Items für den Sprint ausgewählt und ihre Umsetzung geplant.
Sprint-Abbruch und Auswirkung auf die Planung
In seltenen Fällen kann es notwendig werden, einen Sprint frühzeitig abzubrechen. Dies darf nicht leichtfertig geschehen, bedeutet doch jeder Sprint-Abbruch eine Störung des kontinuierlichen Entwicklungsprozesses und hat damit auch Auswirkungen auf die kommende Weiterentwicklung. Daneben bedeutet ein frühzeitiger Abbruch eines Sprints auch die Notwendigkeit, auf allen Ebenen (Releaseplanung, Planung der verschiedenen Sprint-Events etc.) Anpassungen vorzunehmen. Aus diesem Grund beschreibt der Scrum-Guide als einzigen valablen Grund für den Abbruch eines laufenden Sprints die Situation, wenn eine Fortführung des Sprints keinen Sinn mehr macht (engl. «obsolete»). Die entsprechende Entscheidung kann ausschliesslich der Product Owner treffen.
