Diese HTML-Version des Scrum Guides ist eine direkte Portierung der November 2020-Version, die hier als PDFhier erhältlich ist.

Zweck des Scrum Guides

Wir haben Scrum in den frühen 1990er Jahren entwickelt. Wir haben die erste Version des Scrum Guides im Jahr 2010 geschrieben, um Menschen weltweit zu helfen, Scrum zu verstehen. Wir haben den Leitfaden seitdem durch kleine, funktionale Updates weiterentwickelt.Gemeinsam stehen wir dahinter.

Der Scrum Guide enthält die Definition von Scrum. Jedes Element des Rahmens dient einem bestimmten Zweck, der für den Gesamtwert und die mit Scrum erzielten Ergebnisse wesentlich ist. Das Ändern des Kerndesigns oder der Ideen von Scrum, das Weglassen von Elementen oder das Nichtbeachten der Regeln von Scrum verdeckt Probleme und schränkt die Vorteile von Scrum ein und macht es möglicherweise sogar nutzlos.

Wir verfolgen den wachsenden Einsatz von Scrum in einer immer komplexer werdenden Welt.Wir sind demütig zu sehen, dass Scrum in vielen Bereichen mit wesentlich komplexer Arbeit eingesetzt wird, jenseits der Software-Produktentwicklung, in der Scrum seine Wurzeln hat. Während sich der Einsatz von Scrum ausbreitet, erledigen Entwickler, Forscher, Analysten, Wissenschaftler und andere Spezialisten die Arbeit. Wir verwenden das Wort“Entwickler“ in Scrum nicht, um auszuschließen, sondern um zu vereinfachen. Wenn Sie valuefrom Scrum erhalten, betrachten Sie sich als eingeschlossen.

Während Scrum verwendet wird, können Muster, Prozesse und Erkenntnisse, die zu dem in diesem Dokument beschriebenen Scrum-Framework passen, gefunden, angewendet und entwickelt werden. Ihre Beschreibung geht über den Zweck des Scrum-Leitfadens hinaus, da sie kontextsensitiv sind und sich zwischen den Scrum-Anwendungen stark unterscheiden.Solche Taktiken für den Einsatz innerhalb des Scrum-Frameworks sind sehr unterschiedlich und werden an anderer Stelle beschrieben.

Scrum Definition

Scrum ist ein leichtgewichtiges Framework, das Menschen, Teams und Organisationen hilft, durch adaptive Lösungen für komplexe Probleme Mehrwert zu generieren.

Kurz gesagt, Scrum erfordert einen Scrum Master, um eine Umgebung zu schaffen, in der:

1. Ein Product Owner ordnet die Arbeit für ein komplexes Problem in einem ProductBacklog an.

2. Das Scrum-Team verwandelt eine Auswahl der Arbeit während eines Sprints in eine Wertsteigerung.

3. Das Scrum-Team und seine Stakeholder begutachten die Ergebnisse und passen sie für den nächsten Sprint an.

4. Wiederholen

Scrum ist einfach. Probieren Sie es aus und stellen Sie fest, ob seine Philosophie, Theorie und Struktur dazu beitragen, Ziele zu erreichen und Werte zu schaffen. Das Scrumframework ist absichtlich unvollständig und definiert nur die Teile, die zur Implementierung der Scrum-Theorie erforderlich sind. Scrum basiert auf der kollektiven Intelligenz der Menschen, die es benutzen. Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen.

Verschiedene Prozesse, Techniken und Methoden können innerhalb des Rahmens eingesetzt werden. Scrum umschließt bestehende Praktiken oder macht sie unnötig. Scrum macht die relative Wirksamkeit aktueller Management-, Umwelt- und Arbeitstechniken sichtbar, so dass Verbesserungen vorgenommen werden können.

Scrum-Theorie

Scrum basiert auf Empirismus und Lean Thinking. Empirismus behauptetdass Wissen aus Erfahrung kommt und Entscheidungen auf der Grundlage dessen trifft, was beobachtet wird. Lean Thinking reduziert Verschwendung und konzentriert sich auf das Wesentliche.

