Im Folgenden werden nicht nur die wichtigsten Aktivitäten und Artefakte von Scrum erläutert, sondern auch wie diese miteinander verbunden sind.

Der Product Owner hat eine bestimmte Produktvision. Weil das Produkt sehr komplex sein kann, wird es durch sogenanntes Backlog Grooming in kleinere Features (Elemente) aufgebrochen, die in einer Prioritätenliste, dem Product Backlog, aufgeführt werden.

Ein Sprint beginnt mit dem Sprint Planning, beinhaltet die Entwicklungsarbeit (Sprint Execution) während des Sprints und endet mit Review und Retrospektive. Die Anzahl von Punkten im Product Backlog ist in der Regel höher, als sie von einem Entwicklungsteam in einer kurzen Sprint-Phase bewältigt werden könnte. Daher muss das Entwicklungsteam anfangs einige Punkte im Product Backlog bestimmen, von denen es glaubt, sie fertigstellen zu können (Sprint Planning). Ziel ist es am Ende des Sprints ein potentiell auslieferbares Produktinkrement zu haben.

Eine Bemerkung nebenbei:
Im Jahr 2011 hat eine Änderung in “The Scrum Guide” (Schwaber und Sutherland 2011) eine Debatte darüber ausgelöst, ob der passende Terminus zur Beschreibung des Ergebnisses vom Sprint Planning “forecast” (Prognose/Einschätzung) oder “commitment” (Festlegung) sein sollte. Befürworter des Begriffs Forecast bevorzugen diesen Terminus, da sich auch die beste Einschätzung durch neue Informationen im Laufe eines Sprints ändern kann. Es gibt auch die Meinung, ein Commitment seitens des Teams führe dazu, dass die Qualität der Arbeit leide, weil versucht wird, dieses festgesetzte Ziel auf jeden Fall einzuhalten, oder aber weil das Team dazu tendieren kann, sich zu niedrige Ziele zu setzen, damit es diese auf jeden Fall erreichen kann.

Es steht wohl außer Frage, dass jedes Entwicklungsteam eine Einschätzung von dem, was es denkt in einem Sprint schaffen zu können, abgeben sollte. Jedoch könnten viele Entwicklungsteams davon profitieren, wenn sie aus einem Forecast ein Commitment ableiten. Commitments führen nämlich zu stärkerem Vertrauen zwischen Product Owner und dem Entwicklungsteam, genauso wie zwischen den einzelnen Mitgliedern des Teams. Des Weiteren vereinfachen Commitments die kurzfristige Planung und eine sinnvolle Entscheidungsfindung in einem Unternehmen. Wenn mehrere Teams in die Produktentwicklung einbezogen werden, können diese durch Commitments ihre Planung besser aufeinander abstimmen – ein Team kann sich bei seiner Entscheidungsfindung an dem Commitment eines anderen Teams orientieren. Ein Commitment sollte sich jedoch primär am Sprintziel orientieren und nicht so sehr an den offenen Tasks. Mit zunehmendem Wissen gelingt es Teams häufig das Sprintziel anders zu erreichen, als ursprünglich gedacht. (Meist wird im Folgenden der Terminus Commitment benutzt. Sollte der Kontext es erfordern, wird aber hin und wieder auch der Begriff Forecast verwendet.)

Um sicherzustellen, dass das Entwicklungsteam ein sinnvolles Commitment vorgegeben hat, erstellen die Teammitglieder einen zweiten Backlog im Laufe des Sprint Plannings, auch Sprint Backlog genannt. In diesem Sprint Backlog wird anhand von detaillierten Tasks (Aufgaben) beschrieben, wie das Team vorhat, die einzelnen Merkmale aus dem Product Backlog während dieses Sprints zu konzipieren, zu entwickeln, zu integrieren und zu testen.

Der nächste Schritt nennt sich Sprint Execution, also Durchführung des Sprints. Hier führt das Entwicklungsteam die nötigen Aufgaben aus, um die ausgewählten Features realisieren zu können. In dieser Phase gibt es täglich sogenannte Daily Scrums, in denen Synchronisierungs- und Überprüfungsaktivitäten als auch adaptive Planungsaktivitäten vorgenommen werden. Dadurch sind die Teammitglieder in der Lage, ihre Arbeitsabläufe besser zu managen. Am Ende der Sprint Execution hat das Team ein potentiell auslieferbares Produktinkrement produziert, welches bereits einen Teil dessen darstellt, was der Product Owner sich vorgestellt hat.

Das Scrum Team beendet den Sprint mit der Überprüfung und Anpassung (inspect-and-adapt) des Produkts und des Scrum Prozesses . Das Produkt wird im Sprint Review durch das Scrum Team und die Stakeholder geprüft. Die Überprüfung des Scrum Prozesses, der für die Erschaffung eines Produktes genutzt wird, wird bei einem Vorgang namens Retrospektive durch die Teammitglieder durchgeführt. Als Folge dessen können Anpassungen im Product Backlog oder im Entwicklungsprozess vorgenommen werden.

