Scrum-Projekte planen mit System

Teil 1:
Besonderheiten und Voraussetzungen

Genau wie in traditionellen Projekten nimmt auch in Scrum die Planung eine zentrale Rolle ein. Allerdings wird dort auf eine längere vorgelagerte Planungsphase verzichtet, stattdessen findet die Planung größenteils parallel zur Entwicklung statt. Dominik Maximini stellt im ersten Teil des Beitrags das Vorgehen bei der Planung kurz vor, beleuchtet Besonderheiten und zeigt Fehler auf, die in der Praxis häufig gemacht werden. Der zweite und abschließende Teil beschreibt das Vorgehen ausführlich an einem praxisnahen Beispiel.

DownloadDownload

Artikelserie

  1. Besonderheiten und Voraussetzungen
  2. Vorgehen in der Praxis

Scrum-Projekte planen mit System

Teil 1:
Besonderheiten und Voraussetzungen

Genau wie in traditionellen Projekten nimmt auch in Scrum die Planung eine zentrale Rolle ein. Allerdings wird dort auf eine längere vorgelagerte Planungsphase verzichtet, stattdessen findet die Planung größenteils parallel zur Entwicklung statt. Dominik Maximini stellt im ersten Teil des Beitrags das Vorgehen bei der Planung kurz vor, beleuchtet Besonderheiten und zeigt Fehler auf, die in der Praxis häufig gemacht werden. Der zweite und abschließende Teil beschreibt das Vorgehen ausführlich an einem praxisnahen Beispiel.

Wir empfehlen zum Thema Agile
PM Welt 2023: Mutig handeln in unsicheren Zeiten

Wie gehe ich mit den Herausforderungen fehlender Planbarkeit und Unsicherheit um? Welche Kompetenzen, Methoden und Tools sind gefordert, um sich mutig und sicher den Herausforderungen der Zukunft zu stellen? Diese und weitere spannende Themen erleben Sie am 4. Mai 2023 in München bei der PM Welt, unserer Projektmanagement-Konferenz. Seien Sie dabei! Mehr Infos

Scrum wird in immer mehr Software-Projekten jeder Größe eingesetzt. Dabei ist natürlich auch die Planung wesentlich, allerdings verschiebt sich im Vergleich zu traditionellen Ansätzen der Zeitpunkt dafür – denn anstatt einer langen, vorgelagerten Planungsphase erfolgt in Scrum die Planung hauptsächlich rollierend und parallel zur Entwicklung. Leider messen aber selbst erfahrene Scrum-Anwender der Planung oft zu wenig Bedeutung bei, denn häufig hört man Aussagen wie: "Wir sind agil, wir brauchen keine Planung!", oder: "Das Agile Manifest sagt, dass wir auf Veränderungen reagieren und keinem Plan folgen müssen!"

Beide Aussagen sind falsch und führen im schlimmsten Fall dazu, dass die unzureichend geplanten Projekte am Ende scheitern. Typische Fehler bei der Planung sind, dass z.B. ohne klares Ziel gestartet wird oder keinerlei Aufwandsschätzung erfolgt. Ohne Aufwandsschätzung lässt sich jedoch die Velocity, also die Geschwindigkeit des Teams, nicht ermitteln und man erreicht in der Folge auch keine Prognosesicherheit. Kommt dann die Nachfrage des Geschäftsführers, wie gut sich das Team macht, und ob die angestrebte Produktivitätssteigerung erreicht wurde, ist wieder Unschuldslächeln und Achselzucken angesagt, da man ja keine Vorstellung davon hat, wie aufwändig die drei umgesetzten Features relativ zu den noch ausstehende sieben waren.

In diesem zweiteiligen Artikel zeige ich, wie sich die Planung in Scrum strukturiert durchführen lässt und welche Besonderheiten es dabei zu berücksichtigen gilt. Weiter möchte ich auf typische Fallstricke eingehen, denen man in der Praxis oft begegnet. Ziel ist, die Komponente "Planung" für fortgeschrittene Scrum-Anwender näher zu beleuchten. Der erste Teil stellt kurz das Vorgehen vor und beleuchtet Besonderheiten bzw. Fehler, die häufig in der Praxis gemacht werden. Der zweite Teil beschreibt ausführlich das Vorgehen an einem praxisnahen Beispiel.

