Wie funktioniert Scrum?

Scrum – das klingt fremd, ein wenig Englisch. Tatsächlich ist Scrum ein Begriff aus dem Rugby, der übersetzt Gedränge bedeutet. Es waren die Japaner Ikujirō Nonaka und Hirotaka Takeuchi, die den Begriff ursprünglich einführten, um erfolgreiche Entwicklungsprojekte zu beschreiben. Der Erfolg eines Projektes, so Nonaka und Takeuchi, sei vor allem abhängig vom Team und der Taktik, die es einsetze: Es arbeite effizienter, wenn es einem Ziel folge und sich selbst organisieren könne, um es zu erreichen. Später übernahmen Ken Schwaber und Mike Beedle den Begriff und veröffentlichten im Jahre 2001 das erste Buch über Scrum in der Software-Entwicklung. Heute ist es einer der bekanntesten Prozesse im agilen Projektmanagement und bietet einen offiziellen Leitfaden durch den sogenannten Scrum Guide. Diesen Leitfaden können nicht nur Software-Projekte einsetzen, sondern alle Projekte, die vor einer komplexeren Aufgabenstellung stehen. Doch wie funktioniert agiles Projektmanagement mit Scrum?

Die Verantwortlichkeiten in Scrum

Scrum folgt den Werten, die 2001 im agilen Manifest niedergeschrieben wurden und eine neue Art des Projektmanagements festhielten. Sie besagen, dass starre Zeitpläne, unzureichende Kommunikation und unflexible Prozesse nicht zu erfolgreichen Projekten führen. Stattdessen passt man sich den Änderungen kontinuierlich an und agiert agil, indem sich auch das Team als selbstorganisierte Einheit neu erfindet. Scrum baut hier auf drei Verantworlichkeiten, die eine oder mehrere Personen in einem Projekt einnehmen: Entwicklungsteam, Scrum Master und Product Owner. Eine weitere wichtige Personengruppe bilden die Stakeholder, obwohl der Prozess sie nicht explizit als Rolle definiert. Ein Projektleiter fällt in Scrum ganz weg.

Aller Anfang sind die Anforderungen – Das Product Backlog in Scrum

Scrum gehört zu den agilen Entwicklungsprozessen und auch Anforderungen werden agil ermittelt. Deswegen verwendet dieser Prozess das sogenannte Product Backlog: Dort sammelt der Product Owner alle Anforderungen an das Produkt, die das Entwicklungsteam umsetzen muss. Ein Produkt bezieht sich hierbei immer auf genau ein zu erzielendes Ergebnis, zum Beispiel auf eine Software. Muss das Team unterschiedliche Software entwickeln, so gibt es auch unterschiedliche Product Backlogs.

Der Product Owner ermittelt die Anforderungen basierend auf dem Feedback der Stakeholder und priorisiert sie nach Geschäftswert. Als Ergebnis erstellt er eine Liste, in der die Anforderungen nach ihren Prioritäten sortiert sind. Wenn sich jedoch Änderungen im Verlauf des Projektes ergeben, dann passt der Product Owner diese Liste daran an – ein Product Backlog in Scrum ist somit niemals fix, sondern ändert sich stetig. Die dort aufgestellten Anforderungen sind außerdem meistens in Form von User Storys beschrieben und in einzelne Tasks heruntergebrochen.

Lesen Sie hier, um mehr über Backlogs, User Storys und Tasks zu erfahren »

Von Sprint zu Sprint – Das Projektmanagement in Scrum

Das Entwicklungsteam implementiert jedoch nicht einfach ohne Plan die Anforderungen – jedenfalls von der äußeren Struktur betrachtet. Denn ein Scrum-Projekt gliedert sich in sogenannten Sprints und Releases. Ein Sprint entspricht einem Entwicklungszyklus von einer bis vier Wochen. Die genaue Länge legt das Team fest, ein Sprint sollte jedoch immer gleich lang sein. Am Ende eines Sprints liefern Sie ein funktionsfähiges Produktinkrement. In einem Release wird eine Produktversion freigegeben.