Scrum verwendet einen iterativen, inkrementellen Ansatz, um die Vorhersagbarkeit zu optimieren und Risiken zu kontrollieren. Scrum bindet Gruppen von Menschen ein, die kollektiv über alle Fähigkeiten und Fachkenntnisse verfügen, um die Arbeit zu erledigen und diese Fähigkeiten nach Bedarf zu teilen oder zu erwerben.

Scrum kombiniert vier formale Ereignisse zur Inspektion und Anpassung in einem zugehörigen Ereignis, dem Sprint. Diese Veranstaltungen funktionieren, weil sie die empirischen Scrum-Säulen Transparenz, Inspektion und Anpassung umsetzen.

Transparenz

Der entstehende Prozess und die Arbeit müssen sowohl für diejenigen sichtbar sein, die die Arbeit ausführen, als auch für diejenigen, die die Arbeit erhalten. Bei Scrum basieren wichtige Entscheidungen auf dem wahrgenommenen Zustand seiner drei formalen Artefakte. Artefakte mit geringer Transparenz können zu Entscheidungen führen, die den Wert verringern und das Risiko erhöhen.

Transparenz ermöglicht Inspektion. Inspektion ohne Transparenz istmissführend und verschwenderisch.

Inspektion

Die Scrum-Artefakte und der Fortschritt in Richtung vereinbarter Ziele müssen häufig und sorgfältig überprüft werden, um potenziell unerwünschte Abweichungen oder Probleme zu erkennen. Um bei der Inspektion zu helfen, bietet Scrum Kadenz in Form seiner fünf Ereignisse.

Inspektion ermöglicht Anpassung. Inspektion ohne Anpassung istbetrachtet sinnlos. Scrum Events sollen Veränderungen provozieren.

Anpassung

Wenn irgendwelche Aspekte eines Prozesses außerhalb akzeptabler Grenzen abweichen oder wenn das resultierende Produkt nicht akzeptabel ist, muss der angewandte Prozess oder die hergestellten Materialien angepasst werden. Die Anpassung muss so schnell wie möglich erfolgen, um weitere Abweichungen zu minimieren.

Die Anpassung wird schwieriger, wenn die beteiligten Personen nichtmächtig oder selbstverwaltet sind. Von einem Scrum-Team wird erwartet, dass es den Moment anpasstes lernt durch Inspektion etwas Neues.

Scrum-Werte

Der erfolgreiche Einsatz von Scrum hängt davon ab, dass die Menschen die fünf Werte besser leben:

Engagement, Fokus, Offenheit, Respekt und Mut

Das Scrum Team verpflichtet sich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen. Ihr Hauptaugenmerk liegt auf der Arbeit des Sprints, um den bestmöglichen Fortschritt in Richtung dieser Ziele zu erzielen. Das Scrum Team und seine Stakeholder stehen der Arbeit und den Herausforderungen offen gegenüber. Scrum Teammitglieder respektieren einander als fähige, unabhängige Menschen und werden von den Menschen, mit denen sie zusammenarbeiten, als solche wahrgenommen. Die Scrum Teammitglieder haben den Mut, das Richtige zu tun, an schwierigen Problemen zu arbeiten.

Diese Werte geben dem Scrum-Team die Richtung für seine Arbeit, sein Handeln und sein Verhalten vor. Die getroffenen Entscheidungen, die ergriffenen Schritte und die Art und Weise, wie Scrum eingesetzt wird, sollten diese Werte stärken, nicht verringern oder einschränken. Die Scrum-Teammitglieder lernen und erforschen die Werte, die sie mit den Scrum-Ereignissen und -Artefakten arbeiten. Wenn diese Werte vom Scrum-Team und den Menschen, mit denen es zusammenarbeitet, verkörpert werden, werden die Empirical Scrum-Säulen Transparenz, Inspektion und Anpassung zum Leben erweckt, um Vertrauen aufzubauen.

Scrum Team

