Glossar – Scrum

Scrum (aus dem englischen scrum für „Gedränge“) ist ein Vorgehensmodell welches vor allem in der Softwareentwicklung Anwendung findet. Ziel ist die schnelle und kostengünstige Entwicklung hochwertiger Produkte. In allgemeinen spricht man über agilen Softwareentwicklungsmethoden

Der Beginn von Scrum lässt sich auf Ikujirō Nonaka und Hirotaka Takeuchi zurückverfolgen. Inspiriert von Ihnen schuf Jeff Sutherland in einem Projekt eine neue Rolle für die Projektleiter. Sie wurden zu Teammitgliedern, und ihre Rolle war eher die eines Moderators als die eines Managers. Zusammen mit Ken Schwaber entstand Scrum ab 1993. Der Name entstand durch den Vergleich zum Gedränge beim Rugby. Teams arbeiten als kleine, selbst-organisierte Einheiten und bekommen von außen nur eine Richtung vorgegeben, bestimmen aber die Taktik, wie sie ihr Ziel erreichen.

Das Scrum Framework kennt drei Rollen: Product Owner, Entwicklungsteam und Scrum Master.

Product Owner

Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich. Im Vordergrund steht der maximale Nutzen. Er erstellt, erklärt und priorisiert die Eigenschaften des Produkts. Er kümmert sich um Eigenschaften, Auslieferungszeitpunkte und Kosten. Als Verantwortlicher für das Endprodukt hält er regelmäßig Rücksprache mit den Stakeholdern, um deren Interessen und Wünsche zu verstehen und abzuwägen.

Entwicklungsteam

Das Entwicklerteam liefert die Funktionalitäten des Produkts in der vom Product Owner gewünschten Reihenfolge. Es besteht in der Regel aus mindestens drei, höchstens neun Mitgliedern. Es übernimmt auch die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards und schätzt den Umfangs der Einträge im Product Backlog. Ideale Teammitglieder hierbei sind sowohl Spezialisten als auch Generalisten, damit sie das Team beim Erreichen des gemeinsamen Ziels effektiv unterstützen.

Scrum Master

Der Scrum Master ist für die Funktionalität der Scrum Rahmenbedingungen zuständig. Er arbeitet mit dem Entwicklungsteam, ist aber kein teil davon. Er überprüft die Einhaltung der Scrum Regeln und versucht Störungen und Hindernisse zu beheben. Der Scrum Master ist für das Entwicklerteam keine Führungskraft sondern ein Coach, welcher Hindernisse beseitigt.

Stakeholder sind Rollen außerhalb des Scrum Frameworks. Sie sind in folgende 3 Rollen aufgeteilt: Kunden, Anwender und Management

Kunden

Der Kunde bekommt das fertige Produkt nach der Fertigstellung. Der Kunde steht mit dem Product Owner während des Projekts ständig im Austausch um zu gewährleisten, dass seine Interessen gewahrt bleiben.

Anwender

Der Anwender ist die Person, welche das Produkt nach fertigstellung tatsächlich benutzt. Ein ANwender kann aber muss nicht zwingend auch der Kunde sein. Anwender sind von Besonderer Wichtigkeit, da sie das Produkt aus der Perspektive eines Nutzern beurteilen können. Deshalb ist es wichtig den Anwender bei Sprint Reviews hinzuzuziehen um ihn das Produkt erproben zu lassen.

Management

Das Management trägt die Verantwortung für die Rahmenbedingungen wie Arbeitsmittel, Räumlichkeiten und die generelle Unterstützung. Es muss das Scrum-Team vor externen Arbeitsanforderungen schützen, adäquate personelle Besetzungen finden und den Scrum Master dabei unterstützen, Hindernisse auszuräumen.

Ein Sprint ist ein Arbeitsabschnitt, in dem ein Inkrement einer Produktfunktionalität implementiert wird. Er beginnt stets mit Sprint Planning und endet mit Sprint Review und Sprint-Retrospektive. Sprints folgen direkt aufeinander. Während eines Sprints sind auch keine Änderungen erlaubt, die das Ziel des Sprints beeinflussen könnten. Ein Sprint umfasst in der Regel ein Zeitfenster von ein bis vier Wochen und sollte idealerweise immer die gleiche Länge haben. Sprints werden nicht verlängert und enden am vorgegebenen Datum.

In Scrum spricht man von Ereignissen oder Events anstelle von Meetings, um klarzustellen, dass es sich um Arbeit handelt. Diese sind wie folgt unterteilt:

