Scrum beschreibt Rollen, Rituale (Zeremonien und Meetings), und Artefakte die sich für eine iterative Entwicklung von (Software)-Produkten als nützlich erwiesen haben, und liefert somit dem Agile Manifest ein Rahmenwerk für die Zusammenarbeit der Beteiligten Personen.

Artefakte in Scrum

Scrum gibt im Rahmenwerk folgende Artefakte vor, mit denen die Verwaltung des Projekts organisiert wird:

Vision

Die Vision ist im Normalfall eine kurze Beschreibung was mit dem zu erstellenden Produkt erzielt werden soll. Für die Erstellung der Vision werden häufig folgende fünf Fragen gestellt (Frei übernommen von The Product Vision) :

1. Wer wird dieses Produkt kaufen und wer sind die Zielkunden? 
2. Welche Kundennutzen wird das Produkt adressieren? 
3. Welche Produktattribute sind kritisch und müssen deshalb auf alle Fälle umgesetzt werden damit das Produkt erfolgreich sein kann? 
4. Wie ist das Produkt mit anderen Produkten vergleichbar? Was sind die Unique Selling Points dieses Produktes?
5. Was ist der Zeitrahmen und das Budget in dem die Entwicklung und Auslieferung des Produktes erfolgen muss?

Die Vision muss von allen an der Produktentwicklung beteiligten Personen verstanden werden können.

User Story

Um die Vision realisieren zu können, müssen die einzelnen Komponenten, Prozessabläufe usw. beschrieben werden. Hierfür wird im Scrum Umfeld meistens User Stories verwendet.
Eine User Story besteht aus einem Titel, einer Beschreibung und den korrespondierenden Abnahmekriterien.
Die User Story muss von allen beteiligten Personen (Business und Entwicklung) verstanden werden können und dient als Vertrag zwischen den Parteien. Eine User Story muss ein Artefakt in der Form beschreiben, dass dies innerhalb eines kurzen Zeitraums umgesetzt und überprüft werden kann. Beispiel:

Titel
Kunden Login
Beschreibung
Als Kunde möchte ich mich am System mit meinem Usernamen und Passwort anmelden können, damit ich die erweiterten Funktionen nutzen kann.
Abnahmekriterien

• Dem System bekannter Kunde kann sich mit Username und Passwort anmelden und wird zu der Kunden-Startseite geführt
• Ein nicht bekannter Kunde kann sich nicht anmelden
• Falsch eingegebenes Passwort oder Username führt zu einer Fehlermeldung
• Nach drei falschen Eingaben wird der Account für 20 Minuten gesperrt

Epos

Um die Vision umsetzen zu können, müssen die einzelnen Themengebiete beschrieben werden. Ganze Funktionsgruppen sind dabei zu groß um diese innerhalb kurzer Zeiteinheiten umsetzen zu können. Die Beschreibung großer Zusammenhänge innerhalb des Produktes werden Epos (englisch Epic) genannt. Diese großen "Geschichten" werden während des Projekts in User Stories aufgebrochen und umgesetzt (Teile-Herrsche).
Beispiel für ein Epos:

Titel
Alle Kundenbewegungen müssen 10 Jahre historisiert und einsehbar sein.
Beschreibung
Als Auditor muss ich die Möglichkeit haben alle Kundenbewegungen innerhalb des Systems 10 Jahre lang nachvollziehen können damit ich den gesetzlichen Bestimmungen nachkommen kann und jederzeit Audits fahren kann.
Abnahmekriterien

• Jede Kundenbewegung (Beispiel Login, Suchen nach Artikel, Auswahl des Artikels, Bestellung des Artikels, Rechnung bezahlt am ...) wird registriert
• Pro Kunde können die Bewegungen selektiert werden
• Sinnvolle Reports werden dargestellt
• Die Bewegungen können nicht verändert werden (Verwendung von WORM Technologie)

Produkt Backlog

Im Produkt Backlog werden alle bisher erkannten User Stories (egal ob in Form von Epos oder schon klein genug als User Story) abgelegt und priorisiert (Siehe Backlog Grooming). Ein Produkt Backlog ist so angelegt, dass neue Erkenntnisse jederzeit als User Stories hinzugefügt werden können. Die im Produkt Backlog abgelegten User Stories (und Epos) sind mit der Vision abgestimmt und beinhalten nur Beschreibungen die zur Zielerreichung der Vision benötigt werden.