Die grundlegende Einheit von Scrum ist ein kleines Team von Menschen, ein Scrum Team.Das Scrum Team besteht aus einem Scrum Master, einem Product Owner und Entwicklern. Innerhalb eines Scrum Teams gibt es keine Subteams oder hierarchies.It ist eine zusammenhängende Einheit von Fachleuten, die sich jeweils auf ein Ziel konzentrieren, das Produktziel.

Scrum-Teams sind funktionsübergreifend, d.h. die Mitglieder verfügen über alle notwendigen Fähigkeiten, um in jedem Sprint einen Mehrwert zu schaffen. Sie sind auchselbstverwaltend, dh sie entscheiden intern, wer was wann und wie macht.

Das Scrum-Team ist klein genug, um agil zu bleiben, und groß genug, um wichtige Arbeiten innerhalb eines Sprints zu erledigen, in der Regel 10 oder weniger people.In im Allgemeinen haben wir festgestellt, dass kleinere Teams besser kommunizieren und produktiver sind. Wenn Scrum-Teams zu groß werden, sollten sie erwägen, sich in mehrere zusammenhängende Scrum-Teams zu organisieren, die sich jeweils auf dasselbe Produkt konzentrieren. Daher sollten sie dasselbe Produktziel, dasselbe Product Backlog und denselben Product Owner teilen.

Das Scrum-Team ist für alle produktbezogenen Aktivitäten verantwortlich, von der Zusammenarbeit mit den Stakeholdern über die Verifizierung, Wartung, Betrieb, Experimente, Forschung und Entwicklung bis hin zu allem anderen, was erforderlich sein könnte. Sie werden von der Organisation strukturiert und befähigt, ihre eigene Arbeit zu verwalten. Das Arbeiten in Sprints in einem nachhaltigen Tempo verbessert den Fokus und die Konsistenz des Scrum-Teams.

Das gesamte Scrum-Team ist verantwortlich für die Schaffung eines wertvollen, nützlicheninkrement jeden Sprint. Scrum definiert drei spezifische accountabilitiesinnerhalb des Scrum Teams: die Entwickler, der Product Owner und der ScrumMaster.

Entwickler

Entwickler sind die Personen im Scrum-Team, die sich dafür einsetzen, jeden Aspekt eines nutzbaren Inkrements in jedem Sprint zu erstellen.

Die spezifischen Fähigkeiten, die von den Entwicklern benötigt werden, sind oft breit gefächert und variieren mit dem Arbeitsbereich. Die Entwickler sind jedoch immer verantwortlich für:

• Erstellen eines Plans für den Sprint, das Sprint Backlog;

• Qualität durch Einhaltung einer Definition von Done;

• Anpassung ihres Plans jeden Tag an das Sprintziel; und

• Sich gegenseitig als Profis zur Rechenschaft zu ziehen.

Product Owner

Der Product Owner ist verantwortlich für die Maximierung des Produktwerts, der sich aus der Arbeit des Scrum-Teams ergibt. Wie dies geschieht, kann zwischen Organisationen, Scrum-Teams und Einzelpersonen sehr unterschiedlich sein.

Der Product Owner ist auch für ein effektives Product Backlogmanagement verantwortlich, das Folgendes umfasst:

• Entwicklung und explizite Kommunikation des Produktziels;

• Erstellung und klare Kommunikation von Product Backlog Items;

• Bestellung von Product Backlog-Elementen; und

• Sicherstellen, dass das Product Backlog transparent, sichtbar und verständlich ist.

Der Product Owner kann die oben genannten Arbeiten ausführen oder die Verantwortung an andere delegieren. Unabhängig davon bleibt der Product Owner verantwortlich.Damit Product Owner erfolgreich sein können, muss die gesamte Organisation ihre Entscheidungen respektieren. Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs und durch das überprüfbare Inkrement bei der Druckprüfung sichtbar.

Der Product Owner ist eine Person, kein Komitee. Der Product Owner kann die Bedürfnisse vieler Stakeholder im Product Backlog darstellen. Diejenigen, die das Product Backlog ändern möchten, können dies tun, indem sie versuchen, den Product Owner zu überzeugen.

