“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 bestimmter Scrum-Ereignisse 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.