“Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.” (Scrum.Org and ScrumInc, 2015) Das ganze Rahmenwerk Scrum ist im sogenannten Scrum Guide definiert.

Scrum ist ein Rahmenwerk (engl. Framework), welches auf Empirie beruht. Alle Entscheidungen die getroffen werden beruhen auf den Erfahrungen, welche vorher gemacht wurden. Dies soll dabei helfen Risiken in Projekten besser zu kontrollieren. Das Rahmenwerk wird auf drei Säulen aufgebaut:

• Transparenz
• Überprüfung
• Anpassung

Transparenz bedeutet, dass stets für jeden Teilnehmenden klar ist, wann die aktuelle Aufgabe abgeschlossen (Definition of Done) ist und wie der aktuelle Status der Aufgabe ist. Überprüfung heißt im Scrum-Kontext, dass die momentane Aufgabe immer mit Blick auf die Definition of Done betrachtet werden muss. Abweichung, welche nicht in der Definition of Done enthalten sind, sind zu vermeiden. Die Anpassung wird meistens nach einer Überprüfung durchgeführt. Das ist vorallem dann nötig, wenn des Produkt nicht mehr den Erwartungen entspricht. Sowohl Überprüfung, als auch Anpassungen werden im Normalfall während des Sprint Plannings, Daily Scrums, Sprint Review und Sprint Retrospektive durchgeführt (siehe Kaptiel SCRUM GRUNDLAGEN EREIGNISSE). (Scrum.Org and ScrumInc, 2015)

Der Kern des Scrumteams besteht aus drei Personengruppen:

• Product Owner
• Entwicklungsteam
• Scrum Master

Alle Gruppen arbeiten eigenständig voneinander. Beispielsweise darf dem Entwicklungsteam nicht vorgeschrieben werden, wie sie etwas entwickeln müssen und welche Tools sie dafür zu setzen haben. In diesem Fall ist es lediglich von Priorität, dass das Ziel des Projektes erreicht wird. Im Scrum Guide wird der Product Owner wie folgt definiert: “Der Product Owner ist für die Wertmaximierung des Produkts sowie der Arbeit des Entwicklungsteams verantwortlich.” Es handelt sich dabei lediglich um eine Person und nicht eine Gruppe von Personen. Der Product Owner ist die einzige Person, welche für den Product Backlog verantwortlich ist. Der Product Backlog ist eine Liste die alle Dinge umfasst, welche im finalen Produkt enthalten sein sollen. Er ist niemals vollständig und muss stets angepasst und erweitert werden. Der Product Owner ist dazu verpflichtet den Product Backlog so genau und klar zu formulieren, dass jeder diesen versteht. Auch ist es wichtig, dass diese Liste sortiert wird vom Product Owner, sodass das Entwicklungsteam effizient und optimal arbeiten kann. Das Entwicklungsteam sind die einzigen, welche sogenannte Inkremente entwickeln. Ein Inkrement ist das Resultat aus vorherigen Inkrementen und den in einem Sprint (siehe Kaptiel SCRUM GRUNDLAGEN EREIGNISSE) bearbeiteten Einträgen aus dem Product Backlog. Da das Entwicklungsteam selbstorganisiert arbeitet, muss das Team als Ganzes über alle nötigen Fähigkeiten verfügen um ein Inkrement entwickeln zu können. Wichtig ist, dass, wenn es zu einem Versagen kommt und ein Ziel nicht erreicht wurde, das ganze Team dafür verantwortlich ist und nicht eine einzige Person. Die letzte der drei Personengruppen ist der Scrum Master. Dieser ist dafür zuständig, dass jeder im Scrumteam Scrum versteht und Scrum auch korrekt durchgeführt wird. Sein Ziel ist es die Zusammenarbeit zu optimieren und damit den generierten Wert zu maximieren. So hilft der Scrum Master dem Product Owner den Product Backlog zu erabeiten und ihn so zu formulieren, dass er von jedem verstanden wird. Dem Entwicklungsteam soll der Scrum Master so helfen, dass diese besser selbstorganisiert arbeiten können und so hochwertige Produkte entwickeln. Dazu zählt beispielsweise auch das Beseitigen von Hindernissen und die Erklärung und Organisation von Scrum. (Scrum.Org and ScrumInc, 2015)