Scrum Master

Der Scrum Master ist verantwortlich für die Etablierung von Scrum, wie im Scrum Guide definiert. Sie tun dies, indem sie jedem helfen, Scrum-Theorie und -Praxis zu verstehen, sowohl innerhalb des Scrum-Teams als auch innerhalb der Organisation.

Der Scrum Master ist für die Effektivität des Scrum Teams verantwortlich. Sie tun dies, indem sie es dem Scrum-Team ermöglichen, seine Praktiken innerhalb des Scrum-Frameworks zu verbessern.

Scrum Master sind echte Führungskräfte, die dem Scrum-Team und der größeren Organisation dienen.

Der Scrum Master dient dem Scrum-Team auf verschiedene Arten, einschließlich:

• Coaching der Teammitglieder in Selbstmanagement und Cross-Funktionalität;

• Unterstützung des Scrum-Teams bei der Erstellung hochwertiger Inkremente, die die Definition von Done erfüllen;

• Beseitigung von Hindernissen für den Fortschritt des Scrum-Teams;und

• Sicherstellen, dass alle Scrum-Events finden statt und sind positiv, produktiv und innerhalb der Timebox gehalten.

Der Scrum Master dient dem Product Owner auf verschiedene Arten, einschließlich:

• Unterstützung bei der Suche nach Techniken für eine effektive Definition von Produktzielen undProduct Backlog Management;

• Unterstützung des Scrum-Teams beim Verständnis der Notwendigkeit klarer und präziserproduct Backlog Items;

• Unterstützung bei der Erstellung einer empirischen Produktplanung für eine komplexe Umgebung; und

• Erleichterung der Zusammenarbeit mit Stakeholdern nach Wunsch oder Bedarf.

Der Scrum Master dient der Organisation auf verschiedene Arten, einschließlich:

• Führung, Schulung und Coaching der Organisation in ihrer Scrum-Option;

• Planung und Beratung von Scrum-Implementierungen innerhalb der Organisation;

• Unterstützung von Mitarbeitern und Stakeholdern beim Verständnis und der Umsetzung eines empirischen Ansatzes für komplexe Arbeit; und

• Beseitigung von Barrieren zwischen Stakeholdern und Scrum-Teams.

Scrum Events

Der Sprint ist ein Container für alle anderen Events. Jedes Ereignis in Scrum ist eine einmalige Gelegenheit, Scrum-Artefakte zu inspizieren und anzupassen. Diese Veranstaltungen sind speziell darauf ausgelegt, die erforderliche Transparenz zu ermöglichen. Wenn Ereignisse nicht wie vorgeschrieben ausgeführt werden, führt dies zu verpassten Inspektions- und Anpassungsmöglichkeiten. Ereignisse werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings zu minimieren, die nicht in Scrum definiert sind.

Optimalerweise werden alle Veranstaltungen zur gleichen Zeit und am gleichen Ort abgehalten, um zu reduzierenkomplexität.

Der Sprint

Sprints sind der Herzschlag von Scrum, bei dem Ideen in Werte umgewandelt werden.

Es handelt sich um Ereignisse mit fester Länge von einem Monat oder weniger, um Konsistenz zu schaffen.Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigensprint.

Alle Arbeiten, die zur Erreichung des Produktziels erforderlich sind, einschließlich Sprintplanung, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb von Sprints statt.

Während des Sprints:

• Es werden keine Änderungen vorgenommen, die das Sprintziel gefährden würden;

• Die Qualität nimmt nicht ab;

• Das Product Backlog wird nach Bedarf verfeinert; und

• Der Umfang kann geklärt und mit dem Product Owner neu verhandelt werden, sobald mehr gelernt ist.