Sprint Planning

Im Sprint Planning geht es um 2 Fragen: Was kann im kommenden Sprint entwickelt werden? Wie wird die Arbeit im kommenden Sprint erledigt? Die Sprint-Planung wird daher häufig in zwei Teile geteilt und dauert in Summe maximal 2 Stunden je Sprint-Woche.

Daily Scrum

Zweck des Daily Scrum ist der Informationsaustausch. Hierfür trifft sich das Entwicklerteam Zu Beginn eines jeden Arbeitstages zu einem 10-15 minütigen Daily Scrum. Es geht dabei nicht um aktuelle Probleme, sondern um einen Überblick über die aktuelle Situation.

Sprint Review

Sprint Review steht am Ende des Sprints. Das Scrum-Team überprüft das Inkrement um es bei Bedarf anzupassen. Das Entwicklungsteam präsentiert seine Ergebnisse und prüft, ob das Ziel erreicht wurde. Scrum Team und die Stakeholder besprechen dann die Ergebnisse und die nächsten Schritte. Die Teilnahme von Anwender und Kunde sind entscheidend da sie die Ergebnisse überprüfen und validieren können. Am Ende erhält der Product Owner das Feedback der Stakeholder. Das Sprint-Review dauert maximal 1 Stunde je Sprint-Woche.

Sprint-Retrospektive

Auch die Sprint-Retrospektive steht am Ende eines Sprints. Hierbei überprüft das Scrum Team mit unterstützung des Scrum Masters die bisherige Arbeit, um sie in Zukunft effizienter und effektiver zu sein. Die Verbesserungen werden dokumentiert und geplant. Die Sprint-Retrospektive dauert maximal 45 Minuten je Sprint-Woche.

Transparenz des Fortschritts

Zum Kern von Scrum gehört eine Transparenz über den Fortschritt des Produkts und des Sprints – innerhalb und außerhalb des Teams. Bei Scrum wird für die Transparenz des Fortschritts keine spezifische Technik vorgegeben. Typischerweise werden hierzu aber Burndown-Grafiken verwendet.

Definition of Done

Die Definition of Done (DoD) ist ein gemeinsames Ziel des Scrum Teams, unter welchen Bedingungen die Arbeit als fertig bezeichnet werden kann. Sie ist geprägt von Qualitätskriterien, Einschränkungen und allgemeinen nicht-funktionalen Anforderungen. Je höher die Erfahrung des Scrum Teams desto strenger die Kriterien und Anforderungen.

Definition of Ready

Die Definition of Ready (DOR) ähnelt dem Ansatz der Definition of Done. Sie soll sicherstellen, dass Einträge im Product Backlog vom Team implementiert werden. Verantwortlich für die Einhaltung der DOR ist der Product Owner. Nur Einträge, die Ready sind, können in einen Sprint übernommen werden.

Transparenz des Fortschritts

Zum Kern von Scrum gehört eine Transparenz über den Fortschritt des Produkts und des Sprints – innerhalb und außerhalb des Teams. Bei Scrum wird für die Transparenz des Fortschritts keine spezifische Technik vorgegeben. Typischerweise werden hierzu aber Burndown-Grafiken verwendet.

Definition of Done

Die Definition of Done (DoD) ist ein gemeinsames Ziel des Scrum Teams, unter welchen Bedingungen die Arbeit als fertig bezeichnet werden kann. Sie ist geprägt von Qualitätskriterien, Einschränkungen und allgemeinen nicht-funktionalen Anforderungen. Je höher die Erfahrung des Scrum Teams desto strenger die Kriterien und Anforderungen.

Definition of Ready

Die Definition of Ready (DOR) ähnelt dem Ansatz der Definition of Done. Sie soll sicherstellen, dass Einträge im Product Backlog vom Team implementiert werden. Verantwortlich für die Einhaltung der DOR ist der Product Owner. Nur Einträge, die Ready sind, können in einen Sprint übernommen werden.

Seit 2003 ist es möglich Scrum Zertifizierungen abzuschließen. Neben Scrum-fokussierten Anbietern finden sich auch agile Erweiterungen und Anpassungen der etablierten Projektmanagement-Anbieter wieder. Die Zertifizierungen weisen jeoch unterschiedliche Kosten, Voraussetzungen und Inhalte auf. Zu den bekanntesten gehören ScrumAlliance, Scrum.org und Scrum Inc., die den Scrum Guide von Schwaber und Sutherland als gemeinsamen und zentralen Standard ansehen