Neun Planungsschritte in Scrum

Scrum sieht neun Planungsschritte vor, die sich je nach Zielsetzung in strategische und operative Planung unterteilen lassen (zur näheren Erläuterung s. Abschnitt "Operative und strategische Planung"). Nachfolgend stelle ich die Schritte kurz vor; im zweiten Teil werde ich diese an einem Praxisbeispiel näher erläutern. Die Planungsschritte sind im Einzelnen:

  1. Die Geschäftsführung definiert mit dem Product Owner die Produktvision (strategische Planung).
  2. Der Product Owner definiert die Releaseziele zusammen mit den Stakeholdern (strategische Planung).
  3. Der Product Owner definiert die Sprintziele zur Erreichung des aktuell anstehenden Releaseziels (strategische Planung).
  4. Der Product Owner trägt die benötigten Features im Product Backlog ein (strategische Planung).
  5. In der ersten Hälfte des Sprint Plannings stellt der Product Owner dem Team diese Ziele vor. Das Team wählt sich eine Untermenge an Features aus dem Product Backlog aus, die es umsetzen will (operative Planung). Ggf. werden die Sprintziele nochmals angepasst oder Features im Product Backlog geändert.
  6. In der zweiten Hälfte des Sprint Plannings plant das Team präzise auf Taskebene, wie es sein Sprintziel erreichen möchte (operative Planung).
  7. Die Planung wird täglich, spätestens während des Daily Scrums, überprüft. Abweichungen werden an den ScrumMaster adressiert und an den Product Owner kommuniziert (operative Planung).
  8. Am Ende des Sprints wird im Sprint Review das Produkt inspiziert. Hier planen Product Owner, Entwicklungsteam und Stakeholder gemeinsam, welche Veränderungen im Product Backlog nötig sind, um das Releaseziel zu erreichen (strategische Planung).
  9. In der Retrospektive wird ermittelt, wie das Team noch effizienter arbeiten kann (strategische Planung).

Wesentliche Voraussetzungen für die Planung

Alle Planungsschritte wiederholen sich regelmäßig in jedem Sprint. Die Anzahl der notwendigen Änderungen variiert allerdings stark: Produktvision und Releaseziel ändern sich wesentlich seltener als die Sprintziele. Trotzdem wird ihre Gültigkeit ständig durch den Product Owner überprüft. Die operativen Planungsartefakte werden jeden Sprint komplett neu erstellt und können täglich im Daily Scrum geändert werden.

Jeder muss seine Rolle ausführen können

Übergreifend gilt für alle oben beschriebenen Schritte, dass für eine erfolgreiche Planung die richtigen Fähigkeiten an den richtigen Stellen vorhanden sein müssen. Das bedeutet, dass die Rollen mit dafür geeigneten Personen besetzt und diese zur Erfüllung ihrer Aufgaben auch ermächtigt werden müssen. Nur wenn ein Product Owner beispielsweise Entscheidungen treffen darf, kann er seine Rolle korrekt ausfüllen. Ähnlich verhält es sich mit dem Entwicklungsteam: Nur wenn es ohne äußere Einflussnahme wählen kann und darf, wie viele Features es im anstehenden Sprint umsetzen möchte, ist es fähig, nach Scrum zu arbeiten.

Scrum lernt

Scrum ist ein empirisches Modell – es lernt aus der Vergangenheit. Das bedeutet auch, dass mit der Zeit die Prognosesicherheit steigen wird. Ein eingespieltes, erfahrenes Team, das an einem Produkt arbeitet, das es kennt, liefert letztendlich auch sehr verlässliche Vorhersagen darüber, wie viele Features es in einem Sprint schaffen wird. Kennt sich das Team jedoch nicht und ist auch das Produkt für die Entwickler neu, so ist eine Vorhersage in der Regel äußerst ungenau. Optimieren Sie Ihre Prognosesicherheit, indem Sie ein erfolgreiches Entwicklungsteam zusammen lassen und auch das Produkt, an dem dieses Team arbeitet, nur dann ändern, wenn dies unter Berücksichtigung aller Faktoren unbedingt notwendig ist.

