Die vollständige Definition von Scrum ist im "Scrum Guide" von Ken Schwaber und Jeff Sutherland, den Entwicklern von Scrum, zu finden. Der Scrum Guide wird herstellerunabhängig verwaltet und ist auf ScrumGuides.org zu finden.
Diese Version ist eine deutsche Portierung der Version von Juli 2016 und alle Kommentare und Änderungen zur originalen Version von mir werden in eigenen Kästen angezeigt.
In Scrum werden vorgeschriebene Ereignisse verwendet, um eine Regelmäßigkeit herzustellen und die Notwendigkeit anderer, nicht in Scrum definierter, Besprechungen zu minimieren. Alle Ereignisse haben eine zeitliche Beschränkung (Time Box), so dass jedes Ereignis eine maximale Dauer hat. Die Dauer eines Sprints steht zu seinem Beginn fest und darf weder gekürzt noch verlängert werden. Die anderen Ereignisse dürfen beendet werden, sobald sie ihren Zweck erfüllt haben. Dies stellt sicher, dass nur so viel Zeit wie nötig aufgewendet und Verschwendung vermieden wird,
Mit Ausnahme des Sprints als Container für alle anderen Ereignisse ist jedes Scrum Ereignis eine formale Gelegenheit zur Überprüfung und Anpassung. Diese Ereignisse sind genau dazu gedacht, an den kritischen Stellen Transparenz und Überprüfung zu ermöglichen. Das Weglassen irgendeines dieser Ereignisse führt zu verringerter Transparenz und ist eine verpasste Gelegenheit den Ist-Stand zu erfassen und darauf zu reagieren (Inspect & Adapt).
Das Herz von Scrum ist der Sprint, eine Time Box von maximal einem Monat, innerhalb dessen ein fertiges ("Done"), nutzbares und potenziell auslieferbares Produkt-Inkrement hergestellt wird. Alle Sprints innerhalb eines Entwicklungsvorhabens sollten die gleiche Dauer haben. Der neue Sprint startet sofort nach Abschluss des vorigen Sprints
Ein Sprint beinhaltet und umfasst das Sprint Planning, die Daily Scrums, die Entwicklungsarbeit, das Sprint Review und die Sprint Retrospektive.
Während des Sprints:
Jeder Sprint kann als ein Projekt mit einem Zeithorizont von maximal einem Monat gesehen werden. Wie mit einem Projekt will man mit einem Sprint etwas Bestimmtes erreichen. Jeder Sprint hat einen definierten Leistungsumfang, einen Entwurf und einen flexiblen Plan, der die Umsetzung, Arbeit und Ergebnis in die richtige Richtung führt.
Sprints sind auf einen Kalendermonat beschränkt. Wenn der Zeithorizont eines Sprints zu groß gewählt wird, kann sich die Definition des Ergebnisses ändern, die Komplexität ansteigen und sich das Risiko erhöhen. Sprints ermöglichen eine Vorhersagbarkeit, indem sie mindestens einmal im Monat Überprüfung und Anpassungen des Fortschritts zu einem bestimmten Sprint-Ziel ermöglichen. Sprints reduzieren dazu noch das Risiko auf die Kosten eines Monats.
Ein Sprint kann vorzeitig, d.h. vor dem Ablauf seiner Time Box, abgebrochen werden. Dazu ist nur der Product Owner berechtigt, auch wenn er oder sie den Abbruch auf Anraten der Stakeholder, des Entwicklungsteams oder Scrum Masters vornimmt.
Ein Sprint würde dann abgebrochen werden, wenn das Sprint-Ziel obsolet wird. Das kann vorkommen, wenn das Unternehmen seine Zielrichtung wechselt, oder sich andere Markt- oder technologische Rahmenbedingungen ändern. In der Regel sollte ein Sprint dann abgebrochen werden, wenn die Fortführung unter den gegenwärtigen Umständen keinen Sinn mehr macht. Allerdings macht der Abbruch bei der kurzen Dauer der Sprints selten Sinn.
Wenn ein Sprint abgebrochen wird, werden alle abgeschlossenen und "Done" Product Backlog-Einträge begutachtet. Wenn ein Teil der Arbeit potentiell auslieferbar ist, wird sie vom Product Owner meistens abgenommen. Alle unvollständigen Product Backlog-Einträge werden neu geschätzt und wieder in das Product Backlog aufgenommen. Die bislang daran geleistete Arbeit verliert schnell an Wert, daher müssen diese Einträge häufiger neu geschätzt werden.
Sprint‐Abbrüche verbrauchen Ressourcen, da sich alle Teammitglieder zum Start des neuen Sprints in einem Sprint Planning neu finden müssen. Sprint-Abbrüche sind zudem oft schmerzhaft für das Scrum Team; sie sind eher unüblich.
Im Sprint Planning wird die Arbeit für den kommenden Sprint geplant. Dieser Plan entsteht durch die gemeinschaftliche Arbeit des gesamten Scrum Teams.
Das Sprint Planning ist auf eine Time Box von maximal 8 Stunden für einen einmonatigen Sprint beschränkt. Bei kürzeren Sprints wendet man normalerweise weniger Zeit auf. Der Scrum Master sorgt dafür, dass das Ereignis stattfindet und die Teilnehmer seinen Zweck verstehen. Er bringt dem Scrum Team bei, das Ereignis innerhalb der Time Box erfolgreich abzuschließen.
Das Sprint Planning beantwortet die folgenden Fragen:
Das Entwicklungsteam erstellt eine Prognose über die Funktionalität, die im Sprint entwickelt werden soll. Der Product Owner beschreibt das Ziel, das mit dem Sprint erreicht werden soll, und die Product Backlog-Einträge, welche - wenn sie in dem Sprint abgeschlossen werden - das Ziel erfüllen. Das ganze Scrum Team erarbeitet gemeinsam ein Verständnis über die Arbeitsinhalte des Sprints.
Als Eingangsgrößen für das Meeting dienen das Product Backlog, das neueste Produkt-Inkrement, die veranschlagte Kapazität des Entwicklungsteams im Sprint sowie die bisherige Leistung desselben. Ausschließlich das Entwicklungsteam bestimmt die Anzahl der ausgewählten Product Backlog-Einträge für den kommenden Sprint. Es kann nur selbst beurteilen, was im kommenden Sprint machbar ist.
Nach der Prognose der Product Backlog-Einträge für den Sprint durch das Entwicklungsteam formuliert das ganze Scrum Team ein Sprint-Ziel aus. Das Sprint-Ziel bildet die Messlatte, die durch die Implementierung der Product Backlog-Einträge im Sprint erreicht wird; es leitet das Entwicklungsteam in der Frage, warum es dieses Produkt-Inkrement erstellt.
Nach der Vereinbarung des Sprint‐Ziels und der Auswahl der Product Backlog-Einträge für den Sprint entscheidet das Entwicklungsteam, wie es das Produkt-Inkrement erstellen möchte, damit die Funktionalität in einen "Done"-Zustand gebracht werden kann. Als Sprint Backlog bezeichnet man die Auswahl der Product Backlog-Einträge für den jeweiligen Sprint plus den Umsetzungsplan des Entwicklungsteams.
Das Entwicklungsteam beginnt normalerweise mit dem Systementwurf und den notwendigen Arbeiten zur Erstellung des funktionsfähigen Produkt-Inkrements. Die Arbeiten können sich in der Größe oder dem geschätzten Aufwand unterscheiden. Auf jeden Fall sollte das Entwicklungsteam genug Arbeit planen, um zu prognostizieren, was im kommenden Sprint fertiggestellt werden kann. Die für die ersten Sprint-Tage geplanten Arbeiten sind nach Abschluss des Meetings in kleinere Einheiten - oft von einem Tag oder weniger - zerlegt. Das Entwicklungsteam organisiert selbst, wie es die Arbeiten im Sprint Backlog angeht, beginnend mit dem Sprint Planning und, nach Bedarf, im Sprint selbst.
Der Product Owner kann dabei helfen, die ausgewählten Product Backlog-Einträge zu klären und ggf. Kompromisse einzugehen. Wenn das Entwicklungsteam herausfindet, dass es sich zu viel oder zu wenig Arbeit vorgenommen hat, kann es die ausgewählten Product Backlog-Einträge neu mit dem Product Owner aushandeln. Das Entwicklungsteam kann auch andere Teilnehmer zu dem Meeting einladen, um technische oder fachliche Unterstützung zu erhalten.
Am Ende des Sprint Plannings sollte das Entwicklungsteam in der Lage sein, Product Owner und Scrum Master zu schildern, wie es als selbstorganisiertes Team an der Erreichung des Sprint-Ziels und der Erstellung des gewünschten Produkt-Inkrements arbeiten möchte.
Das Sprint-Ziel ist eine übergeordnete Zielsetzung für den Sprint, die durch die Implementierung des Product Backlog (-Einträge) erreicht werden kann. Es gibt dem Entwicklungsteam Orientierung, warum sie dieses Produkt-Inkrement bauen. Das Sprint-Ziel wird während des Sprint Planning erarbeitet.
Das Sprint-Ziel bietet dem Entwicklungsteam eine gewisse Flexibilität in Bezug auf die im Sprint zu implementierende Funktionalität. Die ausgewählten Product Backlog-Einträge bilden eine zusammenhängende Funktionalität, die als Sprint-Ziel angesehen werden kann. Das Sprint-Ziel kann aber auch jedes andere verbindende Element sein, welches das Entwicklungsteam - statt in verschiedene Richtungen zu laufen - zur Zusammenarbeit motiviert.
Bei seiner Arbeit behält das Entwicklungsteam sein Sprint-Ziel vor Augen. Um dieses zu erreichen, implementiert es die entsprechende Funktionalität und Technologie. Falls es sich zeigt, dass der Arbeitsumfang von den ursprünglichen Erwartungen abweicht, handelt das Entwicklungsteam gemeinsam mit dem Product Owner eine Änderung des Sprint Backlog-Umfangs für den laufenden Sprint aus.
Das Daily Scrum ist eine Time Box von 15 Minuten, innerhalb derer das Entwicklungsteam seine Aktivitäten synchronisiert und an der Planung für die nächsten 24 Stunden arbeitet. Das geschieht durch die Überprüfung der Arbeit seit dem letzten Daily Scrum und der Prognose der Arbeitsergebnisse, die bis zum nächsten Daily Scrum erreicht werden könnten.
Um die Komplexität zu reduzieren, wird das Daily Scrum an jedem Tag zur gleichen Uhrzeit am gleichen Ort abgehalten. Während des Meetings schildern die Mitglieder des Entwicklungsteams:
Das Entwicklungsteam überprüft im Daily Scrum seinen Fortschritt in Richtung des Sprint-Ziels und den Trend bei der Abarbeitung der Sprint Backlog-Einträge. Das Daily Scrum erhöht die Wahrscheinlichkeit, dass das Entwicklungsteam sein Sprint-Ziel erreicht. Das Entwicklungsteam sollte Tag für Tag im Blick haben, wie es als selbstorganisiertes Team zusammenarbeiten möchte, um das Sprint-Ziel zu erreichen und das erwartete Inkrement zum Sprintende zu liefern. Das Entwicklungsteam oder einzelne Mitglieder treffen sich häufig direkt nach dem Daily Scrum für detailliertere Diskussionen, Anpassungen oder Umplanungen der Arbeit im Sprint.
Während der Scrum Master dafür sorgt, dass ein Daily Scrum stattfindet, ist das Entwicklungsteam für die Durchführung zuständig. Hierzu bringt der Scrum Master dem Entwicklungsteam bei, wie es die 15-minütige Time Box des Daily Scrums einhalten kann.
Der Scrum Master sorgt für die Einhaltung der Regel, dass nur Mitglieder des Entwicklungsteams am Daily Scrum aktiv teilnehmen.
Daily Scrums verbessern die Kommunikation, machen andere Meetings überflüssig, identifizieren zu beseitigende Hindernisse, fokussieren und fördern die schnelle Entscheidungsfindung und erhöhen den Wissensstand des Entwicklungsteams. Das Daily Scrum ist ein entscheidendes Meeting zur Überprüfung und Anpassung.
Am Ende eines Sprints wird ein Sprint Review abgehalten, um das Produkt-Inkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen. Während des Sprint Reviews beschäftigen sich das Scrum Team und die Stakeholder gemeinsam mit den Ergebnissen des Sprints. Zusammen mit eventuellen Änderungen am Product Backlog während des Sprints bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert des Produkts steigernden Punkten. Beim Sprint Review handelt es sich um ein informelles Meeting, keinen Statusreport. Die Vorführung des Inkrements ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht.
Für einen einmonatigen Sprint wird für dieses Meeting eine Time Box von 4 Stunden angesetzt. Für kürzere Sprints wird in der Regel ein kürzerer Zeitrahmen veranschlagt. Der Scrum Master kümmert sich um die Organisation des Meetings und die Vorbereitung der Teilnehmer. Er zeigt allen Teilnehmern, wie sie das Meeting innerhalb der Time Box halten können.
Das Sprint Review beinhaltet die folgenden Elemente:
Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog, das die möglichen Product Backlog-Einträge für den kommenden Sprint enthält. Das Product Backlog kann auch umfassend umgearbeitet werden, um neue Chancen zu nutzen.
Die Sprint Retrospektive bietet dem Scrum Team die Gelegenheit, sich selbst zu überprüfen und einen Verbesserungsplan für den kommenden Sprint zu erstellen.
Sie findet zwischen dem Sprint Review und dem nächsten Sprint Planning statt. Für einen einmonatigen Sprint wird hierfür eine Time Box von drei Stunden angesetzt, für kürzere Sprints ist das Meeting in der Regel kürzer. Der Scrum Master sorgt dafür, dass das Meeting stattfindet und alle Teilnehmer dessen Zweck verstehen. Er sorgt dafür, dass die Time Box eingehalten wird. Aufgrund seiner Verantwortung für den Scrum Prozess nimmt der Scrum Master als gleichberechtigtes Mitglied an der Sprint Retrospektive teil.
Die Sprint Retrospektive wird durchgeführt, um
Der Scrum Master bestärkt das Scrum Team darin, seine Entwicklungsprozesse und -praktiken innerhalb des Scrum Prozessrahmenwerks zu verbessern, um im kommenden Sprint effektiver und befriedigender arbeiten zu können. In jeder Sprint Retrospektive erarbeitet das Scrum Team Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Definition von "Done".
Zum Ende der Sprint Retrospektive sollte das Scrum Team Verbesserungen für den kommenden Sprint identifiziert haben. Die Umsetzung dieser Verbesserungen im nächsten Sprint ist die Anpassungsleistung zur Selbstüberprüfung des Scrum Teams. Auch wenn jederzeit Verbesserungen eingeführt werden können, bietet die Sprint Retrospektive eine formelle Gelegenheit, sich auf die Überprüfung und Anpassung zu fokussieren.
Scrum ist ein Rahmenwerk zur Entwicklung und Erhaltung komplexer Produkte. Dieser Leitfaden beinhaltet die Definition von Scrum. Diese Definition besteht aus den Scrum Rollen, Ereignissen,Artefakten sowie den Regeln, die sie miteinander verbinden. Ken Schwaber und Jeff Sutherland haben Scrum entwickelt; der Scrum Guide wird von ihnen verfasst und veröffentlicht.
Beide stehen gemeinsam hinter dem Scrum Guide.
Scrum (n): 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 höchstmöglichem Wert auszuliefern.
Scrum ist:
Scrum wird seit den frühen 1990er Jahren als Prozessrahmenwerk bei der Entwicklung komplexer Produkte verwendet. Scrum ist weder ein Prozess noch eine Technik zur Erstellung von Produkten, sondern ist vielmehr als Rahmenwerk zu verstehen, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können. Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Entwicklungsvorgehens sichtbar, so dass Sie sich verbessern können.
Das Scrum Rahmenwerk besteht aus Scrum Teams und den mit ihnen verbundenen Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente des Rahmenwerks dient einem spezifischen Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg.
Durch die Regeln von Scrum werden die Beziehungen und Wechselwirkungen zwischen den Ereignissen, Rollen und Artefakten bestimmt. Die Regeln von Scrum sind in diesem Dokument beschrieben.
Bestimmte Taktiken zur Nutzung von Scrum variieren und sind an anderer Stelle beschrieben.
Scrum basiert auf der Theorie empirischer Prozesssteuerung oder kurz "Empirie". Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden. Scrum nutzt einen iterativen, inkrementellen Ansatz, um Prognosesicherheit zu optimieren und Risiken zu kontrollieren. Drei Säulen tragen jede empirische Prozesssteuerung: Transparenz, Überprüfung (Inspection) und Anpassung (Adaptation).
Die wesentlichen Aspekte des Prozesses müssen für diejenigen sichtbar sein, die für das Ergebnis verantwortlich sind. Transparenz erfordert, dass diese Aspekte nach einem gemeinsamen Standard definiert werden, damit die Betrachter ein gemeinsames Verständnis des Gesehenen teilen.
Dies umfasst beispielsweise
Scrum Anwender müssen die Scrum Artefakte und den Fortschritt regelmäßig in Bezug auf die Erreichung des Sprint-Ziels überprüfen, um unerwünschte Abweichungen zu erkennen. Ihre Untersuchungen sollten nicht so häufig erfolgen, dass sie die Arbeit behindern. Den größten Nutzen bringen Überprüfungen, wenn sie gewissenhaft durch kompetente Prüfer dort vorgenommen werden, wo die Arbeit verrichtet wird.
Wenn ein Prüfer feststellt, dass Aspekte des Prozesses von den akzeptablen Grenzwerten abweichen und dass das resultierende Produkt so nicht akzeptabel sein wird, müssen der Prozess oder das zu bearbeitende Material angepasst werden. Die Anpassung muss so schnell wie möglich vorgenommen werden, um weitere Abweichungen zu minimieren.
Scrum schreibt vier formale Ereignisse für Überprüfung und Anpassung vor. Diese werden im Abschnitt Scrum Ereignisse beschrieben:
Wenn die Werte Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt durch das Scrum Team verkörpert und gelebt werden, werden die Scrum-Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen bei allen Beteiligten Vertrauen zueinander auf. Die Mitglieder des Scrum Teams lernen und erforschen diese Werte, indem sie mit den Scrum Ereignissen, Rollen und Artefakten arbeiten.
Der erfolgreiche Einsatz von Scrum beruht darauf, dass alle Beteiligten kompetenter bei der Erfüllung dieser fünf Werte werden. Sie verpflichten sich persönlich dazu, die Ziele des Scrum Teams zu erreichen. Die Mitglieder des Scrum Teams haben den Mut, das Richtige zu tun und an schwierigen Problemen zu arbeiten. Jeder fokussiert sich auf die Arbeit im Sprint und die Ziele des Scrum Teams. Das Scrum Team und seine Stakeholder sind sich einig, offen mit allen Belangen ihrer Arbeit und den damit verbundenen Herausforderungen umzugehen. Mitglieder von Scrum Teams respektieren sich gegenseitig als fähige, eigenverantwortliche Individuen
Scrum Teams liefern Produkte iterativ und inkrementell und maximieren somit die Gelegenheiten für Feedback. Die inkrementelle Auslieferung von "fertigem" (Done) Produkt sorgt dafür, dass stets eine potentiell nützliche Version des Produkts zur Verfügung steht.
Der Product Owner ist die einzige Person, die für das Management des Product Backlogs verantwortlich ist. Das Product Backlog-Management umfasst:
Der Product Owner kann die oben genannten Arbeiten selbst tun oder sie durch das Entwicklungsteam erledigen lassen. Der Product Owner bleibt jedoch immer rechenschaftspflichtig [accountable].
Der Product Owner ist eine einzelne Person, kein Komitee. Er kann zwar die Wünsche eines Komitees im Product Backlog wiedergeben, aber diejenigen, die einen Eintrag des Product Backlogs in seiner Priorität verändern möchten, müssen sich an den Product Owner wenden.
Damit der Product Owner erfolgreich sein kann, muss die gesamte Organisation seine Entscheidungen respektieren. Die Entscheidungen des Product Owners sind in Inhalt und Reihenfolge des Product Backlogs sichtbar. Niemand darf vom Entwicklungsteam verlangen, andere Anforderungen zu bearbeiten. Dem Entwicklungsteam ist es nicht erlaubt, nach den Angaben einer anderen Person als denen des Product Owners zu arbeiten.
Entwicklungsteams sind von der Organisation so strukturiert und befähigt, dass sie ihre eigene Arbeit selbst organisieren und managen. Die daraus resultierende Synergie optimiert die Gesamteffizienz und -effektivität des Entwicklungsteams.
Entwicklungsteams weisen die folgenden Eigenschaften auf:
Die optimale Größe des Entwicklungsteams ist klein genug, um flink zu bleiben und groß genug, um bedeutende Arbeit innerhalb eines Sprints erledigen zu können. Weniger als drei Mitglieder des Entwicklungsteams reduzieren die Interaktion und führen zu geringeren Produktivitätssteigerungen [als bei größeren Teams]. Kleinere Entwicklungsteams können eventuell kein potentiell auslieferbares Produkt‐Inkrement liefern, da sie möglicherweise nicht über alle benötigten Fähigkeiten verfügen. Mehr als neun Mitglieder erfordern zu viel Koordination. Große Entwicklungsteams erzeugen eine zu hohe Komplexität, um durch einen empirischen Prozess gemanagt werden zu können. Product Owner und Scrum Master zählen nicht zu dieser Zahl dazu, sofern sie nicht ebenso die Arbeit aus dem Sprint Backlog erledigen.
Der Scrum Master ist ein Servant Leader für das Scrum Team. Der Scrum Master hilft denjenigen, die kein Teil des Scrum Teams sind, zu verstehen, welche ihrer Interaktionen mit dem Team sich hilfreich auswirken und welche nicht. Der Scrum Master hilft dabei, die Zusammenarbeit so zu optimieren, dass der durch das Scrum Team generierte Wert maximiert wird.
Der Scrum Master dient dem Product Owner auf verschiedene Arten, unter anderem durch das
Der Scrum Master dient dem Entwicklungsteam auf verschiedene Arten, unter anderem durch:
Der Scrum Master dient der Organisation auf verschiedene Arten, unter anderem durch das:
Die Artefakte von Scrum repräsentieren Arbeit oder Wert, um Transparenz sowie Möglichkeiten zur Überprüfung und Anpassung zu schaffen. Die in Scrum definierten Artefakte wurden speziell so entworfen, dass sie die Transparenz der wesentlichen Informationen maximieren, um für alle ein gleiches Verständnis über das Artefakt zu schaffen.
Das Product Backlog ist eine geordnete Liste von allem, was in dem Produkt enthalten sein kann. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. Der Product Owner ist für das Product Backlog verantwortlich - seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge.
Ein Product Backlog ist niemals vollständig. Während seiner ersten Entwicklungsschritte zeigt es nur die anfangs bekannten und am besten verstandenen Anforderungen auf. Das Product Backlog entwickelt sich mit dem Produkt und dessen Einsatz weiter. Es ist dynamisch; es passt sich konstant an, um für das Produkt klar herauszustellen, was es braucht, um seiner Aufgabe angemessen zu sein, im Wettbewerb zu bestehen und den erforderlichen Nutzen zu bieten. Das Product Backlog existiert so lange wie das dazugehörige Produkt.
Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. Ein Product Backlog-Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert.
Das Product Backlog entwickelt sich mit dem Einsatz eines Produktes, dessen Wertsteigerung sowie durch das Feedback des Marktes zu einer längeren, ausführlicheren Liste. Anforderungen werden nie aufhören, sich zu ändern. Daher ist das Product Backlog ein lebendes Artefakt. Änderungen an den Geschäftsanforderungen, Marktbedingungen oder der Technologie können Änderungen am Product Backlog nach sich ziehen.
Häufig arbeiten mehrere Scrum Teams gemeinsam an einem Produkt. Dann wird ein einziges Product Backlog benutzt, um die anstehende Arbeit am Produkt zu beschreiben. In diesem Fall kann ein Gruppierungsattribut für die Product Backlog‐Einträge verwendet werden.
Als Verfeinerung (Refinement) des Product Backlogs wird der Vorgang angesehen, in dem Details zu Einträgen hinzugefügt, Schätzungen erstellt, oder die Reihenfolge der Einträge im Product Backlog bestimmt werden. Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Product Owner und das Entwicklungsteam gemeinsam die Product Backlog-Einträge detaillieren.
Bei der Verfeinerung des Product Backlogs werden die Einträge begutachtet und revidiert. Das Scrum Team bestimmt, wann und wie diese Verfeinerungsarbeit erfolgt. Sie sollte normalerweise nicht mehr als 10% der Kapazität des Entwicklungsteams beanspruchen. Der Product Owner kann jedoch jederzeit die Einträge im Product Backlog aktualisieren oder aktualisieren lassen.
Höher angeordnete Product Backlog-Einträge sind generell klarer und weisen mehr Details auf als niedrigere. Präzisere Schätzungen entstehen auf der Basis von größerer Klarheit und Detailtiefe - je niedriger der Rang, desto weniger Details sind bekannt. Die Product Backlog-Einträge, mit denen sich das Entwicklungsteam im kommenden Sprint beschäftigen soll, werden so weit verfeinert, dass jeder von ihnen innerhalb der Time Box des Sprints auf "Done" gebracht werden kann. Die Product Backlog-Einträge, für die das der Fall ist, werden als "Ready" angesehen - bereit für die Auswahl durch das Entwicklungsteam in einem Sprint Planning. Ein Product Backlog-Eintrag entwickelt diesen Transparenzgrad in der Regel durch die oben beschriebenen Verfeinerungs-Aktivitäten.
Das Entwicklungsteam ist für alle Schätzungen verantwortlich. Der Product Owner kann das Entwicklungsteam dahingehend beeinflussen, dass er ihm beim Verständnis der Einträge hilft oder Kompromisse eingeht. Die endgültige Schätzung erfolgt immer von denen, die auch die Arbeit erledigen werden.
Die verbleibende Arbeit zur Erreichung eines Ziels kann jederzeit aufsummiert werden. Der Product Owner vermerkt diese gesamte verbleibende Arbeit mindestens zu jedem Sprint Review. Er vergleicht diesen Betrag mit der verbleibenden Arbeit in früheren Sprint Reviews, um den Fortschritt der Arbeiten im Verhältnis zur restlichen Zeit zu begutachten. Diese Information wird allen Stakeholdern präsentiert.
Zur Fortschrittsprognose werden diverse Planungspraktiken eingesetzt, wie Burndown- oder Burnupdiagramme. Diese haben sich als nützlich erwiesen, allerdings ersetzen sie nicht die Wichtigkeit des empirischen Vorgehens. In komplexen Umgebungen lassen sich zukünftige Ereignisse nicht vorherbestimmen. Nur was geschehen ist, gibt Anhaltspunkte für die zukunftsgerichtete Entscheidungsfindung.
Das Sprint Backlog ist die Menge der für den Sprint ausgewählten Product Backlog-Einträge, ergänzt um den Plan für die Lieferung des Produkt‐Inkrements sowie zur Erfüllung des Sprint-Ziels. Das Sprint Backlog ist eine Prognose des Entwicklungsteams darüber, welche Funktionalität im nächsten Inkrement enthalten sein wird, sowie über die erforderliche Arbeit, um diese Funktionalität in einem fertigen – "Done" - Inkrement zu liefern.
Das Sprint Backlog macht die gesamte Arbeit sichtbar, die das Entwicklungsteam für notwendig erachtet, um das Sprint-Ziel zu erreichen.
Das Sprint Backlog ist ein ausreichend detaillierter Plan, um den Fortschritt innerhalb des Sprints im Daily Scrum erkennen zu können. Das Entwicklungsteam passt das Sprint Backlog während des Sprints an; das Sprint Backlog entwickelt sich so während des Sprints. Diese Entwicklung erfolgt, während das Entwicklungsteam den Plan abarbeitet und mehr über die noch benötigten Schritte zur Erreichung des Sprint-Ziels lernt.
Wenn weitere Arbeiten erforderlich sind, werden sie vom Entwicklungsteam zum Sprint Backlog hinzugefügt. Wenn eine Arbeit durchgeführt wird oder abgeschlossen wurde, wird die Schätzung der verbleibenden Arbeit aktualisiert. Wenn sich Bestandteile des Plans als unnötig erweisen, werden sie entfernt. Nur das Entwicklungsteam kann sein Sprint Backlog während des Sprints ändern. Das Sprint Backlog ist ein hochgradig sichtbares Echtzeit-Abbild der Arbeit, die das Entwicklungsteam plant, während des Sprints zu erreichen. Es gehört einzig und allein dem Entwicklungsteam.
Zu jedem Zeitpunkt im Sprint kann die gesamte verbleibende Arbeit an den Sprint Backlog-Einträgen aufsummiert werden. Das Entwicklungsteam verfolgt diese gesamte Restarbeit mindestens zu jedem Daily Scrum, um die Wahrscheinlichkeit, das Sprint-Ziel zu erreichen, sichtbar zu machen. Durch die Nachverfolgung der verbleibenden Arbeit während des Sprints kann das Entwicklungsteam seinen Fortschritt steuern.
Das Inkrement ist das Ergebnis aus allen in einem Sprint fertiggestellten Product Backlog-Einträgen und dem Resultat der Inkremente aller früheren Sprints. Am Ende eines Sprints muss das neue Inkrement "Done" sein; das heißt es muss in einem verwendbaren Zustand sein und die Definition of Done des Teams erfüllen. Es muss auch dann im einsatzfähigen Zustand sein, wenn der Product Owner es aktuell noch gar nicht ausliefern will.
Scrum basiert auf Transparenz. Entscheidungen zur Wertoptimierung und Risikokontrolle werden auf der Basis des festgestellten Zustands der Artefakte vorgenommen. Diese Entscheidungen haben in dem Maß eine solide Basis, in dem die Transparenz der Artefakte umfassend ist. Bei einer unvollständigen Transparenz können Entscheidungen auf Sand gebaut sein, Wert kann gemindert und das Risiko erhöht werden.
Der Scrum Master muss mit dem Product Owner, dem Entwicklungsteam und anderen Beteiligten herausfinden, ob die Artefakte wirklich vollkommen transparent sind. Es gibt Methoden für den Umgang mit fehlender Transparenz; der Scrum Master muss jedem dabei helfen, die bestmöglichen Praktiken zu finden und anzuwenden, wenn vollständige Transparenz nicht gewährleistet werden kann. Ein Scrum Master spürt mangelnde Transparenz durch die Überprüfung der Artefakte, die Erkennung von Mustern, intensives Zuhören, und die Erkennung von Abweichungen zwischen den erwarteten und den tatsächlichen Resultaten auf.
Die Aufgabe des Scrum Masters ist es, mit dem Scrum Team und der Organisation an der Verbesserung der Transparenz der Artefakte zu arbeiten. Diese Arbeit bedeutet zumeist Lernen, Überzeugen und Verändern. Transparenz fällt einem nicht in den Schoß, sie ist ein Weg, den es zu beschreiten gilt.
Es müssen alle verstehen, was "Done" bedeutet, sobald ein Product Backlog-Eintrag oder ein Produkt-Inkrement als "Done" bezeichnet wird. Obwohl sich dies erheblich von Scrum Team zu Scrum Team unterscheidet, müssen alle Teammitglieder ein gemeinsames Verständnis davon haben wann Arbeit fertig ist, um Transparenz zu gewährleisten. Dies erfolgt durch die Definition of Done des Scrum Teams und wird dazu verwendet festzustellen, wann die Arbeit an einem Produkt-Inkrement fertig ist.
Entwicklungsteams liefern jeden Sprint ein Inkrement an Produktfunktionalität. Dieses Inkrement ist vollständig verwendbar, so dass der Product Owner sich jederzeit dazu entscheiden kann, es zu releasen. Wenn die Definition of Done für ein Inkrement Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, müssen alle Scrum Teams diese als Minimalziel befolgen. Wenn "Done" für ein Inkrement nicht Teil der Konvention der Entwicklungsorganisation ist, muss das Entwicklungsteam des Scrum Teams eine für das Produkt geeignete Definition of Done formulieren. Wenn es mehrere Scrum Teams gibt, die am selben System- oder Produktrelease arbeiten, müssen alle Entwicklungsteams aller Scrum Teams gemeinsam eine Definition of Done erstellen.
Jedes Inkrement ist additiv zu allen früheren Inkrementen und gründlich getestet, um sicherzustellen, dass alle Inkremente gemeinsam funktionieren.
Von gereiften Scrum Teams wird erwartet, dass sie ihre jeweilige Definition of Done erweitern, um strengere Kriterien für eine höhere Qualität sicherzustellen. Jedes einzelne Produkt oder System sollte eine Definition of Done haben, welche den Standard für jegliche daran durchgeführte Arbeit darstellt.
Scrum ist kostenlos und wird in Form dieses Guides angeboten. Die Rollen, Artefakte, Ereignisse und Regeln von Scrum sind unveränderlich. Es ist zwar möglich, nur Teile von Scrum einzusetzen - das Ergebnis ist dann aber nicht Scrum. Scrum existiert nur in seiner Gesamtheit und funktioniert sehr gut als Container für andere Techniken, Methoden und Praktiken.
Von den tausenden Menschen, die zu Scrum beigetragen haben, sollten wir diejenigen besonders hervorheben, die für Scrum in seinen ersten zehn Jahren von besonderer Bedeutung waren. Am Anfang standen Jeff Sutherland, welcher mit Jeff McKenna arbeitete, sowie Ken Schwaber, welcher mit Mike Smith und Chris Martin zusammenarbeitete. Viele weitere haben in den folgenden Jahren einen Beitrag geleistet. Ohne deren Hilfe wäre Scrum nicht so ausgefeilt, wie es heute ist.
Ken Schwaber und Jeff Sutherland haben Scrum gemeinsam zum ersten Mal auf der OOPSLA Konferenz 1995 präsentiert. Diese Präsentation dokumentierte im Kern die Erkenntnisse, die Ken und Jeff in den vorher vergangenen Jahren bei der Anwendung von Scrum gewonnen hatten.
Die Geschichte von Scrum kann man heute schon als recht lang ansehen. Zur Würdigung der ersten Orte, an denen Scrum ausprobiert und verfeinert wurde, möchten wir hier Individual, Inc., Fidelity Investments und IDX (heute GE Medical) hervorheben.
Der Scrum Guide dokumentiert Scrum, so wie es seit über 20 Jahren von Jeff Sutherland und Ken Schwaber konzipiert und weiterentwickelt wird. Andere Quellen liefern Ihnen Modelle, Prozesse und Einsichten, die das Rahmenwerk von Scrum ergänzen. Damit lassen sich die Produktivität, der Wert, die Kreativität und der Stolz auf das Erreichte beständig erhöhen.
Dieser Guide wurde von der englischen Originalversion, bereitgestellt von Ken Schwaber und Jeff Sutherland, übersetzt. Hierzu beigetragen haben:
Andreas Schliep, Jan Gretschuskin, Ulf Schneider, Wolfgang Wiedenroth, Dominik Maximini, Pascal Naujoks, Boris Steiner, Sabrina Roos, Jürgen Halstenberg, Ralph Jocham, Wolf Dieter Moggert, Patrick Koglin, Harald Schlindwein.
©2016 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.