An dieser Stelle beginnt der Sprint-Zyklus von Neuem. Das Entwicklungsteam bestimmt nun die nächsten Product Backlog Items, die es fertigstellen kann. Nach einer angemessenen Anzahl von Sprints wird die Vision des Product Owners realisiert worden sein und das Ergebnis kann dann vorgestellt werden.

Im Folgenden wird jede dieser Aktivitäten und Artefakte noch im Detail behandelt.

Product Backlog

Bei der Arbeit mit Scrum werden immer zuerst die wertvollsten Arbeiten erledigt. Der Product Owner ist – unter Einbeziehung des Entwicklungsteams und der Stakeholder – letztendlich für die Abfolge dieser Arbeitsschritte zuständig und muss diese in einer Prioritätenliste, dem Product Backlog, kommunizieren. Bei der Entwicklung neuer Produkte sind die Product Backlog Items erst einmal nur solche Features, die benötigt werden, um die Vision des Product Owners zu verwirklichen. Bei der Weiterentwicklung von Produkten können im Product Backlog auch neue Features enthalten sein, sowie Abänderungen bereits existierender Features, nötige Reparaturen von Defekten oder technische Verbesserungen usw.

Der Product Owner arbeitet mit internen und externen Stakeholdern zusammen, um die Product Backlog Items zusammenzutragen und zu bestimmen. Dann muss er sicherstellen, dass alle Items in die richtige Reihenfolge gebracht werden (im Bezug auf Wert, Kosten, Wissen und Risiko), sodass die wertvollsten Items ganz oben und die weniger wertvollen Items weiter unten im Product Backlog auftauchen. Der Product Backlog ist ein sich ständig weiterentwickelnder Artefakt. Wenn sich die Umstände für eine Unternehmung ändern oder das Verständnis des Scrum Teams für das Produkt (durch Feedback während der Sprints) wächst, können Items vom Product Owner hinzugefügt, entfernt und überarbeitet werden.

Grundsätzlich wird das Entwerfen, Ausarbeiten, Bewerten und Priorisieren der Product Backlog Items Backlog Grooming bzw. Backlog Refinement genannt.

Bevor man das Priorisieren bzw. Ordnen der Items im Product Backlog abschließen kann, muss allerdings erst der Umfang der einzelnen Items bekannt sein. Der Umfang bestimmt die Kosten und der Product Owner muss diese kennen, um die Priorität eines Items festlegen zu können. Eine bestimmte Maßeinheit wird von Scrum dabei nicht vorgegeben. In der Praxis nutzen viele Teams relative Maßeinheiten wie Story Points oder Ideal Days. Eine relative Maßeinheit drückt nicht den absoluten Umfang eines Items aus, sondern nur seinen Umfang im Verhältnis zu anderen Items.

Sprints

In Scrum gibt es Iterationen oder Zyklen von bis zu einem Monat die Sprints genannt werden. Ein abgeschlossener Sprint sollte immer etwas von greifbarem Wert für den Kunden oder Nutzer hervorbringen.

Für alle Sprints wird ein zeitlicher Rahmen (Timebox) mit festgelegtem Start- und Fertigstellungszeitpunkt vorgegeben, der grundsätzlich bei allen Sprints gleich lang sein sollte. Auf die Fertigstellung eines vorangegangenen Sprints folgt direkt ein neuer Sprint. Auch wenn es Änderungen des Leistungsumfangs oder des Personals gibt, die sich auf das Ziel auswirken würden und so während eines Sprints eigentlich nicht vorgenommen werden dürfen, ist dies aufgrund von gewissen Geschäftsbedürfnissen manchmal nicht vermeidbar.

Sprint Planning

Die Arbeit in einem Produkt Backlog kann mehrere Wochen oder Monate dauern, was weitaus mehr ist, als in einem einzelnen, kurzen Sprint geleistet werden kann. Beim Sprint Planning bestimmen Product Owner, das Entwicklungsteam und der Scrum Master, welche die wichtigsten Product Backlog Items für den nächsten Sprint sind. Bei dieser Planung einigen sich der Product Owner und das Entwicklungsteam auf ein Sprint Ziel, also eine Definition von dem, was im folgenden Sprint geleistet werden soll. Anhand dieser Vorgabe überprüft das Entwicklungsteam den Product Backlog und benennt die wertvollsten Items, die das Team im nächsten Sprint tatsächlich erledigen kann. Die Arbeitsgeschwindigkeit, die auch Sustainable Pace genannt wird, sollte so gewählt werden, dass sie ohne Probleme für längere Zeit aufrechterhalten werden kann.