Sprints ermöglichen Vorhersagbarkeit, indem sie mindestens jeden Kalendermonat die Überprüfung und Anpassung des Fortschritts in Richtung eines Produktziels sicherstellen. Wenn der Horizont von aSprint zu lang ist, kann das Sprint-Ziel ungültig werden, die Komplexität kann steigen und das Risiko kann steigen. Kürzere Sprints können eingesetzt werden, um mehr Lernzyklen zu generieren und das Risiko von Kosten und Aufwand auf einen kürzeren Zeitrahmen zu begrenzen. Jeder Sprint kann als Kurzprojekt betrachtet werden.

Es gibt verschiedene Vorgehensweisen, um Fortschritte vorherzusagen, wie Burn-Downs, Burn-ups oder kumulative Flüsse. Diese haben sich zwar als nützlich erwiesen, ersetzen jedoch nicht die Bedeutung des Empirismus. In komplexen Umgebungen wird was passierenunbekannt. Nur das, was bereits geschehen ist, kann für vorausschauende Entscheidungen herangezogen werden.

Ein Sprint kann abgebrochen werden, wenn das Sprintziel obsolet wird. Nur der Product Owner hat die Befugnis, den Sprint abzubrechen.

Sprint Planning

Sprint Planning initiiert den Sprint, indem es die für den Sprint durchzuführenden Arbeiten festlegt. Dieser resultierende Plan wird durch dieArbeit des gesamten Scrum-Teams.

Der Product Owner stellt sicher, dass die Teilnehmer bereit sind, die wichtigsten Product Backlog-Elemente zu diskutieren und wie sie dem ProductGoal zugeordnet werden. Das Scrum-Team kann auch andere Personen einladen, an SprintPlanning teilzunehmen, um Ratschläge zu geben.

Sprint Planning befasst sich mit den folgenden Themen:

Thema Eins: Warum ist dieser Sprint wertvoll?

Der Product Owner schlägt vor, wie das Produkt seinen Wert und Nutzen im aktuellen Sprint steigern könnte. Das gesamte Scrum-Team arbeitet dann zusammen, um ein Sprint-Ziel zu definieren, das kommuniziert, warum der Sprint für die Stakeholder wertvoll ist. Das Sprintziel muss vor dem Ende der Sprintplanung festgelegt werden.

Thema zwei: Was kann in diesem Sprint getan werden?

Im Gespräch mit dem Product Owner wählen die Entwickler Items aus dem Product Backlog aus, die in den aktuellen Sprint aufgenommen werden sollen. Das ScrumTeam kann diese Elemente während dieses Prozesses verfeinern, was das Verständnis und das Vertrauen erhöht.

Die Auswahl, wie viel innerhalb eines Sprints erledigt werden kann, kann eine Herausforderung sein.Je mehr die Entwickler jedoch über ihre vergangene Leistung, ihre bevorstehende Kapazität und ihre Definition von Done wissen, desto zuversichtlicher werden sie in ihren Sprint-Prognosen sein.

Thema drei: Wie wird die gewählte Arbeit erledigt?

Für jedes ausgewählte Product Backlog-Element planen die Entwickler die Arbeitnotwendig, um ein Inkrement zu erstellen, das der Definition von Done entspricht. Dies geschieht häufig durch Zerlegen von Product Backlog-Elementen in kleinere Workitems von einem Tag oder weniger. Wie dies geschieht, liegt im alleinigen Ermessen vondie Entwickler. Niemand sonst sagt ihnen, wie sie Product Backlog-Elemente in Wertsteigerungen umwandeln können.

Das Sprintziel, die für den Sprint ausgewählten Product Backlog-Elemente und der Plan für deren Bereitstellung werden zusammen als SprintBacklog bezeichnet.

Sprint Planning ist timeboxed auf maximal acht Stunden für einen monatSprint. Bei kürzeren Sprints ist die Veranstaltung in der Regel kürzer.

Daily Scrum

Der Zweck des Daily Scrum ist es, den Fortschritt auf dem Weg zum SprintZiel zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die anstehenden geplanten Arbeiten anzupassen.Das Daily Scrum ist eine 15-minütige Veranstaltung für die Entwickler des Scrumteams. Um die Komplexität zu reduzieren, wird es jeden zweiten Tag des Sprints zur gleichen Zeit und am gleichen Ort abgehalten. Wenn der Product Owner oder Scrum Master aktiv an Elementen im Sprint Backlog arbeitet, nehmen sie als Entwickler teil.

