Scrum. Projekte agil managen.

Was ist Scrum und wie funktioniert es? Wer ist daran beteiligt? Und warum sollen Projekte damit erfolgreicher sein?

1
2
3
Der Scrum-Prozess im Überblick

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?

Follow a manual added link

Testen Sie kostenlos
objectiF RPM

Machen Sie den Test.
So geht Scrum in der Praxis.

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.

  • Entwicklungsteam

Ohne ein Entwicklungsteam geht nichts in Scrum. Idealerweise besteht dieses aus 3 bis 9 Personen und organisiert sich selbst. Wenn mehr Personen für die Entwicklung gebraucht werden, wendet man das sogenannte Scrum of Scrums an: Hier bilden Sie mehrere Entwicklungsteams, die ihre eigenen Product Backlogs pflegen und ihre eigenen Daily Scrums abhalten. Im idealen Entwicklungsteam fallen zudem die Expertenrollen weg. Es besteht nicht mehr nur aus dem Analysten, dem System-Architekten und dem Tester: Alle Teammitglieder übernehmen nach Bedarf diese und weitere Funktionen.

  • Product Owner

Der Product Owner in Scrum kümmert sich um die Anforderungen an das Projekt. Dafür kommuniziert er mit allen Stakeholdern und sammelt die Anforderungen in dem Product Backlog. Er trägt jedoch nicht nur die Anforderungen zusammen, sondern priorisiert sie auch, fügt neue hinzu oder verwirft wieder welche im Verlauf des Projekts.

  • Scrum Master

Der Scrum Master stellt sicher, dass alle den Scrum-Prozess korrekt anwenden und die Rollen einhalten. Außerdem moderiert er die Scrum-Meetings und schützt das Team vor unberechtigten Eingriffen während der Entwicklung. Er darf jedoch nicht mit einem Projektleiter verwechselt werden, denn das Team organisiert sich selbst und kommuniziert auch direkt mit dem Product Owner.

  • Stakeholder

Stakeholder sind keine definierte Rolle in Scrum, wirken sich jedoch maßgeblich auf den Prozess aus. Denn zu ihnen gehören Personen wie Kunden, Mitarbeiter oder Manager, aber auch juristische Personen und Institutionen, die am Gelingen des Projekts interessiert sind. Durch sie ermittelt der Product Owner die passenden Anforderungen und Prioritäten.

Lesen Sie hier, um mehr über Stakeholder zu erfahren >>

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.

Während eines Sprints arbeitet das Entwicklungsteam ungestört.
Der Product Owner darf in diesem Zeitraum die Anforderungen nicht anpassen.

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.

Sprint Planning

  • Ziel des nächsten Sprints festlegen
  • Aufwand der User Storys schätzen
  • User Storys für nächsten Sprint planen

Sprint Review

  • Team: Sprint-Ergebnisse präsentieren
  • Product Owner und Stakeholder: Feedback geben

Sprint Retrospektive

  • Fakten und Daten sammeln
  • Erkenntnisse gewinnen
  • Verbesserungen am Prozess beschließen
Follow a manual added link

Wissen zum Mitnehmen

Projektplanung und Kontrolle
in agilen
und hybriden Projekten

Follow a manual added link

Downloads

  • Whitepaper
  • Tipps & Tricks
  • Software

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:

Was habe ich seit gestern getan?

Was mache ich bis morgen?

Was hindert mich am meiner Arbeit?

Scrum erfreut sich hoher Beliebtheit. Und das ist nicht verwunderlich:

Die klare Rollenverteilung und einfache Struktur ermöglichen es,
die Prinzipien schnell zu erlernen, effizient einzusetzen und ein agiles Projektmanagement zu leben.

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?

Übersicht
Wissen Online
Wissen mit Tool anwenden:
objectiF RPM
Mehr Wissen als PDF:
Downloadcenter

Pin It on Pinterest

Share This