Schnelle und direkte Kommunikation – kein "Tooling"

Auch sollte man sich bewusst sein, dass Kommunikation wichtiger ist als "Tooling". Sich schnell verändernde Umgebungen, wie sie bei der Softwareentwicklung die Regel sind, erfordern zeitnahe (mindestens tägliche) und zielgerichtete (persönliche und fokussierte) Kommunikation. Kein Werkzeug kann diese ersetzen. Zwar können die richtigen Werkzeuge den Planungsprozess unterstützen, jedoch kann nur das, was auch mit Papier funktioniert, in einem Tool klappen. In einigen Fällen enthalten Tools sogar Beschränkungen, die es Ihnen verbieten, die Planung so durchzuführen, wie Sie es für richtig halten. Achten Sie daher darauf, grundsätzlich nur flexible und von Ihren Mitarbeitern anpassbare Werkzeuge einzusetzen.

Dazu ein Beispiel aus der Praxis: Ein Unternehmen beschäftigte sich mehrere Monate damit, ein sehr mächtiges Tool zur Modellierung und Ausführung der Workflows einzuführen. Nach der Einführung, stellte das Unternehmen fest, dass die Mitarbeiter diese Workflows nicht nutzten. Eine Analyse zeigte, dass wichtige Faktoren nicht berücksichtigt worden waren, insbesondere Ausnahmeregelungen und bewusste Prozessverletzungen ließen sich nicht abbilden. Also begann man damit, die Prozesse auf Papier zu zeichnen und durch physische Artefakte wie Karten und Boards zu unterstützen. Davon ausgehend optimierte das Unternehmen seine Prozesse und schon bald erfreute sich dieses Vorgehen großer Beliebtheit. Das Workflow-Tool wurde nie wieder eingesetzt, da man feststellte, dass es zu vielen Restriktionen unterlag; man stritt sich mehr um die Möglichkeiten und Unmöglichkeiten der Software als um die produktive Arbeit.

Besonderheiten der Planung in Scrum

Scrum verzichtet auf eine lange und vollständig vorgelagerte Planungsphase. Während beim traditionellen Vorgehen durchaus mehrere Monate – manchmal sogar Jahre – geplant wird, bevor die erste Zeile Code geschrieben werden darf, legt Scrum den Schwerpunkt auf den frühen Beginn der Implementierung. Dazu muss zwar auch in einem gewissen Maß vorab geplant werden, allerdings reicht ein Sprint bereits als Vorlaufzeit aus – dieser lässt sich auch als "Sprint 0" bezeichnen.

Die Dauer dieses Sprints ist abhängig von den noch ausstehenden Aufgaben und beträgt oft nur zwei, maximal vier Wochen. Product Owner, ScrumMaster und Entwicklungsteam nutzen ihn dafür, die Infrastruktur vorzubereiten und die strategische Planung durchzuführen. Am Ende von Sprint 0 sind alle Beteiligten arbeitsfähig – oft bewiesen durch die Implementierung eines ersten winzigen Features – und verfügen über Releaseziele, Sprintziele und ein geschätztes initiales Product Backlog. Der Sprint 0 endet mit der operativen Planung des ersten "richtigen" Sprints.

Während der gesamten Projektlaufzeit erfolgt die Planung im Unterschied zu traditionellen Planungsmethoden parallel zur Umsetzung, wobei man zwischen strategischer und operativer Planung unterscheiden kann. Hier ist auch zu beachten, dass die Planungsverantwortung nicht bei einer Person liegt, sondern auf mehrere Rollen verteilt wird (s. dazu den Abschnitt "Operative und strategische Planung").

Richtiger Zeitpunkt, richtiger Umfang