Das wichtigste Ereignisse im Ablauf von Scrum ist der Sprint. Der Sprint ist zeitlich begrenzt auf einem Monat und minimal eine Woche. Während des Sprintes wird ein Produkt-Inkrement entwickelt, welches die gesetzte Definition of Done erfüllt und potenziell auslieferbar ist. Zwar ist es möglich einen Sprint abzubrechen, aber auf Grund der Kürze des Sprints ist dies nur dann zu tun, wenn das Ziel des Sprintes obsolet geworden ist. Dies hat lediglich der Product Owner zu entscheiden. Zu Anfang eines Sprintes kommt das Sprint Planning. Die Dauer des Plannings ist an die Dauer eines Sprintes anzupassen. Empfohlen wird für einen ein monatigen Sprint ein acht Stunden Planning. In einem Sprint Planning wird geplant, welche Teile des Product Backlogs im Sprint-Inkrement enthalten sein sollen. Dabei kann das Entwicklungsteam beurteilen, welche Funktionalität zeitlich gesehen in der Dauer des Sprintes implementiert werden kann. Hat das Entwicklungsteam entschieden, welche Einträge aus dem Product Backlog im Sprint bearbeitet werden sollen, verfasst das komplette Scrum Team ein Sprint-Ziel. Das Ziel soll erklären warum das Inkrement entwickelt wird und was erreicht werden muss. Die vom Entwicklungsteam ausgewählten Einträge aus dem Product Backlog für einen Sprint werden als Sprint Backlog bezeichnet. Folgend berät das Entwicklungsteam wie sie die Einträge aus dem Sprint Backlog entwickeln sollen beziehungsweise können. Bei Verständnisfragen kann der Product Owner helfen. Zuletzt erklärt das Entwicklungsteam, sowohl Scrum Master als auch Product Owner, wie es diesen Sprint verfahren will. Folgend hält das Entwicklerteam täglich das sogenannte Daily Scrum ab. Im Daily Scrum erklärt jede einzelne Person was sie am gestrigen Tage erreicht hat, was sie heute erreichen will und welche Hindernisse sie sieht. Alles mit Hinblick auf das Sprint-Ziel. Der Scrum Master ist beim Daily Scrum nur dafür verantwortlich, dass es durchgeführt wird und keine anderen Personen, außer dem Entwicklerteam, daran teilnehmen. Das Daily Scrum ist auf 15 Minuten Dauer beschränkt. Am Ende eines Sprintes wird das Sprint Review und die Sprint Retrospektive durchgeführt. Während des Sprint Reviews wird vom Entwicklerteam das Sprint-Inkrement vorgeführt. Es handelt sich dabei um ein informelles Meeting, welches für einen einmonatigen Sprint eine Dauer von vier Stunden nicht überschreiten sollte. Es ist nicht dazu gedacht einen Statusreport abzugeben, da es vielmehr dem Entwicklerteam Feedback geben soll. Bei dem Sprint Review ist es auch möglich, dass der Product Owner Stakeholder einlädt. Diese können meist noch genaueres Feedback stellen. Wichtig ist, dass das Entwicklungsteam Entwicklungsprobleme nach außen hin kommuniziert. Dies gilt auch wenn diese während des Sprintes schon gelöst wurden. Weiterhin ist es während des Sprint Reviews notwendig zu überprüfen, ob sich die Marktsituation verändert hat und sich somit neue Ziele ergeben, welche im Product Backlog festgehalten werden müssen. So wird das Product Backlog von Sprint zu Sprint immer weiter überarbeitet und somit optimiert. Nach dem Sprint Review wird die Sprint Retrospektive durchgeführt, wobei eine Dauer von drei Stunden bei einem ein monatigen Sprint nicht überschritten werden sollte. Diese Zeit dient dem Scrum Team als Phase der Selbstreflexion. Im Besonderen müssen die Prozesse während des letztens Sprints und die Kommunikation zwischen den teilnehmenden Personen begutachtet werden. Das Scrum Team arbeitet während der Sprint Retrospektive “einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Scrum Teams” aus. Das soll wiederum die Arbeitsweise des Teams effektiver machen, was dazu führt das der Wert des Produktes maximiert wird.