E-Learning: Scrum Prozess

Für einen sinnvollen Einsatz von Scrum bedarf es Dreierlei, und zwar eines Verständnisses

1. des Scrum-Prozesses,
2. der agilen Techniken und
3. des Projektumfelds, in dem es eingesetzt werden soll.

In Projekten, bei denen Scrum ohne diese Voraussetzungen verwendet wird, führt es meist zu mehr Problemen, als dass es nutzt. Ein Projektmanager, der wohl schon eingehend unter einer solchen Situation gelitten hatte, brachte seinen ganzen Unmut darüber mit diesem Satz zum Ausdruck: »Wenn man Scrum rückwärts liest, heißt es Murks!«.

Begriffe aus der Scrum-Welt

Die Scrum-Methode nutzt sowohl Spezialbegriffe als auch einige Begriffe aus der agilen Welt, die Ihnen bereits in den Kapiteln zuvor begegnet sind. In der folgenden Tabelle sind die wichtigsten Begriffe für einen ersten Überblick aufgeführt.

Scrum-Vokabular
Sprint	Entspricht einer Iteration
Scrum Master	Ist verantwortlich für die Einhaltung des Scrum-Prozesses
Product Owner	Ist als Fachexperte verantwortlich für die Anforderungen
Daily Scrum	Ein Daily Stand-up Meeting
Sprint Retrospective	Ein Meeting zur Rückschau auf den Prozess zwecks kontinuierlicher Verbesserung
Sprint Review	Ein Meeting, um Feedback zum aktuellen Inkrement zu erhalten
Definition of Done	Vom ganzen Team akzeptierte Kriterien dazu, wann genau eine Aufgabe als erledigt gilt
Product Backlog	Die für das Produkt insgesamt umzusetzenden Aufgaben bzw. Anforderungen
Sprint Backlog	Die für die nächste Iteration (Sprint) umzusetzenden Aufgaben bzw. Anforderungen

Die Artefakte in einem Scrum-Prozess

Der Begriff »Artefakte« klingt zunächst vielleicht etwas seltsam. Er stammt aus der Softwareentwicklung. Dort sind damit im weiteren Sinne Dateien gemeint, die während der Entwicklung als (Zwischen-)Ergebnis entstehen. Bei Scrum werden als Artefakte die folgenden drei (Zwischen-)Ergebnisse bezeichnet:

1. Inkrement: Es entspricht einem Teilprodukt der Entwicklung, wie es durch eine Iteration (im Scrum-Prozess Sprint genannt) entsteht.
2. Product Backlog: Damit werden die für das Produkt insgesamt umzusetzenden Aufgaben bzw. Anforderungen erfasst.
3. Sprint Backlog: Das sind die für die nächste Iteration (Sprint) umzusetzenden Aufgaben bzw. Anforderungen.

Inkrement: das Teilprodukt

Ein Inkrement ist ein Teilprodukt, wie es aus einer Iteration – bei Scrum: einem Sprint – hervorgeht. Bei jedem Sprint entsteht ein neues Inkrement. Jedes Inkrement baut auf dem vorhergehenden auf, enthält also alle Produkteigenschaften, die die älteren Inkremente enthielten. Scrum legt zusätzlich besonderen Wert darauf, dass jedes Inkrement in einem funktionsfähigen Zustand ist, der Kunde es also verwenden könnte, wenn er wollte.

Product Backlog: die Anforderungen an das Produkt aus Sicht der Stakeholder

Das Product Backlog enthält die Beschreibungen der verschiedenen Anforderungen an das Produkt. Es wird nie als vollständig angesehen, da sich die Anforderungen im Laufe des Projektes ändern dürfen, um mit den sich ändernden Wünschen der Stakeholder (Kunden, Auftraggeber, Anwender) Schritt zu halten. Die verschiedenen Anforderungen im Product Backlog sind unterschiedlich genau beschrieben, je nachdem, wie genau sie bereits verstanden wurden. Anforderungen, die detailliert genug beschrieben sind, um umgesetzt zu werden, bezeichnet man als »Ready«. Sie können in ein Sprint Backlog (siehe dazu den nächsten Abschnitt) übernommen werden.

Sprint Backlog: Basis für die konkreten Arbeiten