Scrum erfordert nicht, dass die Planung vollständig abgeschlossen ist, sondern lediglich, dass sie zu jedem Zeitpunkt "gut genug" ist. Das bedeutet, dass entsprechend dem Projektkontext im Voraus geplant werden muss, wobei Zeitpunkt und Umfang der Planung entscheidend sind. Denn setzt die Planung zu spät ein, verfällt das Scrum-Team in Chaos, da es dann von unzureichend definierten Anforderungen überschwemmt wird, und kein klares Ziel mehr vor Augen hat. Anders ausgedrückt: Das Team muss etwas produzieren, weiß allerdings nicht, was genau. Setzt die Planung jedoch zu früh ein, muss sie zu oft verändert werden und es entstehen unnötige Kosten. Die gleichen Folgen hat ein unangemessener Umfang der Planung. Wie kann man diesen Problemen begegnen?

Operative und strategische Planung

Um die Planung in Scrum jeweils zum richtigen Zeitpunkt und im geeigneten Umfang durchzuführen, lohnt es sich, die zwei Dimensionen der Planung in Scrum zu betrachten: Auf der einen Seite gibt es die strategische Planung, zu der die Produktvision, die Releaseplanung und die Sprintziele gehören. Auf der anderen Seite steht die operative Planung, zu der die Sprintplanung sowie die tägliche Anpassung dieser Planung an die aktuellen Gegebenheiten zählen. Die Verantwortung für die strategische Planung liegt beim Product Owner, die Verantwortung für die operative Planung beim Entwicklungsteam. Das bedeutet, dass der Product Owner die zukünftigen Sprints und Releases plant, während das Entwicklungsteam sich zeitgleich um die Identifikation und Abschätzung der Tasks für den aktuellen Sprint kümmert.

Faustregeln für die Planung

Das nächste Release

Der Product Owner plant auf strategischer Ebene das nächste Release komplett durch. Das bedeutet, dass er zunächst den Releasezeitpunkt bestimmt und die Anzahl der Sprints bis zu diesem Termin berechnet. Anschließend legt er Release- und Sprintziele fest. Diese ergänzt er durch möglichst konkrete fachliche Anforderungen, oft in Form von User Stories. Falls diese noch nicht geschätzt wurden, lässt er sie von seinem Team schätzen. Liegen diese Informationen vor, gleicht der Product Owner seine Planung mit der Geschwindigkeit seines Teams, der Velocity, ab und passt die Planung falls nötig an.

Tabelle 1: Beispiel für die Vorausplanung während Release 1.

Die Planung des nächsten Releases erfolgt parallel zum bereits laufenden Release und kann insgesamt mehrere Tage in Anspruch nehmen – allerdings nicht am Stück, sondern meist verteilt über mehrere Wochen, da die Zwischenergebnisse mit Kunden und Stakeholdern diskutiert werden müssen. Für die Schätzungen benötigt der Product Owner etwa 6-10% der Kapazität seines Teams.

Häufig plant der Product Owner auf dieser Detailebene rollierend im Voraus. Er wartet also nicht auf einen speziellen Zeitpunkt, sondern plant immer eine Releaselänge im Voraus. Bei einer Releasedauer von drei Monaten sorgt er also z.B. dafür, dass immer die nächsten drei Monate auf der Detailstufe geplant sind. So bleibt seine Belastung für die Planung konstant.

Das übernächste Release

Während der Product Owner das nächste Release plant, wird er weitere Sprintziele sowie Anforderungen identifizieren. Diese nimmt er in sein Product Backlog auf und ordnet sie, falls sinnvoll, den passenden Releases zu. Um seinen Stakeholdern und dem Team einen Ausblick geben zu können, stellt der Product Owner sicher, dass er mit dem Abschluss der Planung des nächsten Releases bereits Release- und Sprintziele für das übernächste Release präsentieren kann. Er plant dieses jedoch nur grob und verzichtet meist weitgehend auf konkrete Anforderungen. Zusätzliche Planungszeit benötigt er dafür in der Regel nicht.

Die darauffolgenden Releases

Für die beiden Releases, die auf das übernächste folgen, muss mindestens eine diffuse Vorstellung in Form von groben Zielen existieren, wobei ein Release nicht länger als drei Monate dauern sollte. Auch dies erfolgt im Zuge der Planung für das nächste Release. In der Regel ergeben sich die kommenden Releaseziele automatisch aus den Diskussionen mit Stakeholdern und werden vom Product Owner mit diesen abgestimmt.