Die Entwickler können wählen, welche Struktur und Techniken sie wollen, solange sich ihr Daily Scrum auf den Fortschritt in Richtung des Sprint-Ziels konzentriert und einen umsetzbaren Plan für den nächsten Arbeitstag erstellt. Dies schafftfokus und verbessert das Selbstmanagement.Tägliche Scrums verbessern die Kommunikation, identifizieren Hindernisse, fördern die schnelle Entscheidungsfindung und machen folglich andere Meetings überflüssig.

Das Daily Scrum ist nicht das einzige Mal, dass Entwickler ihren Plan anpassen dürfen. Sie treffen sich oft den ganzen Tag über, um detailliertere Diskussionen über die Anpassung oder Neuplanung des Rests der Sprintarbeit zu führen.

Sprint Review

Der Zweck des Sprint Reviews ist es, das Ergebnis des Sprints zu überprüfen und zukünftige Anpassungen zu bestimmen. Das Scrum-Team stellt den wichtigsten Stakeholdern die Ergebnisse ihrer Arbeit vor, und der Fortschritt in Richtung des Produktziels wird erörtert.

Während der Veranstaltung überprüfen das Scrum-Team und die Stakeholder, was im Sprint abgeschlossen wurde und was sich in ihrer Umgebung geändert hat.Basierend auf diesen Informationen arbeiten die Teilnehmer gemeinsam daran, was als nächstes zu tun ist. Der Produktbestand kann auch angepasst werden, um neuen Möglichkeiten gerecht zu werden. TheSprint Review ist eine Arbeitssitzung und das Scrum-Team sollte es vermeiden, es auf eine Präsentation zu beschränken.

Der Sprint Review ist die vorletzte Veranstaltung des Sprints und istimeboxed auf maximal vier Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist die Veranstaltung in der Regel kürzer.

Sprint Retrospektive

Ziel der Sprint Retrospektive ist es, Wege zur Steigerung von Qualität und Effektivität zu planen.

Das Scrum-Team untersucht, wie der letzte Sprint in Bezug auf Einzelpersonen, Interaktionen, Prozesse, Tools und deren Definition vondone verlief. Diese Elemente variieren oft mit dem Arbeitsbereich. Annahmen, die sie in die Irre führten, werden identifiziert und ihre Ursprünge erforscht. Das Scrum-Team bespricht, was während des Sprints gut gelaufen ist, auf welche Probleme es gestoßen ist und wie diese Probleme gelöst wurden (oder nicht).

Das Scrum-Team identifiziert die hilfreichsten Änderungen, um seine Effektivität zu verbessern. Die wirkungsvollsten Verbesserungen werden so schnell wie möglich angegangen. Sie können sogar zum Sprint Backlog für den nextSprint hinzugefügt werden.

Die Sprint Retrospektive schließt den Sprint ab. Es ist timeboxed zu amaximum von drei Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event in der Regel kürzer.

Scrum-Artefakte

Die Artefakte von Scrum repräsentieren Arbeit oder Wert. Sie sollen Maximierentransparenz von Schlüsselinformationen. So hat jeder, der sie inspiziert, die gleiche Grundlage für die Anpassung.

Jedes Artefakt enthält eine Verpflichtung, sicherzustellen, dass es Informationen bereitstellt, die die Transparenz und den Fokus erhöhen, anhand derer der Fortschritt gemessen werden kann:

• Für das Product Backlog ist es das Produktziel.

• Für das Sprint Backlog ist es das Sprintziel.

• Für das Inkrement ist es die Definition von Done .

Diese Verpflichtungen dienen dazu, den Empirismus und die Scrum-Werte für das Scrum-Team und seine Stakeholder zu stärken.

Product Backlog

