Scrum-Projektplanung: flexibel planen und gemeinsam liefern

Scrum-Projektplanung bedeutet nicht, zu Beginn ein vollständiges Projekt bis ins kleinste Detail durchzuplanen. Stattdessen plant das Team schrittweise, überprüft regelmäßig seine Annahmen und passt den Kurs anhand neuer Erkenntnisse an. So entsteht ein verlässlicher Rahmen, ohne die Flexibilität zu verlieren, die Scrum auszeichnet.

Was bedeutet Projektplanung in Scrum?

In klassischen Vorgehensmodellen werden Umfang, Zeit und Kosten häufig möglichst früh festgelegt. Scrum geht anders vor: Das Produkt wird in kurzen Arbeitszyklen, den Sprints, weiterentwickelt. Nach jedem Sprint werden Ergebnisse und Prioritäten überprüft. Die Planung wird dadurch zu einem fortlaufenden Prozess statt zu einer einmaligen Aktivität am Projektanfang.

Scrum bietet dafür mehrere Planungsebenen. Sie reichen von der Produktvision über die Arbeit mit dem Product Backlog bis hin zur konkreten Sprintplanung. Die Planung liefert Orientierung, bleibt aber offen für Veränderungen, wenn sich Kundenbedürfnisse, technische Erkenntnisse oder Rahmenbedingungen ändern.

Die wichtigsten Planungsebenen

Produktvision und Ziele

Am Anfang steht ein gemeinsames Verständnis davon, welches Problem das Produkt lösen soll und für wen es gedacht ist. Eine klare Produktvision hilft dem Team, Entscheidungen einzuordnen und den Fokus zu behalten. Ergänzend sollte ein konkretes Produktziel beschreiben, welchen Nutzen das Produkt als Nächstes erreichen soll.

Product Backlog und Priorisierung

Das Product Backlog enthält die bekannten Anforderungen, Verbesserungen und Arbeiten, die für das Produkt infrage kommen. Es ist dynamisch: Einträge werden ergänzt, verändert, präzisiert oder entfernt, sobald neue Informationen vorliegen.

Der Product Owner ist für eine wirksame Verwaltung des Product Backlogs verantwortlich. Dazu gehört, Einträge verständlich zu machen und ihre Reihenfolge so zu gestalten, dass möglichst viel Wert entsteht. Bei der Priorisierung können beispielsweise Kundennutzen, Risiken, Abhängigkeiten, Aufwand und strategische Ziele berücksichtigt werden.

Release- und längerfristige Planung

Unternehmen und Stakeholder benötigen oft eine Einschätzung dazu, wann bestimmte Funktionen oder Ergebnisse verfügbar sein könnten. Scrum verbietet solche Prognosen nicht. Sie sollten jedoch als Vorhersagen behandelt werden, nicht als unumstößliche Versprechen.

Eine realistische Prognose berücksichtigt unter anderem die Größe und Unsicherheit der Arbeit, die bisherige Lieferfähigkeit des Teams sowie mögliche Abhängigkeiten. Je weiter ein Termin in der Zukunft liegt, desto größer ist normalerweise die Unsicherheit. Regelmäßige Aktualisierungen machen Prognosen aussagekräftiger.

Sprintplanung

Zu Beginn jedes Sprints findet das Sprint Planning statt. Das Scrum Team bespricht dabei drei zentrale Fragen:

• Warum ist dieser Sprint wertvoll? Das Team formuliert ein Sprint-Ziel, das einen gemeinsamen Fokus schafft.
• Was kann im Sprint erreicht werden? Das Team wählt passende Product-Backlog-Einträge aus und berücksichtigt dabei seine Kapazität sowie bisherige Erfahrungen.
• Wie wird die Arbeit erledigt? Die Developers planen die nötigen Schritte, um ein nutzbares Increment zu erstellen.