Um ein Gefühl dafür zu bekommen, was machbar ist, unterteilen viele Teams jedes Product Backlog Item in verschiedene Tasks. Diese bilden, zusammen mit den dazugehörigen Items, einen zweiten Backlog, den Sprint Backlog.

Danach geben die Entwicklungsteams eine Einschätzung über den benötigten Aufwand für jedes Item ab (normalerweise in Stunden). Product Backlog Items in Tasks aufzuspalten ist eine Art von Design und Just-in-Time Planung für die Fertigstellung der Features. Bei einer Sprint Dauer von ein bis vier Wochen, ist das Sprint Planning auf zwei bis acht Stunden zu erledigen – mehr Zeit sollte man dafür nicht veranschlagen. Hierbei gibt es verschiedene Vorgehensweisen, wobei sich eine der beliebtesten an einem einfachen Zyklus orientiert: Man wählt ein Product Backlog Item aus (wenn möglich, das nächste Item in der Rangliste des Product Owners), unterteilt es in Tasks und entscheidet, ob es gut in den Sprint passt (in Hinblick auf andere Items, die für diesen Sprint vorgesehen sind). Sollte es in den Sprint passen und noch genug Zeit übrig sein, wird der Vorgang so lange wiederholt, bis die Kapazitäten des Teams für weitere Aufgaben ausgereizt sind.

Bei einer weiteren Vorgehensweise bestimmen der Product Owner und das Team alle gewünschten Product Backlog Items auf einmal. Nur das Entwicklungsteam nimmt die Aufspaltung in einzelne Tasks vor und bestätigt damit, dass es alle gewünschten Items fertigstellen kann.

Sprint Execution

Sobald das Scrum Team das Sprint Planning abgeschlossen und sich auf den Inhalt des nächsten Sprints geeinigt hat, macht sich das Entwicklungsteam daran, die Arbeit (auf der Task-Ebene) zu erledigen, die zur Fertigstellung der Features nötig ist. Fertigstellung bedeutet in diesem Fall, dass sämtliche Arbeiten erledigt wurden, die für das Produzieren von qualitativ hochwertigen Features notwendig sind.

Niemand gibt dem Entwicklungsteam vor, wie und in welcher Reihenfolge es die Arbeit im Sprint Backlog auf Task-Ebene ausführen soll. Somit können die Teammitglieder selbst ihre Arbeit auf der Task-Ebene festlegen und sich so organisieren, wie es ihrer Ansicht nach optimal für die Erreichung des Sprint Ziels ist.

Daily Scrum / Daily Standup

Jeden Tag während des Sprints, möglichst zur selben Zeit und am selben Ort, halten die Teammitglieder ein Meeting ab, das Daily Scrum genannt wird. Dieses Meeting sollte maximal 15 Minuten dauern. Dieser Inspect-and-Adapt Vorgang wird manchmal auch Daily Stand-Up genannt, da in der Praxis häufig alle Anwesenden stehen bleiben, um das Meeting kurz zu halten.

Eine gängige Vorgehensweise beim Daily Scrum ist, dass die einzelnen Teammitglieder je drei Fragen beantworten, was für den Rest des Teams äußerst hilfreich ist.

Was habe ich seit dem letzten Daily Scrum erreicht?
An was werde ich wohl beim nächsten Daily Scrum arbeiten?
Was genau hält mich davon ab, Fortschritte zu machen?

Durch die Beantwortung dieser Fragen erhält jeder einen Überblick über das was geschieht, über die Fortschritte im Hinblick auf das Sprint Ziel, darüber welche Planänderungen es für den nächsten Tag gibt und welche Probleme behandelt werden müssen. Damit das Team schnelle und flexible Arbeitsabläufe in einem Sprint gewährleisten kann, ist ein Daily Scrum unverzichtbar.

Probleme werden im Daily Scrum nicht gelöst. Stattdessen können sich die Teams nach dem Daily Scrum mit allen Interessierten in kleinen Gruppen treffen, um Probleme zu besprechen. Das Daily Scrum Meeting ist auch kein traditionelles Status-Meeting, wie solche, die von einem Projektmanager einberufen werden, um ihn über den neuesten Stand des Projekts zu informieren. Ein Daily Scrum ist eher dafür gedacht, den Status der Sprint Backlog Items innerhalb des Entwicklungsteams zu kommunizieren. Hauptsächlich ist ein Daily Scrum eine Aktivität, bei der Überprüfungen, Synchronisierungen und adaptive Planung durchgeführt werden, wodurch ein selbstorganisiertes Team noch bessere Arbeit leisten kann.

Definition of Done