Die Planung des Teams

Die operative Planung des Teams erfolgt immer nur für den aktuellen Sprint und zwar bis auf Task- und Stundenebene hinunter. Dies geschieht initial während der zweiten Hälfte des Sprint Planning Meetings. Die so entstandene Planung wird täglich während des Daily Scrums überprüft und gegebenenfalls korrigiert.

Beispiel

Unter der Annahme, dass ein Release drei Monate und ein Sprint vier Wochen dauert, verfügt ein Product Owner also zu jedem Zeitpunkt über eine präzise Planung bis auf Taskebene für den aktuellen Sprint (Monat 1). Die folgenden Sprints (Monate 2 bis 4 bzw. das nächste Release) sind bis auf die Ebene der Anforderungen geplant. Das übernächste Release (Monate 5 bis 7) ist lediglich mit Sprintzielen versehen. Darüber hinaus (ab Monat 8) gibt es noch zwei Releaseziele, die mit den Stakeholdern abgestimmt sind.

Wie präzise im Voraus geplant wird, hängt von den Anforderungen des konkreten Projekts ab. Je nach Auftraggeber kann es auch notwendig sein, für mehr als einen Monat im Voraus bis auf Taskebene zu planen.

Typische Fallstricke bei der strategischen Planung

In vielen Unternehmen wird nicht in "Produkten", sondern in "(Teil-)Projekten" gedacht. Entsprechend werden auch hauptsächlich (Teil-)Projektziele beachtet, während der übergeordnete Kontext des Produkts aus den Augen verloren wird. In der Folge fühlt sich z.B. der Product Owner eines Teilprojekts nicht für das gesamte Produkt, sondern nur für die im Teilprojekt abzudeckenden Aspekte verantwortlich. Selbstverständlich ist dieses Vorgehen aus Sicht des einzelnen Teilprojekts vollkommen richtig, was in den meisten Fällen jedoch auf lange Sicht zu einem nicht optimalen Return on Invest (RoI) und zu einem höheren Total Cost of Ownership (TCO) führt.

Ein Beispiel aus der Praxis: Der Product Owner eines Teilprojekts erstellte einen eigenen Standalone-Client für seine Features. Ein Kollege, der für dasselbe Produkt entwickelte, erstellte ebenfalls einen eigenen Client. Beide Clients erforderten Eingriffe am selben Code des zugrunde liegenden Serverprodukts. Die Anwender mussten sich in der Folge mit mehreren Clients herumquälen und auftretende Fehler im Code des gemeinsam genutzten Servers wurden im Ping-Pong-Verfahren herumgereicht. Zwei Jahre später war die Erstellung eines neuen, einheitlichen Clients notwendig. Ein unnötiger Schritt, hätte man von Anfang an das Gesamtprodukt in den Fokus gerückt.

Releaseplanung – nicht alle Wünsche realisieren

Agile Entwicklung heißt nicht, alle Wünsche der Kunden unreflektiert umzusetzen! Der gängigste Fehler bei der Releaseplanung ist das vollständige Verlassen der Vogelperspektive, also des Blicks auf das Produkt in einer zeitlich langen Sicht. Es ist natürlich einfacher, alle Anforderungen seiner Stakeholder in mehr oder weniger sinnvolle Einheiten zu gruppieren, anstatt aus strategischer Sicht zu planen, was für das Produkt wirklich benötigt wird – denn diese strategische Planung erfordert Weitsicht und jede Menge Arbeit. Bleibt diese Arbeit jedoch aus, so wird nicht klar, in welche Richtung sich das Projekt bzw. Produkt entwickeln soll und die Gefahr steigt, falsche Entscheidungen zu treffen.

Die Gefahr, dass die Produktentwicklung in eine falsche Richtung geht, besteht auch, wenn keine klare Produktvision vorhanden ist. Da die Entwickler täglich Entscheidungen treffen müssen, die sich u.U. stark auf die Zukunft der Software auswirken, benötigen sie eine klare Vision, die als Grundlage für die richtige Entscheidung dienen kann. Fehlt hingegen eine klar formulierte Produktvision, kann es zu Entscheidungen kommen, die nicht im Sinne der gesetzten Projektziele sind.

