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 Refinement 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 zu den Aktivitäten in Scrum
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.