In Scrum werden die Ergebnisse der Sprints als potentiell auslieferbare Produktinkremente bezeichnet. Das bedeutet, dass alles was das Scrum Team schaffen wollte, nach der vereinbarten Definition of Done (Definition von dem, was als erledigt angesehen werden kann), auch erledigt wurde. Diese Definition spezifiziert den Grad dessen, dass das Ergebnis der Arbeit auch von guter Qualität und potentiell auslieferbar ist. Bei der Entwicklung von Software, zum Beispiel, sollte die Definition of Done als absolutes Minumum die vollständige Entwicklung einer Produktfunktion vorgeben, welche entworfen, entwickelt, integriert, getestet und dokumentiert wird.

Durch eine aggressive Definition of Done kann ein Unternehmen bei jedem Sprint entscheiden, ob es das, was entwickelt wurde, an interne oder externe Kunden ausliefern möchte.

Nur zum Verständnis: “potentiell auslieferbar” bedeutet nicht, dass etwas auch tatsächlich ausgeliefert werden muss. Dies ist nämlich eine Geschäftsentscheidung, die ständig von Faktoren beeinflusst wird wie “Haben wir ausreichend Features oder genug zur Zufriedenstellung des Kunden beigetragen?” oder “Können unsere Kunden eine weitere Änderung vertragen, wenn wir ihnen doch schon vor zwei Wochen etwas geliefert haben?”.

“Potentiell auslieferbar” sollte eher als der Grad dessen gesehen werden, was im Sprint wirklich geschafft wurde. Das heißt, dass keine wichtigen Arbeiten (wie wichtige Tests oder die Integration usw.) unerledigt sind und erst fertiggestellt werden müssen, ehe das Ergebnis des Sprints ausgeliefert werden könnte. Die Defintion of Done ist nicht in Stein gemeißelt und sollte genauso wie alles andere regelmäßiger Überprüfung und Anpassen unterworfen sein. In der Praxis verändern viele Teams ihre Definition of Done mit der Zeit.

Sprint Review

Am Ende jedes Sprints gibt es zwei weitere Inspect-and-Adapt Aktivitäten. Eine davon bezeichnet man als Sprint Review.

Das Ziel dieser Aktivität ist die Überprüfung und Anpassung des gewünschten Produkts. Ein wesentlicher Bestandteil hierbei ist die Verständigung zwischen Scrum Team, Stakeholdern, Sponsoren, Kunden und interessierten Mitgliedern anderer Teams. Der Schwerpunkt liegt auf der Überprüfung der gerade fertiggestellten Features im Hinblick auf den gesamten Entwicklungsaufwand. Jeder Anwesende bekommt eine klare Vorstellung von dem, was gerade geschieht und hat die Möglichkeit, die weitere Entwicklung zu beeinflussen, um somit die beste Lösung für die Unternehmung zu ermöglichen.

Ein erfolgreiches Review hat einen Informationsfluss in beide Richtungen zur Folge. Die Personen, die nicht im Scrum Team sind können sich über den Stand des Produktes informieren und die nächsten Schritte beeinflussen. Gleichzeitig haben die Mitglieder des Scrum Teams die Möglichkeit, ein besseres Verständnis für die betriebswirtschaftlichen und marketingbezogenen Aspekte zu entwickeln, indem sie ständig Feedback bekommen, ob die Produktentwicklung auf dem Wege ist, dass Kunden und Nutzer von dem Produkt begeistert sein werden. Das Sprint Review stellt also eine geplante Gelegenheit dar, ein Produkt zu überprüfen und anzupassen. Personen außerhalb des Scrum Teams können Feature Reviews während eines Sprints durchführen und Feedback geben, was wiederum dem Scrum Team hilft, sein Sprint Ziel zu erreichen.

Sprint Retrospektive

Die zweite Inspect-and-Adapt Aktivität am Ende eines Sprints ist die Sprint Retrospektive und wird regelmäßig nach dem Sprint Review und vor dem nächsten Sprint Planning durchgeführt. Während ein Sprint Review für die Überprüfung und Anpassung eines Produktes genutzt wird, ist die Sprint Retrospektive eine Gelegenheit, den Prozess zu überprüfen und anzupassen. Bei einer Sprint Retrospektive kommen das Entwicklungsteam, der Scrum Master und der Product Owner zusammen und besprechen, was in der Praxis mit Scrum funktioniert und was nicht. Der Schwerpunkt liegt auf der kontinuierlichen Verbesserung des Prozesses, durch den aus einem guten Scrum Team ein großartiges Scrum Team werden kann. Am Ende einer Sprint Retrospektive sollte das Scrum Team eine sinnvolle Menge an Verbesserungsmaßnahmen identifizieren, die es dann im nächsten Sprint durchführen wird.

Wenn die Sprint Retrospektive beendet ist, fängt der ganze Vorgang von vorne an – beginnend mit einem neuen Sprint Planning, bei dem die nun wertvollsten Arbeiten, auf die sich das Team konzentrieren muss, bestimmt werden.