→ Zurück zur Übersicht

Scrum ist ein sehr leichtgewichtiges, iteratives Vorgehensmodell der Softwareentwicklung, das grundlegende Kernelemente es Vorgehens zur Verfügung stellt, die Ausgestaltung der angewandten Methoden und Prozesse aber dem Team überlässt. Ziel von Scrum ist es Risiken und Störungen des Produktionsablaufes offenzulegen und damit den Produktionsprozess zu optimieren.

Aufrund dieser Offenheit ist es erforderlich Scrum bei jeder Implementierung in einer Umgebung anzupassen bzw. über die vorhandenen Prozesse zu legen. Dieses Vorgehen deckt oft Schwächen in den Prozessen auf, jedoch ist es an den Betroffenen diese Schwächen zu erkennen und zu reagieren — Scrum selbst gibt keine Handlungsempfehlungen.

Eine wichtige Besonderheit ist, dass in Scrum nicht mit exakten zeitlichen Schätzungen garbeitet wird, sondern nur mit relativen Werten, sogenannten *Story-Points". Diese stellen die Komplexität der Aufgaben im Vergleich zueinander dar. Aus der Höhe der Punkte für eine Aufgabe lässt sich (besonders zu Beginn der Arbeit) nicht wirklich ableiten, wie lange die Bearbeitung dauern kann. Wenn die Entwickler allerdings gelernt haben einzuschätzen, wie gut sie Aufgaben einer bestimmten Komplexität handhaben können, wird die Schätzung dessen, was in einer Iteration abgearbeitet werden kann, immer genauer. Dann lässt sich extrapolieren, ob das Projekt termintreu abgeschlossen werden kann.

Scrum definiert die folgenden Rollen, Aktivitäten und Artefakte:

1. Rollen

Die Beteiligten in diesen Rollen ergeben in ihrer Gesamtheit das Scrum-Team.

Product-Owner

Hat die fachliche Hoheit über die Anforderungen an das Produkt und legt die Prioritäten fest.

Entwickler

Haben die technische Hoheit über das Produkt und sichern die Funktionalität und Qualität.

Scrum-Master

Hat die Hoheit über den Scrum-Prozess und sichert seine Einhaltung durch alle Beteiligten.

2. Aktivitäten

Die Aktivitäten ergeben in ihrer Gesamtheit den Scrum-Prozess. Den Rahmen für diese sich wiederholenden Aktivitäten bietet der Sprint.

2.1. Ablauf

  1. Der Sprint startet mit dem Sprint-Planning.

  2. Danach beginnt die Arbeit am Produkt — währenddessen findet jeden Tag ein Daily-Scrum zu kurzen Abstimmung statt.

  3. Zum Ende des Sprints kommen alle Beteiligten im Sprint-Review zusammen um die Fortschritte am Produkt zu sehen.

  4. Im direkten Anschluss findet die Sprint-Retrospective statt — diese beendet den Sprint.

  5. Danach — in der Regel am folgenden Tag — beginnt der nächste Sprint mit dem Sprint-Planning …​

2.2. Übersicht

Sprint

Entwicklungszyklus bzw. Iteration in der Entwicklung. Im Sprint wird von den Entwicklern ein funktionierendes Inkrement fertiggestellt, dass sich im Laufe der Iterationen immer weiter an die Gesamtmenge der Anforderungen annährt.

Time-Box

1 bis 4 Wochen

Sprint-Planning

Zweigeteilte Aktivität: In der ersten Hälfte planen Product-Owner und Entwickler die Inhalte des kommenden Sprints. Der Product-Owner präsentiert die wichtigsten Aufgaben und die Entwickler schätzen den Aufwand ab und entscheiden, wie viele Aufgaben sie im nächsten Sprint bearbeiten können. Mit den ausgewählten Aufgaben wird der Sprint gefüllt. Der Scrum-Master sichert ab, dass nicht mehr geplant wird, als die Entwickler für realistisch halten. In der zweiten Hälfte besprechen die Entwickler geplanten Aufgaben (ohne den Product-Owner) und priorisieren diese nochmals für den Sprint. Dabei werden die fachlichen Aufgaben auch evtl. auf technischer Ebene nochmals in einzelne Punkte aufgegliedert.

Time-Box

4 bis 8 Stunden

Daily-Scrum

Die Entwickler berichten sich gegenseitig von ihren Fortschritten und Hindernissen (Impediments). Der Product-Owner kann hier teilnehmen, hat allerdings kein aktives Mitspracherecht, kann aber gerne Rückfragen beantworten. Der {so} nmmt ebenfalls Teil und versucht Impediments zu identifizieren.

