In der Theorie schaut ja alles ganz einfach aus: Der Product Owner bastelt den ersten Product Backlog, lässt sich vom Team eine Einschätzung des Aufwands geben, priorisiert die User Stories und schon ist das Produkt so gut wie fertig. Wie gesagt, so steht es im Lehrbuch. Aber wie sieht das ganze in der Praxis aus und wie wird es organisiert?

In der Regel fällt irgendwann einmal der Entschluss ein neues Projekt anzugehen und es wird ein Verantwortlicher dafür bestimmt. Das ist normalerweise der zukünftige Product Owner. Seine erste Aufgabe ist die Formulierung der Zieldefinition und die Erstellung der ersten Version des Product Backlogs.

1. Er wird im ersten Schritt nicht umhinkommen eine Grobversion zunächst selbst zu erstellen. Dazu kann er sich bei Bedarf mit Fachleuten, also Entwicklern etc. besprechen. Das Ergebnis ist die Grundlage für den nächsten Schritt.
2. Zeit für ein erstes Meeting. Dazu versammelt der Product Owner alle verfügbaren bzw. notwendigen Fachleute. Ziel ist es, eine erste realistische Aufwandseinschätzung für die User Stories zu erhalten. Je nach Umfang des Projektes kann dieses Meeting mehrere Stunden in Anspruch nehmen.
3. Sobald der erste, realistische Product Backlog steht, kann der Product Owner die Kosten des Projektes einschätzen. Kommt Anschließend das Go vom Management, kann es losgehen.
4. Spätestens jetzt kommt der Scrum Master ins Spiel. Der Product Owner muss in Zusammenspiel mit ihm dafür sorgen, dass der folgende Prozess korrekt, sprich also Scrum-konform aufgesetzt wird.
5. Jetzt gilt es das passende Team zusammenzustellen. Dessen erste Aufgabe: Noch ein Product Backlog Meeting, dieses mal aber mit den konkret Beteiligten, also den Machern des Projekts. Ziel ist es die Aufwandschätzung nochmals zu optimieren, gegebenenfalls die User Stories zu ergänzen und zu präzisieren.
6. Nun muss der Product Owner die User Stories priorisieren und damit die Grundlage für das erste Sprint Planning schaffen.

Im nächsten Beitrag schauen wir uns an, wie ein Product Backlog inhaltlich aussieht.

Nach dem wir in den letzten Beiträgen die wichtigsten Begriffe gelernt haben, geht es jetzt darum, wie ein Scrum-Projekt prinzipiell abläuft. Drei Punkte sind dabei wesentlich und decken sich weitestgehend mit den grundsätzlichen Prinzipien des agilen Projektmanagements:

1. Die Idee von Scrum beruht darauf, dass die Entwicklung von Software, aber auch generell von komplexen Produkten nicht in dem Maße planbar ist, wie andere typische Projekte, etwa der Bau eines Gebäudes oder die Einrichtung einer neuen Produktionslinie in einer Fabrik.
2. Ein Scrum-Projekt wird iterativ er- und abgearbeitet. Die Devise lautet, lieber in kleinen Schritten schnell voran kommen, als bei einem großen Schritt zu stolpern, sich dabei zu verletzen und deshalb nie ans Ziel zu kommen.
3. Es gilt die Erkenntnis, dass das Team besser weiß als eine zentrale Planungsstelle (Projektmanager), was es wann und wie tun kann und welche Schritte dazu notwendig sind. Scrum formalisiert diesen Prozess jedoch und macht ihn dadurch planbar.

Der Ablauf:

Aus dem Product-Backlog werden die am höchsten priorisierten Anforderungen in den Sprint-Backlog übernommen. Das ist die Arbeitsgrundlage bzw. der Projektplan für den folgenden Sprint. Ein Sprint dauert typischerweise zwei bis vier Wochen. Die Basis für die tägliche Arbeit bildet dabei das (in der Regel 15-Minuten kurze) Daily-Scrum-Meeting. Am Endes eines Sprints folgt das Sprint-Review.

Das Ziel von Scrum wird damit klar: In möglichst kurzer Zeit zu einem funktionierenden, wenn auch nicht mit allen Features versehenen Produkt zu kommen. Fehlende Features werden in nachfolgenden Sprints hinzugefügt.

Am Beginn eines Scrum-Projektes steht das Product Backlog. Den schauen wir uns in der nächsten Folge genauer an.