Scrum Framework
Stand: 9.08.2020
Letzte Bearbeitung: Peter.Rizzola
Autor: Hanna Looks
Inhaltsverzeichnis
Agiles Wiki Verwaltungswissen / Seite: Scrum Framework
Allgemein
Bereits seit den frühen 1990er Jahren wird Scrum als Prozessrahmenwerk in der Entwicklung komplexer Produkte verwendet. Entwickelt von Jeff Sutherland und Ken Schwaber [SS13], ist Scrum weder ein Prozess, noch eine Technik, sondern vielmehr als ein Rahmenwerk zu verstehen, in dem verschiedene Techniken zum Einsatz kommen können. Scrum ist nach Sutherland und Schwaber [SS13] als leichtgewichtig, einfach zu verstehen und schwierig zu meistern, anzusehen. Das Vorgehensmodell Scrum besteht sowohl aus Scrum Teams und den damit verbundenen Rollen Product Owner, ScrumMaster und dem Entwicklungsteam, als auch aus Ereignissen, Artefakten und Regeln. Jede Komponente ist für den Erfolg von Scrum unentbehrlich. Scrum basiert auf der Theorie empirischer Prozesssteuerung, sodass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden [SS13]. Um Prognosesicherheit zu optimieren und Risiken zu kontrollieren, nutzt Scrum einen iterativen, inkrementellen Ansatz. Meetings innerhalb von Scrum stellen Ereignisse, mit einer klaren zeitlichen Begrenzung dar.
Scrum-Prozess
Scrum Team
Ein Scrum Team besteht aus den im Folgenden erläuterten Rollen, Product Owner, Scrum Master und Entwicklungsteam. Das Scrum Team ist selbstorganisierend und interdisziplinär.
Product Owner
Der Product Owner ist eine einzelne Person und ist sowohl für die Wertmaximierung des Produktes, als auch für die Arbeit des Entwicklungsteams verantwortlich. Der Product Owner übernimmt als einzige Person das Management des Product Backlogs.
Scrum Master
Der Scrum Master sorgt dafür, dass das Scrum Team die Praktiken und Regeln von Scrum einhält. Er ist für das Verständnis und Durchführung von Scrum verantwortlich und ermöglicht dem Scrum Team ein selbstorganisiertes Arbeiten, indem er Hindernisse beseitigt.
Team
Das Team ist selbstorientierend und interdisziplinär. Es besteht aus Profis, die daran arbeiten, ein potentiell auslieferbares Inkrement am Ende eines Sprints zu übergeben. Innerhalb eines Entwicklungsteams gibt es keine weiteren Unterteilungen.
Ereignisse
In Scrum werden vorgeschriebene Ereignisse mit einer festen zeitlichen Beschränkung (Time Box) verwendet. Die im Folgenden genannten Ereignisse werden nach dem von Sutherland und Schwaber [SS13] geschriebenen ScrumGuide aus dem Jahr 2013 erläutert.
Sprint
Der Sprint stellt einen Arbeitsabschnitt von maximal einem Monat dar. Ziel ist, innerhalb dieses Arbeitsabschnittes ein fertiges, nutzbares und potenziell auslieferbares Produkt-Inkrement herzustellen. Ein Sprint beinhaltet das Sprint Planning, Daily Scrums, Entwicklungsarbeit, ein Sprint Review und die Sprint Retrospektive, die im Folgenden erläutert werden. Sprints ermöglichen eine Hervorsagbarkeit und reduzieren das Risiko hinsichtlich der Kosten auf einen Monat. Der Abbruch eines Sprints, sollte das Sprint-Ziel obsolet sein, ist nur durch den Product Owner möglich. Abbrüche verbrauchen Ressourcen und sind eher unüblich.
Sprint Planning
Sprint Planning ist die Planung des folgenden Sprints und bedarf einer maximalen Zeit von 8 Stunden. Das Sprint Planning wird dazu genutzt, dass das Entwicklungsteam eine Prognose über die Funktionalität, die im Sprint entwickelt werden soll, erstellt und der Product Owner beschreibt das Ziel des Sprints. Im Rahmen des Sprint Plannings wird gemeinsam ein Verständnis über die Arbeitsinhalte des Sprints erarbeitet. Wichtig ist, dass das Entwicklungsteam über die ausgewählten Product Backlog-Einträge entscheidet, da es als selbstorganisiertes Team beurteilen kann, was innerhalb des Sprints machbar ist.
Daily Scrum
Daily Scrum ist ein tägliches Meeting des Entwicklungsteams innerhalb einer Zeit von 15 Minuten. Das Entwicklungsteam überprüft im Daily Scrum den Fortschritt in Richtung des Sprint-Zieles. Es erfolgt ein Austausch hinsichtlich der anstehenden Aktivitäten und den Hindernissen bei der Durchführung/Umsetzung. Ziel ist, den Informationsaustausch untereinander zu erhöhen und andere Meetings überflüssig zu machen.
Sprint Review
Das Sprint Review erfolgt am Ende eines Sprints, um feststellen zu können, ob das Sprint Ziel erreicht wurde und bei Bedarf eine Anpassung des Product-Backlog durchzuführen. Für einen einmonatigen Sprint werden für dieses Meeting vier Stunden angesetzt. Das Scrum Team und auch die Stakeholder beschäftigen sich in diesem Meeting gemeinsam mit den Ergebnissen des Sprints. Ebenfalls wird das Inkrement als Anregung für Feedback vorgeführt. Das Ergebnis des Sprint Review ist ein überarbeitetes Product Backlog mit den Einträgen für den nächsten Sprint.
Sprint Retrospektive
Die Sprint Retrospektive dient dem Scrum Team dazu, zu überprüfen, wie der vergangene Sprint in Bezug auf die beteiligten Menschen, Beziehungen, Prozesse und Werkzeuge verlief und wenn nötig, einen Plan für die Verbesserung der Arbeitsweise des Scrum Teams zu erstellen. Für dieses Meeting werden bei einem einmonatigen Sprint drei Stunden angesetzt und findet zwischen Sprint Review und dem neuen Sprint Planning statt.
Artefakte
Die Artefakte in Scrum wurden speziell dafür entworfen, um Transparenz der wesentlichen Informationen zu schaffen. Nach Sutherland und Schwaber [SS13] enthält Scrum die folgenden Artefakte.
Product Backlog
Das Product Backlog ist eine geordnete und nicht vollständige Liste und dient als einzige Anforderungsquelle. Es entwickelt sich immer weiter und zeigt anfangs nur die bekannten und am besten verstandenen Anforderungen. Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen gelistet. Da sich Anforderungen immer wieder ändern, stellt das Product Backlog ein lebendes Artefakt dar. Der Product Owner ist für das Product Backlog zuständig.
Sprint Backlog
Das Sprint Backlog stellt eine Menge der ausgewählten Product Backlog-Einträge dar und somit die gesamte Arbeit, die für das Erreichen des Sprint-Zieles notwendig ist. Das Sprint Backlog ist ein ausreichend detaillierter Plan und wird während des Sprints von dem Entwicklungsteam angepasst, sodass weitere Arbeiten hinzugefügt und unnötige entfernt werden können. Das Nachverfolgen der verbleibenden Arbeit während eines Sprints ermöglicht dem Entwicklungsteam seinen Fortschritt zu steuern.
Inkrement
Das Product Inkrement stellt das Ergebnis aller in einem Sprint fertiggestellten Product-Backlog Einträge und das Resultat der Inkremente aller vorherigen Sprints dar. Am Ende eines Sprints muss das Inkrement in einem verwendbaren Zustand sein und den Status „Done“ erreicht haben.
Definition of Done
Alle Entwicklungsteammitglieder müssen ein einheitliches Verständnis von dem Status „Done“ haben und somit, wann die Arbeit fertig ist. Dies erfolgt mit dem Ziel, die Transparenz zu wahren. Jedes einzelne Produkt oder System sollte eine Definition of Done haben, die durch das Scrum Team festgelegt wird.
Quellenangaben
[SS13] Sutherland, J.; Schwaber, K.: Scrumguide, Juli 2013.
Seiteninfo
Stand: 9.08.2020
Letzte Bearbeitung: Peter.Rizzola
Seitenpatenschaft: Hanna Looks
