Diese Grundsätze werden allerdings manchmal missverstanden:
Die jeweils zuerst genannten (links stehenden) Ziele sind zwar wichtiger als die anderen (rechts stehend),
aber auch letztere sind wichtig (z.B. Dokumentation):
"That is, while there is value in the items on the right, we value the items on the left more".
Scrum definiert drei Rollen und zusätzlich müssen Stakeholder berücksichtigt werden:
-
Product Owner:
Der Product Owner ist für den Projekterfolg und die Erreichung der wirtschaftlichen Ziele des Projekts verantwortlich.
Er repräsentiert, bündelt und priorisiert die Anforderungen des Endkunden und anderer Interessenvertreter und steuert den Entwicklungsprozess.
Wichtig ist, dass er die Bedürfnisse des Endkunden (und weiterer Interessenvertreter) versteht und diese klar kommunizieren kann.
Er kann auch wichtige übergreifende Architekturentscheidungen fällen.
Anders als zum Beispiel Projektmanager in anderen Vorgehensmodellen arbeitet er während des gesamten Projektverlaufs eng mit dem
Team zusammen.
Er sorgt für die kontinuierliche Aktualisierung der Anforderungen und Priorisierungen im
Product Backlog, nimmt beim
Sprint-Review das Entwicklungsergebnis ab und erstellt den
Sprint-Endbericht,
Releasebericht und
Releaseplan.
-
ScrumMaster:
Der ScrumMaster ist Coach, Moderator und Change Agent.
Er soll möglichst keine Personalverantwortung für die Teammitglieder haben und keine Leistungsbeurteilungen zu den Teammitgliedern abgeben.
Er unterstützt das Team, fördert Lernprozesse und moderiert Besprechungen und bei Konflikten.
Er soll wenig steuern, sondern eher unterstützen und Hindernisse beseitigen.
Er kümmert sich um den Entwicklungsprozess und unterstützt bei der Einführung
von testgetriebener Entwicklung, kontinuierlicher Integration und Refactoring.
Er aktualisiert täglich den
Sprint-Burndown-Bericht,
moderiert die täglichen
Daily-Scrum-Besprechungen,
und moderiert zu Beginn des
Sprint-Zyklusses die
Sprint-Planungssitzung und am Ende die
Sprint-Retrospektive.
-
Team:
Das Team führt die Arbeiten zur Umsetzung der Anforderungen in auslieferbare Produktinkremente aus.
Es besteht meistens aus 5 bis 10 Mitgliedern und kann interdisziplinär aus verschiedenen Rollen zusammengesetzt sein, zum Beispiel
Architekt, UI-Designer, Entwickler, Datenbankexperte, Tester, Dokumentierer und Konfigurationsmanager.
Das Team organisiert sich weitgehend selbst.
Es bestimmt während der
Sprint-Planungssitzung,
wie viele der Anforderungen aus dem
Product Backlog
in das
Sprint Backlog des jeweiligen Sprint-Zyklusses übernommen werden,
ermittelt die dazu notwendigen Aktivitäten/Aufgaben und schätzt den Aufwand.
-
Interessenvertreter (Stakeholder):
Stakeholder sind vom Projektergebnis betroffen, aber wirken nicht aktiv am Projekt mit,
beispielsweise Anwender, Kunde, Manager, Marketing, Vertrieb, Service, Geschäftsführung etc.
-
Produktkonzept ("Vision"):
Bevor das Projekt gestartet und das Product Backlog gefüllt wird, wird häufig ein Produktkonzept erstellt.
Es kann beispielsweise enthalten:
Vision, Produktidee, Funktion, Produkteigenschaften, Zielgrößen, Marktforschungsergebnisse, Befragung von Kunden, Roadmap.
Das Produktkonzept hilft bei der Kommunikation mit Interessenvertretern und bei der Erstellung des Product Backlog.
-
Product Backlog:
Der Product Owner entscheidet über Anforderungen, Funktionalitäten und deren Priorisierung.
Die Anforderungen/Funktionalitäten werden im zentralen Product Backlog gesammelt und regelmäßig aktualisiert.
Anders als beim traditionellen Lastenheft werden sie zu Beginn des Projekts nur grobgranular und unvollständig beschrieben
und erst im Laufe des Projekts präzisiert und vervollständigt.
Da die Anforderungen immer wieder angepasst werden, gibt es bei Scrum keinen zusätzlichen Change-Request-Prozess.
Außer funktionalen werden auch nicht-funktionale Anforderungen beschrieben,
sowie Benutzerschnittstellen, Testumgebungen und Fehlerbehebungen.
Das Product Backlog enthält zu jeder Anforderung Angaben zu:
Priorität, User Story / Beschreibung, Akzeptanzkriterien, Risiken und Aufwandschätzung.
Das Product Backlog enthält nicht Aufgaben und Aktivitäten
(diese sind in den Sprint Backlogs enthalten).
Die einzelnen Einträge ("Items") sollen möglichst
"INVEST-Eigenschaften" aufweisen:
"independent" (unabhängig), "negotiable" (verhandelbar), "valuable" (werthaltig), "estimatable" (schätzbar), "small" (klein), "testable" (testbar).
Die Item-Anforderungsbeschreibungen ("User Story")
sollen möglichst nach folgendem Schema formuliert werden:
Als <Rollenname>
möchte ich <Tätigkeit>,
sodass <Ziel>.
Die Aufwandschätzungen werden nicht vom Product Owner ermittelt, sondern vom
Team (z.B. in "Schätzklausur" / "Estimation Meeting",
z.B. per Planning Poker).
Dabei wird als Maßeinheit häufig nicht in Stunden oder Tagen gerechnet, sondern in relativen "Story Points":
Die Aktivität mit dem geringsten Aufwand erhält "1", eine mit doppeltem Aufwand eine "2" etc.
(gerne mit Story-Point-Werten aus der
Fibonacci-Folge).
Dies erleichtert die Aufwandschätzungen, weil am Anfang die "Entwicklungsgeschwindigkeit"
("Velocity")
des Teams noch nicht feststeht.
Das Product Backlog kann entweder mit Karteikarten geführt werden oder als elektronische Tabelle, beispielsweise folgendermaßen:
| Product Backlog: |
|---|
| Prio |
ID |
Themengruppe |
Item-Anforderungsbeschreibung
als "User Story" |
Akzeptanzkriterien,
Risiken |
Aufwand
(in Story Points) |
| 1 |
4711 |
Online-Bestellung |
Als Kunde möchte ich mich anmelden,
damit ich Bestellungen tätigen kann. |
Authentifizierung und erfolgreicher Log-in. |
2 |
| 2 |
4712 |
Online-Bestellung |
Als Kunde möchte ich Produkte auswählen können,
damit ich sie bestellen kann. |
Produkte werden aufgelistet
(dauert höchstens 5 Sekunden),
Produkt kann ausgewählt werden. |
5 |
| 3 |
... |
... |
... |
... |
... |
|
Als Ergebnis der Sprint-Planung wird aus dem Product Backlog das "Selected Product Backlog" erstellt,
welches die im nächsten Sprint umzusetzenden Anforderungen enthält,
und als Grundlage für das Sprint Backlog dient.
-
Sprint Backlog:
Pro Sprint gibt es einen Sprint Backlog.
Das Sprint Backlog enthält die Definition des Sprint-Ziels ("Sprint Goal") sowie die
Liste der während der Sprint-Dauer umzusetzenden Anforderungen und den dazu notwendigen Aktivitäten/Aufgaben
(möglichst detailliert, möglichst keine Aufgabe länger als 8 Stunden).
Das Team erstellt das initiale Sprint Backlog zu Beginn des Sprints in der
Sprint-Planungssitzung und aktualisiert es täglich
(Aktualisierung der Aufgaben und der Restaufwandschätzung und Kennzeichnung erledigter Aufgaben).
Das Sprint Backlog kann entweder mit Karteikarten an einer Stellwand ("Taskboard") geführt werden oder als elektronische Tabelle, beispielsweise folgendermaßen:
| Sprint Backlog: |
|---|
| Prio |
Anforderung |
Zu erledigen |
In Arbeit |
Blockiert |
Erledigt |
Teststatus |
| 1 |
Anforderung A |
Aktivität A4
Aktivität A5 |
Aktivität A2 (Tim)
Aktivität A3 (Tom) |
- |
Aktivität A1 |
A1 ok |
| 2 |
Anforderung B |
Aktivität B2
Aktivität B3 |
Aktivität B1 (Theo) |
- |
- |
- |
| 3 |
... |
... |
... |
... |
... |
... |
|
-
Sprint-Burndown-Bericht:
Der Sprint-Burndown-Bericht zeigt in einer grafischen Darstellung die Verringerung ("Burndown") des Sprint-Restaufwandes pro Tag über die Sprint-Dauer
(bitte nicht verwechseln mit dem Release-Burndown-Bericht, der die Gesamt-Restaufwand-Verringerung pro Sprint über die gesamte Projektdauer darstellt).
So kann durch einen Vergleich des tatsächlichen Fortschritts mit dem geplanten der Projektfortschritt überprüft werden.
Der Sprint-Burndown-Bericht wird täglich vom
ScrumMaster oder
Team aktualisiert
(nachdem die Teammitglieder das
Sprint Backlog aktualisiert haben).
-
Sprint-Endbericht:
Am Ende eines jeden Sprints (aber noch vor der Sprint-Retrospektive) erstellt der
Product Owner beim
Sprint-Review den Sprint-Endbericht.
Der Sprint-Endbericht fasst den Sprint-Verlauf zusammen.
Enthalten ist die Abnahme umgesetzter Anforderungen,
Verweise auf Testprotokolle und Qualitätsmetriken (z.B. Testabdeckung),
der Sprint-Burndown-Bericht
und der auf der Hindernisliste basierende Hindernisbericht.
Der Sprint-Endbericht sollte maximal zwei DIN-A4-Seiten lang sein.
Als abgenommen gelten nur 100 % fertig umgesetzte Anforderungen.
"Fast fertig" oder "zu 99 % fertig" genügt nicht.
Dies beinhaltet auch Modultests, Integrationstests und funktionale Blackbox-Tests
sowie Architektur-, Design- und Benutzerdokumentation.
Als Product Owner sollten Sie nicht einzelne Teammitglieder loben oder tadeln,
sondern immer nur das gesamte Team.
Jeder im Team soll sich für das Teamergebnis verantwortlich fühlen.
Das Team soll sich als Einheit betrachten und möglichst selbstorganisiert und verantwortlich agieren.
-
Aus der Sprint-Retrospektive resultierende Verbesserungsmaßnahmen:
Am Ende eines jeden Sprints (nach dem Sprint-Review) findet die vom
ScrumMaster moderierte
Sprint-Retrospektive statt.
Dabei wird Feedback zur kontinuierlichen Verbesserung des Entwicklungsprozesses gesammelt ("kaizen").
Es soll ehrlich aber auch respektvoll kommuniziert werden, persönliche Anschuldigungen müssen vermieden werden.
Ein bewährtes Verfahren ist "Mad Sad Glad":
Jeder schreibt die drei wichtigsten positiven und die drei wichtigsten negativen Vorkommnisse auf Karteikarten.
Dabei ergibt sich meistens, welches Thema am wichtigsten ist.
Als Ergebnis werden wenige konkrete Verbesserungsmaßnahmen abgeleitet, welche optimalerweise die "SMART"-Kriterien erfüllen:
"specific" (spezifisch), "measurable" (messbar), "attainable" (erreichbar), "relevant" (relevant) und "timely" (zeitgebunden).
-
Hindernisliste ("Impediment Backlog"):
In den Daily-Scrum-Besprechungen
(tägliche Stand-up-Kurzbesprechung, max. 15 Minuten) sammelt der
ScrumMaster auftretende Hindernisse ("Impediment") in der Hindernisliste.
Der ScrumMaster versucht anschließend die Hindernisse aufzulösen.
Der Product Owner berichtet im
Sprint-Endbericht über die Hindernisse.
-
Releaseplan:
Der Product Owner erstellt den Releaseplan und aktualisiert ihn in jedem Sprint.
Der Releaseplan bietet eine Übersicht zum Zeit- und Kostenrahmen und zu Terminen für Zwischenergebnisse und der Fertigstellung.
Er enthält im Groben die Reihenfolge der Umsetzung der Anforderungen und die erwartete Anzahl Sprints.
Anfangs wird nur im Groben geplant. Im Laufe des Projekts wird regelmäßig iterativ präzisiert.
Dabei wird insbesondere auf Risiken eingegangen.
-
Releasebericht:
Der Releasebericht ermöglicht die Verfolgung des Projektfortschritts und den Vergleich des tatsächlichen Fortschritts mit dem geplanten.
Er kann beispielsweise in Form eines Release-Burndown-Berichts
(grafische Darstellung der Verringerung des Gesamt-Restaufwands pro Sprint über die gesamte Projektdauer),
als Entwicklungsgeschwindigkeitsbericht
(grafische Darstellung der Entwicklungsgeschwindigkeit pro Sprint, z.B. Anzahl abgenommener Story Points pro Sprint)
und/oder als Themenpark (Fertigstellungsgrad gruppiert nach Themen) ausgeführt werden.
-
Tools:
Eine Übersicht zu "Agile Project Management Tools" bietet:
http://www.agile-tools.net.
| Gesamte Projektlaufzeit: |
|---|
| Phase, Tätigkeit | Ergebnis | Bemerkung | Verantwortlich
(und Beteiligte) |
|---|
| Projektstart |
Produktkonzept |
Vision, Produktidee, Funktion, wesentliche Leistungsmerkmale, Zielgrößen, event. Roadmap |
Product Owner
(Kunde, Marketing, Vertrieb, Service, Interessenvertreter) |
Vorbereitung
Releaseplanung |
vorläufiger
Releaseplan |
Zeit- und Kostenrahmen, Termine für Zwischenergebnisse und Endergebnis
(anfangs nur sehr grob) |
Product Owner |
Vorbereitung
Product Backlog |
vorläufiges
Product Backlog |
Liste der Anforderungen:
Prio, User Story, Akzeptanzkriterien, Risiken, Aufwandschätzung
(anfangs nur Wichtiges detailliert, Unwichtiges grobgranular/unvollständig) |
Product Owner
(Kunde, Marketing, Vertrieb, Service, Interessenvertreter) |
| Anforderungsworkshop |
Product Backlog |
Verfeinerung der Anforderungen (entsprechend "INVEST") |
Product Owner
(Team, Kunde, Marketing, Vertrieb, Service) |
| Schätzklausur |
Product Backlog |
"Estimation Meeting": Aufwandschätzung
(z.B. in "Story Points", z.B. per "Planungspoker") |
Team
(Product Owner, ScrumMaster) |
| Sprint 1 |
s.u. |
s.u., max. 1 Monat je Sprint |
Team, ScrumMaster, Product Owner |
| Sprint 2 |
|
|
|
| Sprint ... |
|
|
|
| Sprint n |
|
|
|
| |
|---|
| Jeweiligerer einzelner Sprint (Timeboxing, typischerweise 1 Monat, nicht länger, manchmal kürzer, z.B. 2 Wochen): |
|---|
| Phase, Tätigkeit | Ergebnis | Bemerkung | Verantwortlich
(und Beteiligte) |
|---|
| Sprint-Planungssitzung |
Sprint Backlog |
Jeder Sprint beginnt mit der Sprint-Planungssitzung,
max. 1 Tag (max. 5 % der Sprint-Dauer),
wahlweise in zwei Teilen:
Teil 1:
Definition des Sprint-Ziels (Sprint Goal) und
Auswahl der während der Sprint-Dauer umzusetzenden Anforderungen aus dem Product Backlog in das "Selected Product Backlog".
Dazu Teamkapazität berechnen, Urlaub berücksichtigen,
den Overhead durch zusätzliche nicht dem Projekt direkt nützende Aufwände berücksichtigen
(wird oft auf bis zu 35 % der Arbeitszeit geschätzt).
Teil 2:
Das Team erstellt das "Sprint Backlog", also die möglichst detaillierte Liste der zu den ausgewählten Items notwendigen Aktivitäten/Aufgaben.
|
Team
(Product Owner, ScrumMaster) |
| Softwareentwicklung |
Design,
Implementierung,
Konfiguration,
Tests, Doku etc. |
Aktivitäten/Aufgaben wie im Sprint Backlog definiert,
zuerst die hoch priorisierten |
Team |
Auswählen des
Sprint-Ziels für den
Folge-Sprint |
Sprint-Ziel |
Erwartetes Ergebnis des Folge-Sprints definieren |
Product Owner |
Vorbereitung der
Sprint-Planungssitzung
des Folge-Sprints,
beinhaltet:
- Anforderungsworkshop
- Schätzklausur |
Product Backlog |
zum Sprint-Ziel passende Anforderungen aufbereiten,
iterative Verfeinerung der Anforderungen, Priorisierung, Testbarkeit und Aufwandschätzungen;
max. 1 Tag (max. 5 % der Sprint-Dauer) |
Team, Product Owner |
Releaseplanung
(Planungsworkshop) |
Releaseplan |
iterative Verfeinerung,
Berücksichtigung von Risiken |
Product Owner
(Team) |
Verfolgung des
Projektfortschritts |
Releasebericht |
beispielsweise:
Release-Burndown-Bericht (Burndown über Sprints während gesamter Projektlaufzeit),
Entwicklungsgeschwindigkeit, Themenpark |
Product Owner |
| Sprint-Review |
Sprint-Endbericht |
Überprüfung und Abnahme der Arbeitsergebnisse;
Zusammenfassender Bericht (Abnahme umgesetzter Anforderungen, Sprint-Burndown-Bericht, Hindernisbericht, Qualitätsmetriken);
max. 0,5 Tage (max. 2,5 % der Sprint-Dauer) |
Product Owner
(Team) |
| Sprint-Retrospektive |
Verbesserungs-
maßnahmen |
Feedback für kontinuierlichen Verbesserungsprozess ("kaizen"), Verbesserungsmaßnahmen entsprechend "SMART";
max. 0,5 Tage (max. 2,5 % der Sprint-Dauer) |
ScrumMaster, Team, Product Owner |
| |
|---|
| Einzelner Tag: |
|---|
| Tätigkeit | Ergebnis | Bemerkung | Verantwortlich
(und Beteiligte) |
|---|
| Daily Scrum |
Hindernisliste |
Stand-up-Kurzbesprechung (max. 15 Minuten), täglich selbe Uhrzeit, selber Ort, 3 Fragen:
- was war gestern
- heute anstehende Tätigkeiten/Aufgaben
- Hindernisse |
Team,
ScrumMaster,
Product Owner |
| Softwareentwicklung |
Design,
Implementierung,
Konfiguration,
Tests, Doku etc. |
Aktivitäten/Aufgaben wie beim Daily Scrum besprochen |
Team |
| tägliche Aktualisierung |
Sprint Backlog |
Aktualisierung der Aufgaben und der Restaufwandschätzung, Kennzeichnung erledigter Aufgaben |
Team |
| tägliche Aktualisierung |
Sprint-Burndown-
Bericht |
Burndown über Tage während Sprint-Dauer (nicht verwechseln mit Release-Burndown-Bericht) |
ScrumMaster |
Für Scrum ist die bevorzugte Teamgröße 5 bis höchstens 10 Mitglieder.
Mit "großen Projekten" sind Projekte gemeint, die wesentlich mehr Mitarbeiter benötigen.
Hierfür gibt es besondere Empfehlungen und Zusätzliches zu beachten.
-
Teams
Auch für "große Projekte" gilt, dass die Scrum-Teamgröße nicht wesentlich größer sein sollte, als bei "kleinen Projekten", damit die Teams effektiv arbeiten können.
Deshalb wird bei Scrum nicht die Teamgröße erhöht, sondern stattdessen werden zusätzliche Teams gebildet.
Jedes Team hat einen eigenen
ScrumMaster und möglichst auch einen eigenen
Product Owner.
-
Effektivität
Für eine hohe Effektivität ist ein übergreifendes Verständnis und die Akzeptanz und Motivation für gemeinsame Standards (z.B. Kodierrichtlinien),
gemeinsame Ziele (z.B. Architekturmodell) und Vorgehensweisen (z.B. Versionierung, Continuous Integration und automatisierte Tests) wichtig.
Dies ist bei mehreren Teams schwieriger zu erreichen und bedeutet zumindest höheren Kommunikationsaufwand.
Beachten Sie, dass die Entwicklungsgeschwindigkeit nicht linear mit der Anzahl der Teammitglieder oder mit der Anzahl der Teams wächst.
-
Räumliche Entfernung
Innerhalb einzelner Scrum-Teams sollte immer an einem Ort zusammengearbeitet werden.
Bei mehreren Scrum-Teams ist räumliche Nähe zwischen den Teams zu bevorzugen.
Ist dies nicht möglich, müssen zusätzliche Aufwände für Organisation, Kommunikation und Integration geplant werden.
-
"Product Owner Team"
Wenn es wegen mehrerer Scrum-Teams mehrere Product Owner gibt, bilden diese ein Product Owner Team.
Bei mehr als fünf Teams wird häufig ein zusätzlicher Product Owner benötigt, der kein eigenes Scrum-Team betreut,
sondern nur das Product Owner Team, welches dann als Scrum-Team organisiert wird.
-
"Scrum of Scrums"
Mit "Scrum of Scrums" wird eine tägliche 15-minütige projektübergreifende Besprechung bezeichnet,
zu welcher aus jedem Scrum-Team ein Teilnehmer entsandt wird.
Die dabei zu beantwortenden Fragen sind analog zum Daily-Scrum.