Das Product Backlog ist eine aufkommende, geordnete Liste dessen, was zur Verbesserung des Produkts benötigt wird. Es ist die einzige Quelle der Arbeit von theScrum Team durchgeführt.

Product Backlog-Elemente, die vom Scrum-Team innerhalb von oneSprint ausgeführt werden können, werden in einem Sprint-Planungsereignis als zur Auswahl bereit erachtet. Sie erwerben normalerweise diesen Grad an Transparenz nach Raffinationsaktivitäten.Product Backlog Refinement ist der Akt der Aufschlüsselung und weiteren Definition von Product Backlog-Elementen in kleinere, präzisere Elemente. Hierbei handelt es sich um eine fortlaufende Aktivität zum Hinzufügen von Details, z. B. einer Beschreibung, einer Bestellung und einer Größe. Attribute variieren oft mit dem Arbeitsbereich.

Die Entwickler, die die Arbeit machen werden, sind für die Dimensionierung verantwortlich. Der Product Owner kann die Entwickler beeinflussen, indem er ihnen helftverstehen und wählen Sie Kompromisse.

Commitment: Produktziel

Das Produktziel beschreibt einen zukünftigen Zustand des Produkts, der als Ziel für das Scrum-Team dienen kann. Das Produktziel liegt im Product Backlog. Der Rest des Product Backlogs entsteht, um zu definieren,“was“ das Produktziel erfüllen wird.

Ein Produkt ist ein Vehikel, um Wert zu liefern. Es hat eine klare Grenze,bekannte Stakeholder, klar definierte Benutzer oder Kunden. Ein Produkt könnte eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein.

Das Produktziel ist das langfristige Ziel für das Scrum-Team. Sie müssen ein Ziel erfüllen (oder aufgeben), bevor sie das nächste annehmen.

Sprint Backlog

Das Sprint Backlog besteht aus dem Sprintziel (warum), den für den Sprint ausgewählten Product Backlog-Elementen (was) sowie einem umsetzbaren Plan für die Bereitstellung des Inkrements (wie).

Das Sprint Backlog ist ein Plan von und für die Entwickler. Es ist ein hochsichtbares Echtzeitbild der Arbeit, die die Entwickler während des Sprints planen, um das Sprintziel zu erreichen.Folglich wird das Sprint Backlog während des gesamten Sprints aktualisiert, sobald mehr gelernt wird. Es sollte so detailliert sein, dass sie ihren Fortschritt im Daily Scrum überprüfen können.

Commitment: Sprintziel

Das Sprintziel ist das einzige Ziel für den Sprint. Obwohl DIESEDRUCKZIEL ist eine Verpflichtung der Entwickler, es bietet Flexibilitätin Bezug auf die genaue Arbeit, die benötigt wird, um es zu erreichen. Das Sprint-Ziel schafft auch Kohärenz und Fokus und ermutigt das Scrum-Team, zusammenzuarbeiten, anstatt an separaten Initiativen zu arbeiten.

Das Sprint-Ziel wird während des Sprint-Planungsereignisses erstellt und dann dem Sprint-Backlog hinzugefügt. Da die Entwickler während des Sprints arbeiten, behalten sie das Sprintziel im Auge. Wenn sich herausstellt, dass die Arbeit anders ist als erwartet, arbeiten sie mit dem Product Owner zusammen, um den Umfang des Sprint-Backlogs innerhalb des Sprints auszuhandeln, ohne das Sprint-Ziel zu beeinträchtigen.

Inkrement

Ein Inkrement ist ein konkretes Sprungbrett zum Produktziel. Jedes Inkrement ist additiv zu allen vorherigen Inkrementen und wird gründlich überprüft, um sicherzustellen, dass alle Inkremente zusammenarbeiten. Um einen Wert bereitzustellen, muss das Inkrement verwendbar sein.

Innerhalb eines Sprints können mehrere Inkremente erstellt werden. Die Summe der Zuwächse wird im Sprint Review vorgestellt und unterstützt damit die Empirismus.Ein Inkrement kann jedoch vor dem Ende des Sprints an die Stakeholder geliefert werden. Der Sprint Review sollte niemals als Tor zum Erfolgswert betrachtet werden.