Time-Box

15 Minuten

Sprint-Review

Die Entwickler zeigen live, an einem funktionierenden System (keine Demo, kein Powerpoint), was sie im Sprint erreicht haben. Zuschauer sind der Product-Owner und weitere interessierte Stakeholder. Nach der Präsentation entscheidet der Product-Owner, ob das Inkrement produktiv gehen kann oder noch weiterentwickelt werden muss. Der Scrum-Master sichert ab, dass aufkommende Kritik in einem konstruktiven Rahmen bleibt und sich die Entwickler nicht unter Druck setzen lassen.

Time-Box

2 bis 4 Stunden

Sprint-Retrospective

Die Entwickler und der Scrum-Master reflektieren den vergangenen Sprint. Dabei wird im allgemeinen geprüft was gut funktioniert hat und was nicht, bzw. welche Hindernisse den Ablauf gestört haben. Gemeinsam wird versucht Lösungsstrategien zu finden.

Time-Box

2 bis 4 Stunden

3. Artefakte

Product-Backlog

Hier sammelt und priorisiert der Product-Owner seine fachlichen Aufgaben, auch Einträge genannt.

Sprint-Backlog

Aufgaben, die im Sprint-Planning für den Sprint ausgewählt wurden, werden hier eingegliedert und von den Entwicklern priorisiert.

Inrement

Funktionstüchtige, potentiell auslieferbare Software-Version.

4. Erweiterungen

Da Scrum nur einen sehr kleine Rahmen vorgibt ergibt es Sinn, diesen nach den eigenen Bedürfnissen anzupassen. Dabei kann man sich bei Best-Practices aus dem Projektmanagement oder der Softwareentwicklung bedienen. Außerdem spielt Scrum wunderbar mit diversen Elementen des Exctreme Programming zusammen.

Beispiele für mögliche Erweiterungen:

Rollen
Kunde

Steht im engen Kontakt mit dem Product-Owner und trägt seine Anforderungen an ihn heran.

Anwender

Sog. Key- oder Power-User, der sich sehr gut mit den abzubildenden Prozessen auskennt. Dient als Vertreter der eigentlichen Nutzergruppe der Anwendung und steht dem Product-Owner oder den Entwicklern für Rückfragen zur Verfügung.

Manager

Schafft den Rahmen für den Einsatz und die Akzeptanz von Scrum im Unternehmen

Aktivitäten
Product-Backlog Refinement

Wird ein laufender Entwicklungsprozess auf Scrum "umgestellt", so existieren vermutlich sehr viele Backlog-Einträge, die es zu schätzen und zu priorisieren gilt. Um das Sprint-Planning nicht unnötig in die Länge zu ziehen, gibt es einen extra Termin (Time-Box z. B. 1 Stunde wöchentlich) bei dem strukturiert das Backlog durchgearbeitet wird.

Artefakte
Sprint-Burndown-Chart

Management-Tool, dass abbildet, wie schnell das Backlog Sprint für Sprint abgearbeitet wird. Daraus lässt sich eine Trendkurve ableiten, die anzeigt, ob der geplante Termin eingehalten werden kann oder nicht. So kann bereits nach wenigen Iterationen entschieden werden, ob mit dem Kunden über die Realisierung gesprochen werden muss oder nicht.

Impediment-Backlog

Übersicht des Scrum-Masters, auf der er die Störfaktoren festhält und deren Auflösung durch sich priorisiert.

Erweiterungen für Backlog-Einträge
Definition of Ready (DoR)

Legt fest ab welcher Detaillierung die Bearbeitung eines Eintrages möglich ist. Existieren User-Stories? Ist er geschätzt? …​

Definition of Done (DoD)

Legt fest, ab wann ein Backlog-Eintrag als vollständig bearbeitet gilt. Existieren Unit-Tests? Existiert eine Dokumentation? Wurde er abgenommen? …​

5. Kritik

Die Entwickler werden, z. B. in der Sprint-Retrospective angehalten sich stetig zu verbessern. Der Scrum-Master hat zwar die Aufgabe Impediments aus dem Weg zu räumen, aber es fehlt ein Feedback zur Arbeit des Product-Owner.

Für die Arbeit an großen und komplexen Projekten, an denen mehrere Scrum-Teams beteiligt sind, gibt es kein Konzept. Hier muss auf externe Skalierungframeworks zurückgegriffen werden.

Scrum ist ausschließlich für Feature-Entwicklung geeinget. Besonders bei der produktgetriebenen Entwicklung gibt es aber im Hintergrund oft weitreichende Maintenance-Aufgaben, die in Scrum nur schwer zu berücksichtigen sind.