Typische Fallstricke bei der operativen Planung

Die operative Planung beschäftigt sich mit dem detaillierten Planen einzelner Aufgaben. Was in der strategischen Planung an Vorbereitung häufig fehlt, wird bei der operativen Planung oft zu viel investiert. Die beiden größten Fehler sind dabei das Planen zu lange im Voraus sowie die Mikroplanung.

Langfristige Ziele lassen sich nur grob planen

In manchen Organisationen wird Druck auf die Projektbeteiligten ausgeübt, nach der Identifizierung aller Tasks eine scheinbar präzise Vorhersage des Fertigstellungstermins abzugeben. Scrum sieht das nur für den jeweils aktuellen Sprint vor. Weitet man diese Vorgabe allerdings auf Releases oder sogar ganze Projekte aus, so wird eine Menge Aufwand in die eine Planung gesteckt, die mit sehr hoher Wahrscheinlichkeit bereits nach kurzer Zeit hinfällig ist. Versucht man dann auch noch auf Biegen und Brechen diesen Plan einzuhalten, ist der Vorteil der Agilität verloren.

Absolute Planungssicherheit ist in Softwareprojekten nur selten zu erreichen (in solchen Fällen ist Scrum auch ungeeignet). In Scrum müssen alle akzeptieren, dass langfristig nur grobe Ziele geplant werden, deren genaue Ausgestaltung im Detail noch nicht festgelegt ist. Kurzfristig plant man hingegen präzise. So weiß der Kunde, welche Themen behandelt, aber nicht exakt, welche Features geliefert werden. Ein solches Vorgehen berücksichtigt, dass Vorhersagen in der Softwareentwicklung nicht sinnvoll möglich sind und ermöglicht es dem Kunden, auch während der Projektlaufzeit ständig neue Anforderungen einzubringen, die dann anstelle früherer Wünsche den noch ungeplanten Releases zugewiesen werden können.

Keine Mikroplanung

Selbst wenn durch die Organisation und den Product Owner keine Fehler gemacht wurden, kann das Entwicklungsteam immer noch unnötige Kosten verursachen. Beliebt ist z.B. die Mikroplanung: Statt Aufgaben auf Tagesbasis zu planen, werden hier bis auf die Minutenebene Einzelschritte extrahiert. Dabei kostet die Planung mancher Schritte oft mehr Zeit, als die Ausführung der Aufgabe selbst beanspruchen würde.

Ähnlich kritisch ist es, wenn das Entwicklungsteam die Aufgaben zu große Schritte aufteilt: Dauert ein Task länger als einen Tag, ist es schwierig festzustellen, ob das Team noch im Plan liegt oder ob es Handlungsbedarf gibt. Die Transparenz geht verloren, eine sinnvolle tägliche Neuplanung wird unmöglich.

Bewährt hat sich, nur Tasks zu planen, die mehr als eine Stunde und weniger als einen Tag dauern. Kleinere Tasks werden zusammengefasst. Größere müssen in kleinere Teilaufgaben heruntergebrochen werden. Auf diese Weise ist einerseits sichergestellt, dass Mikroplanung vermieden wird, andererseits erhält der Product Owner täglich einen transparenten Projektstatus.

Ausblick

Der zweite Teil beschreibt detailliert die neun Planungsschritte und zeigt, worauf man bei den einzelnen Schritten achten sollte. Anhand eines realen Praxisbeispiels erfahren Sie, wie auf diese Weise die Planung in Scrum bei einem Unternehmen aus der Automobilbranche durchgeführt wurde.

DownloadDownload

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 4
Kommentare 0

Fortsetzungen des Fachartikels

Teil 2:
Vorgehen in der Praxis
Im ersten Teil stellte Dominik Maximini ein Vorgehen vor, um Scrum-Projekte strukturiert zu planen und zeigte Fehler auf, die dabei häufig in der Praxis gemacht werden.