Arbeit kann nicht als Teil eines Inkrements betrachtet werden, es sei denn, sie erfüllt die Definition von Erledigt.

Verpflichtung: Definition von Done

Die Definition von Done ist eine formale Beschreibung des Zustands des Produkts, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.

In dem Moment, in dem ein Product Backlog-Element die Definition von Done erfüllt, ist anIncrement geboren.

Die Definition von Done schafft Transparenz, indem sie jedem ein gemeinsames Verständnis darüber vermittelt, welche Arbeit im Rahmen der Steigerung abgeschlossen wurde. Wenn ein Product Backlog Item nicht der Definition vondone entspricht, kann es nicht freigegeben oder gar beim Sprint Review präsentiert werden.Stattdessen kehrt es zur zukünftigen Betrachtung zum Product Backlog zurück.

Wenn die Definition von Done für ein Inkrement Teil der Standards der Organisation ist, müssen alle Scrum-Teams sie mindestens befolgen. Wenn es sich nicht um einen Organisationsstandard handelt, muss das Scrum-Team eine für das Produkt geeignete Definition von Done erstellen.

Die Entwickler müssen sich an die Definition von Done halten. Wenn mehrere Scrum-Teams gemeinsam an einem Produkt arbeiten, müssen sie die gleiche Definition von Done definieren und einhalten.

Endnote

Scrum ist kostenlos und wird in diesem Handbuch angeboten. Das Scrum Framework, wie hierin beschrieben, ist unveränderlich. Während es möglich ist, nur Teile von Scrum zu implementieren, ist das Ergebnis nicht Scrum. Scrum existiert nur in seiner Gesamtheit und funktioniert gut als Container für andere Techniken, Methoden und Praktiken.

Danksagung

Menschen

Von den Tausenden von Menschen, die zu Scrum beigetragen haben, sollten wir diejenigen herausgreifen, die am Anfang maßgeblich waren: Jeff Sutherlandarbeitete mit Jeff McKenna und John Scumniotales, und Ken Schwaber arbeitete mit Mike Smith und Chris Martin zusammen, und alle arbeiteten zusammen. Viele andere trugen in den folgenden Jahren dazu bei, und ohne ihre Hilfe würde Scrum nicht so verfeinert werden, wie es heute ist.

Geschichte des Scrum Guides

Ken Schwaber und Jeff Sutherland stellten Scrum erstmals 1995 auf der OOPSLAConference vor. Es dokumentierte im Wesentlichen das Lernen, das Ken andJeff in den letzten Jahren gewonnen hat, und veröffentlichte die erste formelle Definition von Scrum.Der Scrum Guide dokumentiert Scrum, wie es seit über 30 Jahren von Jeff Sutherland und Ken Schwaber entwickelt, weiterentwickelt und aufrechterhalten wird. Andere Quellen liefern Muster, Prozesse und Erkenntnisse, die das Scrum-Framework ergänzen.Diese können die Produktivität, den Wert, die Kreativität und die Zufriedenheit mit den Ergebnissen steigern.

Die komplette Geschichte von Scrum wird an anderer Stelle beschrieben. Um die ersten Orte zu ehren, an denen es sich bewährt hat, erkennen wir Individual Inc. an.,Newspage, Fidelity Investments und IDX (jetzt GE Medical).

© 2020 Ken Schwaber und Jeff Sutherland Diese Publikation wird unter der AttributionShare-Alike-Lizenz von Creative Commons zur Lizenz angeboten, zugänglich unterhttps://creativecommons.org/licenses/by-sa/4.0/legalcode und auch in zusammengefasster Form unterhttps://creativecommons.org/licenses/by-sa/4.0/. Durch die Nutzung dieses ScrumGuide, Sie bestätigen und stimmen zu, dass Sie die Bedingungen der Attribution Share-Alike-Lizenz von CreativeCommons gelesen haben und damit einverstanden sind.