Die Genialität von Scrum liegt in seiner Einfachheit. Mit wenigen Regeln und Rahmenbedingungen gelingt es, komplexe Aufgaben in kleine, überschaubare Teile zu zerlegen, die übersichtlich, klar strukturiert und schnell umsetzbar sind. Erfolge sind somit schon während der Entwicklung ersichtlich und überprüfbar. Ständige Kommunikation zwischen allen Beteiligten stellt sicher, dass es nicht zu Missverständnissen und falschen Erwartungen kommt. Und: Bei Bedarf können jederzeit während des laufenden Projektes Änderungen an Ziel und Inhalt vorgenommen werden. 

Wer mit Scrum beginnt, braucht vor allem das absolute Commitment aller Beteiligten: vom obersten Management bis zum Umsetzungsteam muss jeder an Bord sein, denn Scrum stellt die klassischen Rollen auf den Kopf. Der Gedanke „Vertrauen ist gut, Kontrolle ist besser“ hat bei der agilen Web-Entwicklung ausgedient. Führungskräfte verlieren zunehmend ihre Kontrollfunktion und dienen mehr denn je als Coaches, die ihre Mitarbeiter darin unterstützen, ihre Ziele aus sich selbst heraus zu erreichen. Die Verantwortung des Projekts liegt alleine beim Product Owner. Die Autorität beim Umsetzungsteam. Dieses muss interdisziplinär aufgebaut sein und über alle Kompetenzen verfügen, um ein Produktinkrement zu erzeugen, ohne auf Zuarbeit von außen angewiesen zu sein. Die Mitglieder bringen unterschiedliche Fähigkeiten ein und ergänzen sich gegenseitig, um anstehende Aufgaben zu lösen und Innovationen durch gegenseitigen Austausch voranzutreiben. Wie eingangs erwähnt, hat Scrum wenige Regeln – diese gilt es aber möglichst genau zu befolgen, um die positiven Effekte der Methodik nicht zu verlieren. Über die Einhaltung von Meetings, Zeiten und Vereinbarungen wacht der Scrum Master. Er schützt das Team gegen Störungen von außen, räumt Hindernisse, sogenannte „Impediments“, aus dem Weg und sorgt dafür, dass der Scrum-Prozess von allen verstanden wird und sich das Team kontinuierlich weiterentwickeln kann.

Die Rollen im Scrum

• Neben dem Auftraggeber gibt es in Scrum drei zentrale Rollen: den Product Owner, den Scrum Master und das Umsetzungsteam.
• Der Product Owner (PO) ist für den Erfolg des Projektes und den Return on Invest verantwortlich. Er erstellt das Product Backlog, eine priorisierte Aufgabenliste für das Team, das in einzelnen Stories aus der Kundensicht heraus klare Wünsche beschreibt: „Wenn ich als Kunde erneut im Onlineshop einkaufe, möchte ich, dass sich der Shop an meine bevorzugte Empfangsadresse erinnert.“
• Der Scrum Master hat in erster Linie eine organisierende und moderierende Funktion. Er sorgt dafür, dass der Scrum-Prozess von allen verstanden und eingehalten wird und das Team gut arbeiten kann.
• Das Umsetzungsteam ist für die erfolgreiche Umsetzung der Stories zuständig. Es ist selbstorganisiert und dafür verantwortlich, dass alle vorgesehenen Stories in einem Sprint umgesetzt werden.

Zum Start eines Projekts in Scrum ist es die erste Aufgabe des Product Owners, mit dem Auftraggeber die zwei begrenzenden Faktoren zu klären: Zeit und Budget. Sind diese Bedingungen abgesteckt, kann mit dem Auftraggeber besprochen werden, welche Anforderungen sich innerhalb des Rahmens umsetzen lassen. Dafür formuliert der Product Owner aus den Anforderungen sogenannte Stories, um das Product Backlog aufzubauen. Die Stories des Backlogs beschreiben die einzelnen Funktionen beispielsweiser einer Software.

Relativ zu Anfang des Scrum-Projekts kann der Product Owner die Komplexität der Stories seines gesamten Backlogs vom Umsetzungsteam in einem Meeting (Backlog Refinement ) grob in Story Points schätzen lassen. So erhält er ein Gefühl dafür, wie weit das Team innerhalb des verfügbaren Zeit- und Budgetrahmens kommen wird und kann seinem Auftraggeber eine ungefähre Vorstellung geben, wie „fertig“ das Produkt am Ende des Geldes sein wird.

Scrum ABC

Sprint: Eine fest definierte Zeitspanne (meist zwei Wochen) zur Umsetzung von Stories.
Daily Scrum: tägliches Meeting (15 Minuten). Jedes Teammitglied berichtet, was es gestern erreicht hat, was es heute plant und ob es Hindernisse gibt.

Sprint Review: Ergebnispräsentation des Sprints (1-2 Stunden). Der PO bewertet die Ergebnisse und nimmt sie an oder lehnt sie ab.

Retrospektive: Moderiert vom Scrum Master (1-2 Stunden) nach jedem Sprint: wie geht es dem Team, funktionieren die Werkzeuge, wie kann das Team besser und die Leistung optimiert werden? Mit der Retro ist der Sprint abgeschlossen.

Sprint Planning: Vor jedem Sprint (1-2 Stunden). Der PO stellt dem Team die am höchsten priorisierten Stories vor, die er als nächstes umgesetzt sehen möchte. Es endet mit dem Team Commitment, dem Versprechen des Teams, die ausgewählten Stories innerhalb des Sprints fertigzustellen.

Task Breakdown: Nach dem Planning (1-2 Stunden). Das Team schneidet die Stories in einzelne Tasks, die die Schritte zur Umsetzung beschreiben.

Backlog Refinement: Treffen (1-2 Stunden) einige Tage vor dem Planning. Anforderungen aus dem Backlog – Epics und Stories werden priorisiert und Lösungen besprochen. Das Team schätzt, wie hoch die Komplexität (Story Points) von Stories ist. Vom Product Owner vorher festgelegte Akzeptanzkriterien werden geprüft, Impediments (Hindernisse) identifiziert und im Anschluss mit Hilfe des Scrum Masters beseitigt.

Stories: Stories können mal größer mal kleiner sein, haben aber alle gemein, dass sich jede Story innerhalb eines Sprints umsetzen lassen muss. Die Points geben dem PO ein Gefühl, wie lange die Story-Umsetzung dauern wird.

Epic: große Features, die noch in Stories geteilt werden müssen
Product Backlog: die Sammlung aller Stories, die das fertige Produkt und seine Funktionen beschreiben.

Sprint Backlog: die Sammlung aller für den aktuellen Sprint relevanten Stories.