Wenn das erste Product Backlog im Scrum-Projekt steht, setzen sich das Team und der Product Owner in einem Sprint Planning zusammen. Hier entscheiden sie, welches Ziel für den nächsten Sprint geplant ist und welche Anforderungen sie dafür umsetzen müssen. Das Entwicklungsteam schätzt dafür den Umsetzungsaufwand jeder Anforderung bzw. User Story. Auf Basis dieser Aufwandsschätzung und den Prioritäten, die der Product Owner vergeben hat, wählt das Entwicklungsteam eine Anzahl von Anforderungen für den nächsten Sprint – ein sogenanntes Sprint Backlog entsteht. Die Entwickler müssen alle User Storys, die dieses Backlog enthält, selbstorganisiert in diesem Sprint umsetzen. Den Fortschritt halten Sie fest, indem sie jeden Tag den Restaufwand notieren. Auf diese Weise sinkt der Restaufwand einer Anforderung am Ende des Sprints auf 0: Die User Story wurde umgesetzt. Solch eine Entwicklung lässt sich in einem sogenannten Burndown Chart schön darstellen.

Am Ende des Sprints trifft sich das Team in einem Sprint Review, das idealerweise nicht länger als eine Stunde dauern sollte. Die Entwickler besprechen ihre Ergebnisse und prüfen, ob sie das angestrebte Ziel erreicht haben. Auch die Stakeholder beteiligen sich an diesem Treffen und geben aktiv Feedback. Der Product Owner überarbeitet das Product Backlog und zusammen mit dem Team plant er das Ziel und die Anforderungen für den nächsten Sprint im Scrum-Projekt.

Als Abschluss des Sprints führt das Team unter Moderation des Scrum Masters oder eines anderen Moderators eine Sprint Retrospektive durch. Diese soll mindestens einen Verbesserungsvorschlag bezüglich des Prozesses hervorbringen.

Kommunizieren geht über Studieren – Die Daily Scrums

Scrum lebt von einer lebendigen Kommunikation – nicht nur zwischen Stakeholdern und Product Owner, sondern auch innerhalb des Entwicklungsteams. Deswegen kommen die Entwickler zu Beginn jedes Arbeitstages zu einem Daily Scrum zusammen: In etwa 15 Minuten berichten die Beteiligten, was sie am letzten Tag erreicht haben, was sie zum nächsten Daily Scrum erreichen möchten und welche Hindernisse ihnen dabei möglicherweise im Weg stehen. Wenn Probleme auftreten, helfen sich die Teammitglieder nach Bedarf gegenseitig. Auch der Product Owner und Scrum Master sind oftmals anwesend, wenn auch nur passiv daran beteiligt.

Das Treffen findet meistens stehend statt. Wichtig ist, dass sich Teammitglieder wirklich einander berichten und keinem Vorgesetzten Bericht erstatten. Schließlich geht es darum, nicht im eigenen Elfenbeinturm zu sitzen, sondern einen Einblick in die Arbeit aller anderen zu erhalten.

Wenn es mehrere Entwicklungsteams gibt, dann folgt nach einem Daily Scrum ein Treffen zwischen den verschiedenen Teams in einem Scrum of Scrums. Auch sie informieren sich gegenseitig über den aktuellen Stand ihres Teams. Nicht alle Mitglieder der Teams müssen daran teilnehmen, sondern nur ein bis zwei definierte Personen je Team.

Lesen Sie hier, um mehr über Scrum of Scrums zu erfahren »

Jedes Team-Mitglied beantwortet die Fragen:

Projekte agil mit Scrum managen

Als Product Owner müssen Sie Anforderungen aufstellen, schnell neue hinzufügen und veraltete hinausstreichen können, damit das Product Backlog aktuell bleibt. Sie müssen Sprints und Releases sowie die dazugehörigen Backlogs planen, um Ihr Produkt zeitig liefern zu können. Die Entwickler sind dafür verantwortlich, den Fortschritt ihrer Arbeit festzuhalten, damit sich der aktuelle Sprint- und Projekt-Verlauf bewerten lässt. Aber wie behalten Sie den Überblick? Wie lassen sich Anforderungen effizient anlegen, priorisieren und abschätzen, wie lässt sich der Fortschritt der Implementierung verfolgen? Und wäre es nicht sinnvoll, Diagramme wie ein Burndown Chart ohne großen Aufwand zu erstellen? Das geht am besten mit passendem Tool.

Probieren Sie es einfach jetzt gleich aus. objectiF RPM – 30 Tage lang kostenlos!