Optional Projekt Backlog

Bei größeren Produkten werden zu weilen mehrere Projekte (parallel oder sequentiell) gestartet um das Produkt zu entwickeln. Weiter können mehrere Produkte in entsprechenden Projekten erarbeitet werden. Hierfür können die im Produkt Backlog festgelegten Epos auf mehrere Projekt Backlogs aufgeteilt werden. Ein Beispiel für die Vision, das Produkt-Backlog und zwei Projekten:

Iterationsbacklog

Scrum ist eine iterative Entwicklungsvorgehensweise. Das bedeutet, dass in einem festgelegten Zeitraum, z.B. zwei Wochen, bestimmte Projektergebnisse vereinbart und umgesetzt werden. Die hierfür benötigten User Stories werden zwischen den Beteiligten verhandelt und in das Iterationsbacklog eingetragen. Im Folgenden findet sich ein Beispiel für zwei Projekte und zwei Projektteams die an der Umsetzung beteiligt sind.

In diesem fiktiven Beispiel soll in der aktuellen Iteration User Story 1, 2, 4, 5 und 7 umgesetzt werden. Damit werden bis auf User Story 3 die Epos 1 vollständig abgearbeitet. Epos 2 wird User Story 7 erarbeitet. Beide Epos sind noch nicht vollständig vorhanden.

Tasks

User Stories beschreiben zu realisierende Artefakte die von einem Team innerhalb einer Iteration umgesetzt werden können. Jede User Story wird vom Team in kleinere Schritte (Tasks ) zerlegt um die Realisierung durchführen zu können. Ein Task kann im Normalfall in einem Arbeitstag umgesetzt werden. Die folgende Skizze zeigt den Zusammenhang zwischen User Story und Task auf. Für User Story 1 werden zwei Tasks benötigt, für User Story 2 nur einer.

Rollen in Scrum

Innerhalb eines Projektes müssen unterschiedliche persönliche Eigenschaften verbunden werden um zielsicher und effizient Produkte entwickeln zu können (Siehe Teamrollen nach Belbin).
Für Scrum wurden folgende Rollen festgelegt:

Product Owner

Der Product Owner erstellt die Vision und verwaltet das Produkt Backlog. Diese Rolle kennt das Geschäftsumfeld und die Kunden. Häufig werden hier Businessvertreter eingesetzt. Die Rolle kann jedoch auch von mehreren Personen ausgefüllt werden. Beispiel: Ein technischer Produkt Owner der den operationellen Betrieb kennt, einen Architekten und Businessvertreter. Eine Person wird als "Master-Produktowner" ausgewählt. Diese Person entscheidet schlussendlich welche User Stories als nächstes umgesetzt werden.

Scrum Team

Das Team beinhaltet die Mitarbeiter, die für die Umsetzung der einzelnen User Stories notwendig sind. Alle notwendigen Skills sind innerhalb des Teams vorhanden um die Aufgaben zu erledigen. (Cross Functional Team) Die Teilnehmer des Teams werden idealerweise über einen längeren Zeitraum in gleicher Besetzung gehalten. Ein Team kann hiermit zusammenwachsen und die Velocity (Entwicklungs-Geschwindigkeit) erhöhen.

Scrum Master

Diese Rolle sorgt dafür, dass alle Beteiligten miteinander arbeiten können. Sie stellt dem Team eine Umgebung zur Verfügung in dem es optimale Arbeitsbedienungen vorfindet.

Experte

Häufig werden für kurze Zeiträume weitere Skills benötigt um User Stories abarbeiten zu können. Beispiele: Ein Rechtsanwalt muss für zwei Iterationen mitarbeiten um rechtliche Fragen zu beantworten. Diese Personen werden bei Bedarf zum Team hinzugefügt, sind Teil des Teams auf Zeit, und verlassen nach dem Einsatz wieder das Team.

Stakeholder