Das Sprint Backlog beschreibt die Arbeiten, die für das aktuelle Inkrement (bei Scrum: Sprint) geplant sind. Dazu werden in einem speziellen Meeting (Sprint Planning, siehe dazu näher unten) passende Anforderungen aus dem Product Backlog ausgewählt. Daraus werden dann wiederum konkrete Aufgaben abgeleitet, so dass deutlich wird, wie genau das Ziel des Sprints erreicht werden kann. Dazu muss natürlich auch der Aufwand für die Aufgaben mit einem konkreten Wert abgeschätzt werden. Als Einheit für diese Schätzung werden gemeinhin Personentage verwendet. Das Team aktualisiert das Sprint Backlog während eines Projektes fortlaufend. Daher wird durch einfaches Aufsummieren der Aufwandsschätzungen aller noch ausstehenden Aufgaben leicht ersichtlich, ob ein Team aktuell im Plan liegt.

Das Sprint Backlog gehört denjenigen, die die Anforderungen umsetzen. Es darf daher auch nur von ihnen verändert werden. Da ausschließlich sie sich um die Aufgaben im Sprint Backlog kümmern müssen bzw. sollen, ist es somit nicht erlaubt, von außen neue Aufgaben an sie heranzutragen.

Sprints

Während eines Sprints wird also vom Scrum Team ein Teilprodukt entwickelt. Ein Sprint darf bei Scrum höchstens einen Monat dauern. Die verschiedenen Sprints innerhalb eines Scrum-Prozesses sollten jeweils die gleiche Dauer haben. Dabei schließen die Sprints zeitlich direkt aneinander an. Zu Beginn eines Sprints wird genau festgelegt, welche Anforderungen im Sprint umgesetzt werden sollen. Währenddessen dürfen dann keine neuen Anforderungen hinzukommen.

Beim Einsatz von Scrum in einem klassischen Projektumfeld gehört die zeitlich begrenzte Fokussierung des Teams auf ein klares Sprintziel zu den Elementen, die von Projektleitern als besonders wertvoll wahrgenommen werden. In extremen Fällen wird der Einsatz von Scrum sogar nur auf dieses Element reduziert. Natürlich kann man dann nicht mehr wirklich von Scrum sprechen, obwohl das in der Praxis häufig vorkommt.

Wichtige Regeln für einen Sprint sind vor allem die folgenden:

• Ein Sprint dauert höchstens einen Monat.
• Während eines Sprints werden keine neuen Anforderungen von außen in das Scrum Team gegeben.
• Falls nötig, kann der Umfang eines Sprints vom Scrum Team angepasst werden.

Zu einem Sprint sind verschiedene Ereignisse vorgeschrieben, die im Allgemeinen in Form von Meetings stattfinden (siehe dazu ausführlich die nächsten Abschnitte):

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

In der Praxis findet parallel zu den Sprints oft das sog. Backlog Grooming statt. Dabei werden die Einträge im Product Backlog für das Sprint Backlog vorbereitet (also beispielsweise die Beschreibungen verfeinert). Es können dabei auch Einträge im Product Backlog verändert, gelöscht oder hinzugefügt werden, um die Gesamtplanung an veränderte Kundenwünsche anzupassen.

Der Begriff des Sprints ist übrigens eine ungünstige Metapher. Er legt nahe, dass es darauf ankommt, eine Weile lang unter Einsatz all seiner Kräfte besonders schnell vorwärts zu kommen. Tatsächlich sollen die Teams in den Sprints aber nachhaltige Arbeitsgeschwindigkeiten haben. Das ist wichtig, weil die Sprints direkt aneinander anschließen. Es gibt keine Erholungsphasen zwischen ihnen. Zudem wird in Managerkreisen wegen des Sprint-Begriffs gerne fälschlich angenommen, dass die Mitarbeiter nach der Scrum-Methode schneller arbeiten als in anderen Projektformen. Dies ist nur insofern der Fall, als dass durch die bessere Rückkopplung mit dem Auftraggeber Blindleistungen vermieden werden können.

Sprint Planning

Zu Beginn eines Sprints wird während eines sog. Sprint Planning Meetings geplant, welche Anforderungen während des aktuellen Sprints umgesetzt werden sollen. In diese Planung wird das gesamte Scrum Team miteinbezogen. Damit soll insbesondere erreicht werden, dass alle Teammitglieder anschließend auch hinter der Planung des Sprints stehen, um motiviert und eigenverantwortlich an der Zielerreichung mitzuarbeiten.