Das ausgewählte Backlog und der Umsetzungsplan bilden gemeinsam den Sprint Backlog. Die Developers passen diesen Plan während des Sprints an, wenn sie mehr über die Arbeit erfahren. Das Sprint-Ziel bleibt dabei der gemeinsame Orientierungspunkt.

So gelingt eine gute Scrum-Projektplanung

1. Mit dem gewünschten Ergebnis beginnen: Klären Sie zuerst, welches Problem gelöst und welcher Nutzen geschaffen werden soll.
2. Arbeit in kleine, überprüfbare Einheiten zerlegen: Kleine Backlog-Einträge lassen sich leichter verstehen, schätzen und innerhalb eines Sprints fertigstellen.
3. Unsicherheit sichtbar machen: Unklare Anforderungen und technische Risiken sollten früh besprochen und gegebenenfalls durch Experimente überprüft werden.
4. Das gesamte Team einbeziehen: Product Owner, Scrum Master und Developers bringen unterschiedliche Perspektiven ein. Entscheidungen werden dadurch fundierter und realistischer.
5. Auf Basis echter Erfahrung planen: Vergangene Sprints liefern Hinweise auf die tatsächliche Lieferfähigkeit. Diese Daten sollten als Orientierung dienen, nicht als Leistungskennzahl für Einzelpersonen.
6. Regelmäßig überprüfen und anpassen: Sprint Reviews, Retrospektiven und die tägliche Abstimmung helfen, Fortschritt, Zusammenarbeit und Hindernisse sichtbar zu machen.

Beispiel: Planung eines Online-Shops

Ein Team entwickelt einen Online-Shop. Das erste Produktziel könnte lauten: „Kundinnen und Kunden können ein Produkt finden und eine Bestellung aufgeben.“ Das Product Backlog enthält dafür unter anderem die Produktsuche, eine Produktdetailseite, einen Warenkorb und den Bestellabschluss.

Für den nächsten Sprint entscheidet sich das Team für ein Sprint-Ziel, das einen sinnvollen ersten Schritt ermöglicht, zum Beispiel: „Nutzende können Produkte durchsuchen und die wichtigsten Produktinformationen ansehen.“ Das Team plant die dafür nötigen Arbeiten. Nach dem Sprint wird das Ergebnis mit Stakeholdern überprüft. Deren Rückmeldungen können die Reihenfolge der nächsten Backlog-Einträge verändern.

So wird die Planung konkret genug, um ins Handeln zu kommen, bleibt aber offen für Erkenntnisse aus der tatsächlichen Nutzung.

Häufige Fehler bei der Scrum-Projektplanung

• Alles im Voraus detailliert festlegen: Bei komplexer Arbeit ändern sich Erkenntnisse und Prioritäten. Ein starrer Gesamtplan kann dann schnell überholt sein.
• Den Sprint mit zu vielen Aufgaben füllen: Eine realistische Auswahl ist hilfreicher als ein überladener Sprint Backlog.
• Story Points als Produktivitätsmaß verwenden: Schätzwerte dienen der Planung im Team und eignen sich nicht dazu, Mitarbeitende oder Teams miteinander zu vergleichen.
• Nur Auslastung statt Ergebnis planen: Entscheidend ist der Wert des fertigen Increments, nicht die Zahl der begonnenen Aufgaben.
• Änderungen im Sprint unkontrolliert aufnehmen: Neue Informationen können Anpassungen erforderlich machen. Sie sollten gemeinsam bewertet werden, ohne das Sprint-Ziel unnötig zu gefährden.

Fazit

Scrum-Projektplanung schafft Orientierung, ohne so zu tun, als ließe sich die Zukunft vollständig vorhersagen. Eine klare Produktvision, ein gepflegtes Product Backlog, ein sinnvolles Sprint-Ziel und regelmäßige Überprüfung bilden die Grundlage. Erfolgreiche Planung ist dabei keine einmalige Aufgabe, sondern ein gemeinsamer Lern- und Anpassungsprozess.