Alle Personen, die nicht direkt mit dem Projekt zu tun haben, werden hiermit abgebildet. Jeder darf einsehen was das Team arbeitet und wie der Projektfortschritt aussieht. Stakeholder dürfen jedoch nur observieren. Falls sie Einfluss auf die Arbeit nehmen wollen, müssen sie über den Product Owner und Scrum Master ihre Wünsche äußern. Ziel ist es, dass das Team sich auf die vereinbarten User Stories konzentrieren kann und nicht abgelenkt wird.

Der Scrum Lebenszyklus

Die Artefakte und Rollen verwenden in Scrum folgenden Lebenszyklus für die Realisierung des Produktes:

Rituale (Zeremonien und Meetings)

Im Scrum Lifecycle sind folgende Rituale beschrieben:

Produkt Backlog Grooming

Koordiniert durch: Produkt Owner

Owner: Produkt Owner

Während der Projektlaufzeit erstellt der Produkt Owner die zu realisierenden User Stories und fügt sie in das Produkt Backlog ein. Als Grundlage für die User Stories dient die Vision. Die Verfeinerung und Ausformulierung der einzelnen User Stories kann von anderen Personen als dem Produkt Owner durchgeführt werden. Owner ist jedoch der Produkt Owner.

Planungsmeeting 1

Koordiniert durch: Scrum Master

Teilnehmer: Produkt Owner, Team und Scrum Master.

Bei diesem Meeting erläutert der Produkt Owner dem Team welche User Stories in der nächsten Iteration abgearbeitet werden sollen. Das Team stellt Fragen und schätzt ab ob die User Stories in einer Iteration umgesetzt werden können. Am Ende des Meetings vereinbaren das Team und der Produkt Owner den Lieferumfang (die User Stories) die als nächstes umgesetzt werden. Nicht gut genug formulierte User Stories werden abgelehnt und zum Produkt Backlog Grooming zurückgeführt.

Planungsmeeting 2

Koordiniert durch: Scrum Master

Teilnehmer: Team, Scrum Master und Optional Produkt Owner

Das Team nimmt die vereinbarten User Stories und zerlegt die Aufgaben in Tasks die in einem Tag erledigt werden können.

Daily Stand-Up Meeting

Koordinator: Scrum Master

Teilnehmer: Team, Scrum Master, optional Produkt Owner und Stakeholders

Während die Iteration läuft werden Tasks abgearbeitet und Teile des Produktes (potentiell lieferbares Produktinkrements) erstellt.
Jeden Tag zur gleichen Zeit am gleichen Ort trifft sich das Team und jedes Team Mitglied beantwortet drei Fragen:

• Was habe ich gestern erarbeitet?
• Was werde ich heute erarbeiten?
• Welche Verhinderer (Impediments) habe ich (Was blockiert mich)?

Falls Impediments vorhanden sind, werden diese vermerkt und vom Scrum Master gelöst.

Review Meeting

Koordinator: Scrum Master

Teilnehmer: Team, Scrum Master, Produkt Owner und Optional Stakeholders

Beim Review Meeting wird das erstellte potentiell lieferbares Produktinkrement präsentiert und kontrolliert ob die in den User Stories festgelegten Abnahmekriterien erreicht wurden. Falls dem so ist, nimmt der Produkt Owner die User Stories ab. Falls Fehler vorhanden sind, oder User Stories nicht abgeschlossen wurden, wird die entsprechende User Story nicht akzeptiert und fließt wieder in das Produkt Backlog ein. Stakeholder können bei diesem Meeting einsehen wie der aktuelle Zustand der Entwicklung aussieht.

Retrospektive

Koordinator: Scrum Master

Teilnehmer: Team, optional Produkt Owner

In diesem Meeting analysiert das Team was innehalb der Iteration gut lief und was verbessert werden sollte. Das Team analysiert den aktuell im Einsatz befindlichen Prozess und versucht diesen zu optimieren um schneller und stabiler entwickeln zu können. Systemische Probleme, die das Team nicht lösen kann, wird vom Scrummaster aufgenommen und dem Management präsentiert. Aus der Retrospektive werden konkrete User Stories erstellt die eine Prozessverbesserung beinhalten. Diese User Stories werden beim nächsten Produkt Backlog Grooming berücksichtigt und aufgenommen. Damit wird ein kontinuierlicher Verbesserungsprozess erreicht.