Es geht bei diesem Termin darum festzulegen, welche Anforderungen des Product Backlogs in das aktuelle Sprint Backlog genommen werden.

• Die Developer sind dafür verantwortlich einzuschätzen, welche Arbeiten für den Sprint realistisch erledigt werden können.
• Der Product Owner ist für die Klärung der ausgewählten Product-Backlog-Einträge zuständig, falls dem Team unklar ist, welche Produkteigenschaften genau Stakeholder sich unter einem bestimmten Backlog-Eintrag vorstellen.
• Der Scrum Master ist für die richtige Durchführung des Sprint Plannings verantwortlich. Dazu gehört auch das Einhalten des von Scrum vorgesehenen Zeitfensters für das Sprint Planning, was auch im Sinne eines strikten Timeboxings ist. Bei einem einmonatigen Sprint sind dafür acht Stunden vorgesehen, ansonsten entsprechend weniger.

Am Ende des Sprint Plannings hat das Scrum Team ein klares Bild, wie das Teilprodukt (Inkrement) am Ende des Sprints aussehen soll und wie dieses Ziel von den Developern erreicht wird.

Daily Scrum

Der Daily Scrum ist ein Daily Stand-up Meeting, das der Koordination des Scrum Teams dient. Insbesondere geht es dabei für jedes Mitglied des Developer Teams um die folgenden Fragen:

• Wer hat seit dem letzten Daily Scrum was genau erreicht?
• Wer arbeitet heute woran?
• Wer hat Probleme, die ihn aufhalten?

Sollte ein Entwickler aktuell ein Problem haben, das ihn an dem Erreichen seiner Ziele hindert – bei Scrum Impediments genannt –, werden vom Team konkrete Gegenmaßnahmen bzw. eine Unterstützung geplant.

Das Team nutzt das Daily Scrum außerdem, um die teamübergreifende Planung der Arbeiten zu überprüfen und bei Bedarf anzupassen. Ein gutes Daily Scrum sorgt dafür, dass das Scrum Team reibungslos arbeitet und der Scrum Master über den Stand der Arbeiten stets auf dem Laufenden bleibt. Es macht dadurch viele andere Meetings überflüssig. Scrum legt als Dauer für das Meeting 15 Minuten fest. Es soll täglich jeweils zur gleichen Zeit und am gleichen Ort stattfinden. Für die richtige Durchführung des Meetings und das Timeboxing ist wiederum der Scrum Master verantwortlich.

Sprint Review

Das Sprint Review entspricht im Wesentlichen dem Review (siehe dazu Kap. »Review«). In diesem Meeting wird zum Ende eines Sprints den wichtigen Stakeholdern, insbesondere den Kunden, das entwickelte Teilprodukt vorgestellt. Beim Sprint Review sehen die Stakeholder den aktuellen Arbeitsstand des Projekts und können bezogen auf die Projektziele nachsteuern. Das bedeutet natürlich, dass sich das Product Backlog während eines Sprint Reviews ändern kann. Dies ist explizit gewünscht.

Am Ende des Sprint Reviews ist das Product Backlog für den nächsten Sprint vorbereitet. Es spiegelt das gewünschte Zielprodukt der Stakeholder unter den aktuellen Rahmenbedingungen wider. Der Scrum Master ist für die richtige Durchführung dieses Termins verantwortlich. Bei einem einmonatigen Sprint sind für das Sprint Review vier Stunden vorgesehen, ansonsten entsprechend weniger.

Sprint Retrospective

Bei diesem Meeting geht es darum, dass das Scrum Team die Zusammenarbeit im Team sowie Werkzeuge und Prozesse zu dieser Zusammenarbeit reflektiert. Das Ziel ist es, daraus konkrete Verbesserungsmaßnahmen für den kommenden Sprint abzuleiten. Die Sprint Retrospective findet zwischen dem Sprint Review des aktuellen Sprints und dem Sprint Planning des kommenden Sprints statt. Scrum legt für das Meeting bei einmonatigen Sprints eine maximale Dauer von drei Stunden fest. Die Verantwortung für die richtige Durchführung liegt beim Scrum Master.