Scrum

Vergleich Scrum Guide 2017 & Scrum Guide 2020

Der Scrum Guide wurde im November 2020 aktualisiert. Mit unserem Vergleich des Scrum Guides 2017 und Scrum Guides 2020 erfahren Sie, wie sich Scrum verändert hat.

Mit dem Scrum Guide Update im November 2020 haben Ken Schwaber und Jeff Sutherland das Ziel verfolgt, „Scrum wieder zu einem minimal ausreichenden Rahmenwerk zu machen“1. Um diese Änderungen besser zu verstehen, haben wir diese Zusammenfassung und einen direkten Vergleich zwischen dem Scrum Guide 2020 und dem Scrum Guide 2017 erstellt.
  

Zusammenfassung der Änderungen im Scrum Guide


  1. Weniger vorschreibende Sprache: Präskriptive Sprache wurde entfernt oder gemildert, sodass der Scrum Guide noch mehr das „Warum?“ und „Was?“ beschreibt und weniger das „Wie?“.

  2. Ein Scrum Team: Das Konzept des Development Teams innerhalb des Scrum Teams wurde aufgelöst, da es potenziell zu einer Dysfunktion zwischen dem:der Product Owner:in und dem Development Team geführt hat. Es gibt jetzt nur noch das Scrum Team, das sich gemeinsam auf dasselbe Ziel fokussiert. Der:die Scrum Master:in ist als Teil des Teams jetzt genauso ergebnisverantwortlich dafür, ein wertvolles, nutzbares Increment zu erschaffen.

  3. Es gibt ein Produkt-Ziel: Es gibt jetzt ein Produkt-Ziel, um dem Scrum Team Fokus auf ein mittelfristiges Ziel zu ermöglichen. Mit jedem Sprint sollte das Produkt dem Produkt-Ziel einen Schritt näher kommen.

  4. Ein Commitment für jedes Artefakt: Jedem Scrum-Artefakt ist ein Commitment zugeordnet, das die Transparenz erhöht und damit Fortschritt leichter beurteilbar macht: Für das Product Backlog ist es das Product Goal, für das Sprint Backlog das Sprint Goal, und für das Increment die Definition of Done.

  5. Selbstmanagement über Selbstorganisation: Der Scrum Guide verwendet jetzt den Begriff Selbstmanagement, um zu betonen, dass Scrum Teams darüber entscheiden, woran sie arbeiten und wer diese Arbeit wie ausführt. Der vorherige Scrum Guide hat das Development Team als selbstorganisierend beschrieben, das wählen konnten, wer die Arbeit erledigt und wie.

  6. Eine dritte Frage für das Sprint Planning: Der neue Scrum Guide bringt mit der Frage „Wofür?“ (neben „Was?“ und „Wie?“) eine dritte Frage beim Sprint Planning ins Spiel. Diese bezieht sich auf das Sprint Ziel und beantwortet die Frage: „Wofür steckt das Team Arbeit in den nächsten Sprint?“.

  7. Sprachliche Vereinfachung: Redundante, sehr komplexe oder IT-spezifische Begriffe (z.B. Design, Test, Requirements) wurden aus dem Scrum Guide entfernt um ihn für Teams außerhalb der IT zugänglich zu machen.

Scrum Poster 2020

Laden Sie hier unser kostenloses Scrum Framework 2020 Poster herunter. Sie können es als visuelle Unterstützung für Ihr Scrum-Team und Ihre Organisation nutzen.

download!

Vergleich Scrum Guide 2017 & Scrum Guide 2020

Sie finden nachfolgend Inhalte in [eckigen Klammern]. Diese enthalten Querverweise zur besseren Vergleichbarkeit. Verwenden Sie STRG-F oder CMD-F und geben Sie die gesuchten Wörter ein. Die Treffer sind in beiden Versionen des Scrum-Handbuchs hervorgehoben.

Dieser Vergleich wurde von Johannes Geske, Professional Scrum Trainer™ (PST) bei Scrum.org und Agile Coach bei Amazing Outcomes in Düsseldorf, Deutschland, erstellt. Der Vergleich wird unter der gleichen Lizenz wie der Scrum Guide angeboten, der Attribution Share-Alike license von Creative Commons, die hier und in zusammengefasster Form hier zugänglich ist. Indem Sie diesen Vergleich nutzen, bestätigen Sie, dass Sie die Bedingungen der Attribution Share-Alike license von Creative Commons gelesen haben und damit einverstanden sind.

 
Scrum Guide 2017 Scrum Guide 2020
[Titelseite]

 

Der Scrum Guide™

Der gültige Leitfaden für Scrum: Die Spielregeln

November 2017

Entwickelt und kontinuierlich verbessert von den Scrum-Erfindern: Ken Schwaber and Jeff Sutherland

[Titelseite]

 

Ken Schwaber & Jeff Sutherland

Der Scrum Guide

Der gültige Leitfaden für Scrum: Die Spielregeln

November 2020

[Seite 2]

Inhaltsverzeichnis

Zweck des Scrum Guides, 3
Definition von Scrum, 3
Anwendung Scrum, 4
Scrum: Theorie, 4
Scrum: Werte, 5
Das Scrum Team, 6
Der Product Owner, 6
Das Development Team, 7
Der Scrum Master, 8
Scrum Events, 9
Der Sprint, 9
Sprint Planning, 10
Daily Scrum, 12
Sprint Review, 13
Sprint Retrospective, 14
Scrum‐Artefakte, 14
Product Backlog, 15
Sprint Backlog, 16
Increment, 17
Transparenz der Artefakte, 17
Definition of "Done", 17
Schlussbemerkung, 19
Danksagungen, 20
Menschen, 20
Historie, 20
Übersetzung, 20

[Seite 2]

 

Der Sinn des Scrum Guides, 1
Scrum-Definition, 3
Scrum-Theorie, 3
Transparenz, 4
Überprüfung, 4
Anpassung, 4
Scrum-Werte, 4
Scrum Team, 5
Developer:innen, 6
Product Owner:in, 6
Scrum Master:in, 7
Scrum Events, 8
Der Sprint, 8
Sprint Planning, 9
Daily Scrum, 10
Sprint Review, 10
Sprint Retrospective, 10
Scrum-Artefakte, 11
Product Backlog, 11
Commitment: Produkt-Ziel, 12
Sprint Backlog, 12
Commitment: Sprint-Ziel, 12
Increment, 13
Commitment: Definition of Done, 13
Schlussbemerkung, 14
Danksagungen, 14
Personen, 14
Scrum-Guide-Historie, 14
Übersetzung, 16

[^]

[Seite 3]

Zweck des Scrum Guides

Scrum ist ein Rahmenwerk zur Entwicklung, Auslieferung 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. Gemeinsam stehen sie hinter dem Scrum Guide.

[^]

[Seite 1]

Der Sinn 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 auf der ganzen Welt dabei zu helfen, Scrum zu verstehen. Wir haben den Guide seitdem durch kleine, funktionale Aktualisierungen weiterentwickelt. Wir stehen gemeinsam dahinter.

Der Scrum Guide enthält die Definition von Scrum. Jedes Element von Scrum dient einem bestimmten Zweck, der für den Gesamtwert und die mit Scrum erzielten Ergebnisse wesentlich ist. Den Kern oder die Grundideen von Scrum zu verändern, Elemente wegzulassen oder den Regeln von Scrum nicht zu folgen, verdeckt Probleme, begrenzt den Nutzen und macht Scrum im Zweifel sogar nutzlos.

Wir verfolgen den zunehmenden Einsatz von Scrum in einer stetig komplexer werdenden Welt. Wir sehen demütig, wie Scrum in zahlreichen Bereichen komplexer Arbeit über die Softwareentwicklung hinaus ‐ wo Scrum seine Wurzeln hat ‐ eingesetzt wird. Während sich die Verwendung von Scrum weiter verbreitet, wird diese Arbeit von Entwickler:innen, Forscher:innen, Analyst:innen, Wissenschaftler:innen und anderen Spezialist:innen getan. Wir verwenden das Wort „Developer:innen” in Scrum nicht, um jemanden auszuschließen, sondern um zu vereinfachen. Wer auch immer vom Einsatz von Scrum profitiert, soll sich angesprochen fühlen.

Beim Einsatz von Scrum können Muster, Prozesse und Erkenntnisse angewendet und entwickelt werden, die zum Scrum‐Rahmenwerk passen, wie es in diesem Dokument beschrieben ist. Ihre Beschreibung geht über den Zweck des Scrum Guides hinaus, da sie kontextabhängig sind und sich, je nachdem wie Scrum eingesetzt wird, stark unterscheiden. Solche Taktiken für die Anwendung innerhalb des Scrum‐ Rahmenwerks variieren stark und werden an anderer Stelle beschrieben.

Ken Schwaber & Jeff Sutherland, November 2020

[^]

[Seite 3]

Definition von Scrum

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:

  • Leichtgewichtig
  • Einfach zu verstehen
  • Schwierig zu meistern

Scrum wird seit den frühen 1990er Jahren als Prozessrahmenwerk zum Management der Arbeit an komplexen Produkten verwendet. Scrum ist weder ein Prozess, noch eine Technik oder vollständige Methode. Vielmehr ist es ein Rahmenwerk, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können. Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Ihrer Arbeitstechniken sichtbar, damit Sie fortlaufend das Produkt, das Team und die Arbeitsumgebung verbessern können.

Das Scrum-Rahmenwerk besteht aus Scrum Teams und den zu ihnen gehörenden Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente innerhalb des Rahmenwerks dient einem bestimmten 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 Rollen, Ereignissen und Artefakten bestimmt. Die Regeln von Scrum sind im Hauptteil dieses Dokumentes dargestellt.

Bestimmte Taktiken zur Nutzung von Scrum variieren und sind an anderer Stelle beschrieben.

[^]

[Seite 3]

Scrum‐Definition

Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.

Kurz gesagt fordert Scrum, dass ein:e Scrum Master:in ein Umfeld fördert, in dem

  1. ein:e Product Owner:in die Arbeit für ein komplexes Problem in ein Product Backlog einsortiert;
  2. das Scrum Team aus einer Auswahl dieser Arbeit innerhalb eines Sprints ein wertvolles Increment erzeugt;
  3. das Scrum Team und dessen Stakeholder:innen die Ergebnisse überprüfen und für den nächsten Sprint anpassen;
  4. diese Schritte wiederholt werden.

Scrum ist einfach. Probiere es so aus, wie es ist, und finde heraus, ob seine Philosophie, Theorie und Struktur dabei helfen, Ziele zu erreichen und Wert zu schaffen. Das Scrum‐Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum‐Theorie erforderlich sind. Scrum baut auf der kollektiven Intelligenz der Personen auf, die es anwenden. Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen.

Innerhalb des Rahmenwerks können verschiedene Prozesse, Techniken und Methoden eingesetzt werden. Scrum umhüllt bestehende Praktiken oder macht sie überflüssig. Scrum macht die relative Wirksamkeit des aktuellen Managements, der Umgebung und der Arbeitstechniken sichtbar, so dass Verbesserungen vorgenommen werden können.

[^]

[Seite 4]

Anwendungen von Scrum

Scrum wurde ursprünglich dazu entwickelt, um Produkte zu managen und zu entwickeln. Seit den frühen 1990er Jahren wird Scrum weltweit ausgiebig genutzt zur:

  1. Erforschung und Identifizierung rentabler Märkte, Technologien und Produktfähigkeiten;
  2. Entwicklung von Produkten und Erweiterungen;
  3. Release von Produkten und Erweiterungen, regelmäßig und mehrmals täglich;
  4. Entwicklung und Aufrechterhaltung von Cloud-Umgebungen (online, sicher, on-demand) und anderer Produktivumgebungen; sowie
  5. Erhaltung und Erneuerung von Produkten.

Scrum wird verwendet, um Software, Hardware, Embedded Software, Netzwerke von interagierenden Funktionen und autonome Fahrzeuge zu entwickeln. Scrum wird aber auch in Schulen, Regierungs- und Marketingprojekten genutzt, zur Verwaltung von Organisationen und der Entwicklung von fast allem, was wir in unserem täglichen Leben als Einzelpersonen und als Gesellschaften verwenden.

Scrum bewährt sich täglich im Umgang mit Komplexität, da Technologie-, Markt- und Umweltkomplexitäten und deren Interaktionen rapide zugenommen haben.

Scrum hat sich bei iterativem und inkrementellem Wissenstransfer als besonders effektiv erwiesen. Scrum wird heute häufig für Produkte, Dienstleistungen und das Management der übergeordneten Organisation verwendet.

Der Kern von Scrum ist ein kleines Team von Menschen. Dieses Team ist sehr flexibel und anpassungsfähig. Diese Stärken wirken weiter zwischen mehreren und vielen Teams und sogar Netzwerken von Teams, die die Arbeit und Ergebnisse von Tausenden von Menschen entwickeln, ausliefern, betreiben und erhalten. Sie arbeiten über durchdachte Entwicklungsarchitekturen und Zielumgebungen für Releases zusammen.

Wenn die Wörter "entwickeln" und "Entwicklung" im Scrum Guide verwendet werden, beziehen sie sich auf komplexe Arbeit, wie z.B. die oben beschriebenen Typen.

 

[^]

[Seite 4]

Scrum: Theorie

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 verfolgt 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].

[^]

[Seite 3]

Scrum‐Theorie

Scrum basiert auf Empirie und Lean Thinking. Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden. Lean Thinking reduziert Verschwendung und fokussiert auf das Wesentliche.

Scrum verwendet einen iterativen, inkrementellen Ansatz zur Optimierung der Vorhersagbarkeit und zur Risikokontrolle. Scrum setzt auf Personengruppen, die gemeinsam über alle Fähigkeiten und Fachkenntnisse verfügen, um die Arbeit zu erledigen und solche Fähigkeiten im Bedarfsfall zu teilen oder zu erwerben.

Scrum kombiniert vier formale Events zur Überprüfung und Anpassung innerhalb eines umspannenden Events, des Sprints. Diese Events funktionieren, weil sie die empirischen Scrum‐Säulen Transparenz, Überprüfung und Anpassung implementieren.

[^]

[Seite 5]

Transparenz

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:

  • Eine gemeinsame Prozesssprache, die von allen Teilnehmern geteilt wird.
  • Die Personen, die das Product Increment produzieren und inspizieren, müssen alle ein gemeinsames Verständnis von „Done“ teilen.

[^]

[Seite 4]

Transparenz

Der sich entwickelnde Prozess und die entstehende Arbeit müssen sowohl für diejenigen sichtbar sein, die die Arbeit ausführen, als auch für diejenigen, die die Arbeit empfangen. Bei Scrum basieren wichtige Entscheidungen auf dem wahrgenommenen Zustand seiner drei formalen Artefakte. Artefakte, die wenig transparent sind, können zu Entscheidungen führen, die den Wert mindern und das Risiko erhöhen.

Transparenz ermöglicht Überprüfung. Eine Überprüfung ohne Transparenz ist irreführend und verschwenderisch.

[^]

[Seite 5]

Überprüfung

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.

[^]

[Seite 4]

Überprüfung

Die Scrum‐Artefakte und der Fortschritt in Richtung der vereinbarten Ziele müssen häufig und sorgfältig überprüft werden, um potenziell unerwünschte Abweichungen oder Probleme aufzudecken. Um bei der Überprüfung zu helfen, bietet Scrum eine Kadenz in Form seiner fünf Events.

Überprüfung ermöglicht Anpassung. Überprüfung ohne Anpassung wird als unsinnig betrachtet. Scrum Events sind darauf ausgerichtet, Veränderungen zu bewirken.

[^]

[Seite 5]

Anpassung

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 [dann] so schnell wie möglich vorgenommen werden, um weitere Abweichungen zu minimieren.

[^]

[Seite 4]

Anpassung

Wenn einzelne Aspekte eines Prozesses von akzeptablen Grenzen abweichen oder wenn das resultierende Produkt nicht akzeptabel ist, müssen der angewandte Prozess oder die produzierten Ergebnisse angepasst werden. Die Anpassung muss so schnell wie möglich erfolgen, um weitere Abweichungen zu minimieren.

Die Anpassung wird schwieriger, wenn die beteiligten Personen nicht bevollmächtigt (empowered) sind oder sich nicht selbst managen können. Von einem Scrum Team wird erwartet, dass es sich in dem Moment anpasst, in dem es durch Überprüfung etwas Neues lernt.

[^]

[Seite 5]

Scrum schreibt vier formale Ereignisse für Überprüfung und Anpassung vor. Diese werden im Abschnitt Scrum Events beschrieben:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

[^]

[siehe Seite 3, „Scrum-Theorie“, Absatz 3: „Scrum kombiniert vier formale Events zur Überprüfung und Anpassung innerhalb eines umspannenden Events, des Sprints...“]

[^]

[Seiten 5-6]

Scrum: Werte

Wenn die Werte Commitment, 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-Events, -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.

[^]

[Seiten 4-5]

Scrum‐Werte

Die erfolgreiche Anwendung von Scrum hängt davon ab, dass die Menschen immer besser in der Lage sind, fünf Werte zu leben:

Commitment, Fokus, Offenheit, Respekt, und Mut

Das Scrum Team committet sich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen. Sein primärer Fokus liegt auf der Arbeit des Sprints, um den bestmöglichen Fortschritt in Richtung dieser Ziele zu bewirken. Das Scrum Team und dessen Stakeholder:innen sind offen in Bezug auf die Arbeit und die Herausforderungen. Die Mitglieder des Scrum Teams respektieren sich gegenseitig als fähige, unabhängige Personen und werden als solche auch von den Menschen, mit denen sie zusammenarbeiten, respektiert. Die Mitglieder des Scrum Teams haben den Mut, das Richtige zu tun: an schwierigen Problemen zu arbeiten.

Diese Werte geben dem Scrum Team die Richtung vor, was seine Arbeit, seine Handlungen und sein Verhalten betrifft. Die Entscheidungen, die getroffen werden, die Schritte, die unternommen werden, und die Art und Weise, wie Scrum angewendet wird, sollten diese Werte stärken und nicht schmälern oder untergraben. Die Mitglieder des Scrum Teams lernen und erforschen die Werte, während sie in den Events und mit den Artefakten von Scrum arbeiten. Wenn diese Werte durch das Scrum Team und die Menschen, mit denen es arbeitet, verkörpert werden, werden die empirischen Scrum‐Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen Vertrauen auf.

Scrum Poster 2020

Laden Sie hier unser kostenloses Scrum Framework 2020 Poster herunter. Sie können es als visuelle Unterstützung für Ihr Scrum-Team und Ihre Organisation nutzen.

download!
 
Scrum Guide 2017 Scrum Guide 2020

[^]

[Seite 6]

Das Scrum Team

Ein Scrum Team besteht aus dem Product Owner, dem Development Team, sowie dem Scrum Master. Scrum Teams sind selbstorganisierend und interdisziplinär. Selbstorganisierende Teams entscheiden selbst, wie sie ihre Arbeit am besten erledigen, anstatt dieses durch andere Personen außerhalb des Teams vorgegeben zu bekommen. Interdisziplinäre Teams verfügen über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne dabei von Personen außerhalb des Teams abhängig zu sein. Das Team-Modell in Scrum wurde konzipiert, um Flexibilität, Kreativität und Produktivität zu optimieren. Es hat sich herausgestellt, dass ein Scrum Team für alle eingangs aufgeführten Anwendungsfälle und jegliche komplexe Arbeit in zunehmendem Maße effektiv ist.

Scrum Teams liefern Produkte iterativ und inkrementell und maximieren somit die Gelegenheiten für Feedback. Die inkrementelle Auslieferung eines „Done“ [„fertigen“] Produkts sorgt dafür, dass stets eine potentiell nützliche Version des Produkts zur Verfügung steht.

[^]

[Seite 5]

Scrum Team

Der zentrale Bestandteil von Scrum ist ein kleines Team von Menschen, ein Scrum Team. Das Scrum Team besteht aus einem:einer Scrum Master:in, einem:einer Product Owner:in und Developer:innen. Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien. Es handelt sich um eine geschlossene Einheit von Fachleuten, die sich auf ein Ziel konzentrieren, das Produkt‐Ziel.

Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen. Sie managen sich außerdem selbst, d.h. sie entscheiden intern, wer was wann und wie macht.

Das Scrum Team ist klein genug, um flink zu bleiben und groß genug, um innerhalb eines Sprints bedeutsame Arbeit fertigzustellen, üblicherweise 10 oder weniger Personen. Im Allgemeinen haben wir festgestellt, dass kleinere Teams besser kommunizieren und produktiver sind. Wenn Scrum Teams zu groß werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie sich Produkt‐Ziel, Product Backlog und Product Owner:in teilen.

Das Scrum Team ist umsetzungsverantwortlich (responsible) für alle produktbezogenen Aktivitäten: Zusammenarbeit mit den Stakeholder:innen, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte. Es ist von der Organisation so aufgebaut und befähigt, dass es seine Arbeit selbst steuert. Das Arbeiten in Sprints mit einer nachhaltigen Geschwindigkeit verbessert den Fokus und die Kontinuität des Scrum Teams.

Das gesamte Scrum Team ist ergebnisverantwortlich (accountable), in jedem Sprint ein wertvolles, nützliches Increment zu schaffen. Scrum definiert drei spezifische Ergebnisverantwortlichkeiten innerhalb des Scrum Teams: Developer:innen, Product Owner:in und Scrum Master:in.

[^]

[Seiten 6-7]

Der Product Owner

Der Product Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Development Teams entsteht. Wie dies geschieht, kann je nach Organisation, Scrum Team und Einzelpersonen stark variieren.

Der Product Owner ist die einzige Person, die für das Management des Product Backlogs verantwortlich ist. Das Product-Backlog-Management umfasst:

  • Die Product-Backlog-Einträge klar zu formulieren;
  • Die Einträge im Product Backlog so zu sortieren, dass Ziele und Missionen optimal erreicht werden können;
  • Den Wert der Arbeit zu optimieren, die das Development Team erledigt;
  • Sicherzustellen, dass das Product Backlog sichtbar, transparent und für alle klar ist sowie zeigt, woran das Scrum Team als nächstes arbeiten wird; und
  • Sicherzustellen, dass das Development Team die Product-Backlog-Einträge im erforderlichen Maße versteht.

Der Product Owner kann die oben genannten Arbeiten selbst durchführen oder sie durch das Development Team erledigen lassen. Der Product Owner bleibt jedoch immer rechenschaftspflichtig.

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 das Development Team zwingen, andere Anforderungen zu bearbeiten.

[^]

[Seite 6]

Product Owner:in

Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt. Wie dies geschieht, kann je nach Organisation, Scrum Team und Individuum sehr unterschiedlich sein.

Der:die Product Owner:in ist auch für ein effektives Product‐Backlog‐Management ergebnisverantwortlich, das Folgendes umfasst:

  • das Produkt‐Ziel zu entwickeln und explizit zu kommunizieren;
  • die Product‐Backlog‐Einträge zu erstellen und klar zu kommunizieren;
  • die Reihenfolge der Product‐Backlog‐Einträge festzulegen; und
  • sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist.

Der:die Product Owner:in kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der:die Product Owner:in ergebnisverantwortlich.

Damit der:die Product Owner:in Erfolg haben kann, muss die gesamte Organisation seine:ihre Entscheidungen respektieren. Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs sowie durch das überprüfbare Increment beim Sprint Review, sichtbar.

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

[^]

[Seite 7]

Das Development Team

Das Development Team besteht aus Profis, die am Ende eines jeden Sprints ein „Done“ Increment übergeben, welches potentiell auslieferbar ist. Im Sprint Review muss ein „Done“ Increment vorhanden sein. Nur Mitglieder der Development Teams erstellen das Product Increment.

Development Teams 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 Development Teams.

Development Teams weisen die folgenden Eigenschaften auf:

  • Sie sind selbstorganisierend. Niemand (nicht einmal der Scrum Master) sagt dem Development Team, wie es aus dem Product Backlog potentiell auslieferbare Funktionalität erzeugen soll.
  • Development Teams sind interdisziplinär. Sie haben als Team alle Fähigkeiten, die notwendig sind, um ein Product Increment zu erstellen.
  • Scrum kennt für Mitglieder des Development Teams keine Titel. Dies ist unabhängig von der Arbeit, die diese Personen erledigen.
  • Scrum kennt keine weiteren Unterteilungen innerhalb des Development Teams, ungeachtet der verschiedenen Themenfelder, mit denen das Team sich befasst, also z.B. "Test", "Architektur", "Betrieb" oder "Analyse".
  • Einzelne Mitglieder des Development Teams können zwar spezialisierte Fähigkeiten oder Spezialgebiete haben, aber die Rechenschaftspflicht obliegt dem Team als Ganzem.

[^]

[Seite 6]

Developer:innen

Developer:innen sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Increments zu schaffen.

Die spezifischen Fähigkeiten, die von den Developer:innen benötigt werden, sind oft breit gefächert und variieren je nach Arbeitskontext. Die Developer:innen sind jedoch immer ergebnisverantwortlich dafür,

  • einen Plan für den Sprint zu erstellen, das Sprint Backlog;
  • Qualität durch die Einhaltung einer Definition of Done einzubringen;
  • täglich ihren Plan zur Erreichung des Sprint‐Ziels anzupassen; und
  • sich wechselseitig als Expert:innen zur Verantwortung zu ziehen.

[^]

[Seite 7]

Größe des Development Teams

Die optimale Größe des Development Teams 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 Development Teams reduzieren die Interaktion und führen zu geringeren Produktivitätssteigerungen [als bei größeren Teams]. Kleinere Development Teams können eventuell kein potentiell releasebares Product Increment liefern, da sie möglicherweise nicht über alle benötigten Fähigkeiten verfügen. Mehr als neun Mitglieder erfordern zu viel Koordination. Große Development Teams erzeugen eine zu hohe Komplexität, als dass ein empirischer Prozess nützlich wäre. Product Owner und Scrum Master zählen nicht zu dieser Zahl dazu, sofern sie nicht ebenso die Arbeit aus dem Sprint Backlog erledigen.

[^]

[siehe Seite 5, „Scrum Team“, Absatz 3: „Das Scrum Team ist klein genug, um flink zu bleiben und groß genug, um innerhalb eines Sprints bedeutsame Arbeit fertigzustellen, üblicherweise 10 oder weniger Personen. Im Allgemeinen haben wir festgestellt, dass kleinere Teams besser kommunizieren und produktiver sind. Wenn Scrum Teams zu groß werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie sich Produkt‐Ziel, Product Backlog und Product Owner:in teilen.“]

[^]

[Seite 8]

Der Scrum Master

Der Scrum Master ist dafür verantwortlich, Scrum entsprechend des Scrum Guides zu fördern und zu unterstützen. Scrum Master tun dies, indem sie allen Beteiligten helfen, die Scrum-Theorie, -Praktiken, -Regeln und -Werte zu verstehen.

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.

[^]

[Seite 7]

Scrum Master:in

Der:die Scrum Master:in ist ergebnisverantwortlich für die Einführung von Scrum, wie es im Scrum Guide definiert ist. Er:sie tut dies, indem er:sie allen dabei hilft, die Scrum‐Theorie und ‐Praxis zu verstehen, sowohl innerhalb des Scrum Teams als auch in der Organisation.

Der:die Scrum Master:in ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Er:sie tut dies, indem er:sie das Scrum Team in die Lage versetzt, seine Praktiken innerhalb des Scrum‐Rahmenwerks zu verbessern.

Scrum Master:innen sind echte Führungskräfte, die dem Scrum Team und der Gesamtorganisation dienen.

[^]

[siehe Seite 8, „Der Scrum Master dient dem Development Team auf verschiedene Arten, unter anderem durch das:

  • Coachen des Development Teams hin zu Selbstorganisation und funktionsübergreifender Teamarbeit;
  • Unterstützen des Development Teams bei der Schaffung hochwertiger Produkte;
  • Beseitigen von Hindernissen, die das Development Team aufhalten;
  • Unterstützen bei der Durchführung von Scrum Events bei Bedarf oder auf Anfrage;
  • Coachen des Development Teams in Organisationen, in denen Scrum noch nicht vollständig angenommen und verstanden wird.
“]

[^]

[Seite 7]

Der:die Scrum Master:in dient dem Scrum Team auf unterschiedliche Weise, unter anderem dadurch,

  • die Teammitglieder in Selbstmanagement und interdisziplinärer Zusammenarbeit zu coachen;
  • das Scrum Team bei der Fokussierung auf die Schaffung von hochwertigen Increments zu unterstützen, die der Definition of Done entsprechen;
  • die Beseitigung von Hindernissen (impediments) für den Fortschritt des Scrum Teams zu bewirken; und
  • sicherzustellen, dass alle Events von Scrum stattfinden, positiv und produktiv sind und innerhalb der Timebox bleiben.

[^]

[Seite 8]

Der Dienst des Scrum Masters für den Product Owner

Der Scrum Master dient dem Product Owner auf verschiedene Arten, unter anderem durch das:

  • Sicherstellen, dass Ziele, Umfang und Produktdomäne von allen im Scrum Team so gut wie möglich verstanden werden;
  • Vermitteln von Techniken für eine effektive Verwaltung des Product Backlogs;
  • Vermitteln eines Verständnisses für die Notwendigkeit klarer, prägnanter Product-BacklogEinträge im Scrum Team;
  • Schaffen eines Verständnisses für Produktplanung in einem empirischen Arbeitsumfeld;
  • Sicherstellen, dass der Product Owner weiß, wie er das Product Backlog so anordnet, dass es den größten Wert erzeugt;
  • Vermitteln des richtigen Verständnisses von Agilität und ihrer Anwendung;
  • Unterstützen bei der Durchführung von Scrum Events bei Bedarf oder auf Anfrage.

[^]

[Seite 7]

Der:die Scrum Master:in dient dem:der Product Owner:in auf unterschiedliche Weise, unter anderem dadurch,

  • bei der Suche nach Techniken zur effektiven Definition des Produkt‐Ziels und zum Product‐ Backlog‐Management zu helfen;
  • dem Scrum Team dabei zu helfen, die Notwendigkeit klarer und präziser Product‐Backlog‐ Einträge zu verstehen;
  • bei der Etablierung einer empirischen Produktplanung für ein komplexes Umfeld zu helfen; und
  • die Zusammenarbeit mit Stakeholder:innen nach Wunsch oder Bedarf zu fördern (facilitate).

[^]

[Seite 8]

Der Dienst des Scrum Masters für das Development Team

Der Scrum Master dient dem Development Team auf verschiedene Arten, unter anderem durch das:

  • Coachen des Development Teams hin zu Selbstorganisation und funktionsübergreifender Teamarbeit;
  • Unterstützen des Development Teams bei der Schaffung hochwertiger Produkte;
  • Beseitigen von Hindernissen, die das Development Team aufhalten;
  • Unterstützen bei der Durchführung von Scrum Events bei Bedarf oder auf Anfrage;
  • Coachen des Development Teams in Organisationen, in denen Scrum noch nicht vollständig angenommen und verstanden wird.

[^]

[siehe Seite 7, „Der:die Scrum Master:in dient dem Scrum Team auf unterschiedliche Weise, unter anderem dadurch,

  • die Teammitglieder in Selbstmanagement und interdisziplinärer Zusammenarbeit zu coachen;
  • das Scrum Team bei der Fokussierung auf die Schaffung von hochwertigen Increments zu unterstützen, die der Definition of Done entsprechen;
  • die Beseitigung von Hindernissen (impediments) für den Fortschritt des Scrum Teams zu bewirken; und
  • sicherzustellen, dass alle Events von Scrum stattfinden, positiv und produktiv sind und innerhalb der Timebox bleiben.
“]

[^]

[Seiten 8-9]

Der Dienst des Scrum Masters an der Organisation

Der Scrum Master dient der Organisation auf verschiedene Arten, unter anderem durch das:

  • Leiten und Coachen der Organisation bei der Einführung von Scrum;
  • Planen von Scrum-Implementierungen innerhalb der Organisation;
  • Unterstützen von Kollegen und Stakeholdern, Scrum und empirische Produktentwicklung zu verstehen und umzusetzen;
  • Auslösen von Veränderungen zur Produktivitätssteigerung des Teams;
  • Zusammenarbeiten mit anderen Scrum Mastern, um die Effektivität von ScrumImplementierungen innerhalb der Organisation zu verbessern.

[^]

[Seite 7]

Der:die Scrum Master:in dient der Organisation auf unterschiedliche Weise, unter anderem dadurch,

  • die Organisation bei der Einführung von Scrum zu führen, zu schulen und zu coachen;
  • Einführungen von Scrum in der Organisation zu planen und zu empfehlen;
  • Mitarbeitende und Stakeholder:innen beim Verständnis und bei der Umsetzung eines empirischen Ansatzes für komplexe Arbeit zu unterstützen; und
  • Barrieren zwischen Stakeholder:innen und Scrum Teams zu beseitigen.

Scrum Poster 2020

Laden Sie hier unser kostenloses Scrum Framework 2020 Poster herunter. Sie können es als visuelle Unterstützung für Ihr Scrum-Team und Ihre Organisation nutzen.

download!
 
Scrum Guide 2017 Scrum Guide 2020

[^]

[Seite 9]

Scrum Events

In Scrum werden vorgeschriebene Ereignisse verwendet, um eine Regelmäßigkeit herzustellen und die Notwendigkeit anderer, nicht in Scrum definierter, Besprechungen zu minimieren. Alle Ereignisse sind befristet [time boxed], 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 Event eine formale Gelegenheit zur Überprüfung und Anpassung. Diese Events 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 gegenwärtigen Stand zu erfassen [Inspect] und darauf zu reagieren [Adapt].

[^]

[Seite 8]

Scrum Events

Der Sprint ist ein Container für alle anderen Events. Jedes Event in Scrum ist eine formelle Gelegenheit, Scrum‐Artefakte zu überprüfen und anzupassen. Diese Events sind speziell darauf ausgelegt, die erforderliche Transparenz zu ermöglichen. Wenn ein Event nicht wie vorgeschrieben durchgeführt wird, verpasst man die Gelegenheit, zu überprüfen und anzupassen. Events werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings, die in Scrum nicht definiert sind, zu minimieren. Optimalerweise werden alle Events zur selben Zeit und am selben Ort abgehalten, um die Komplexität zu reduzieren.

[^]

[Seite 9]

Der Sprint

Das Herz von Scrum ist der Sprint, ein Zeitraum [Time Box] von maximal einem Monat, innerhalb dessen ein „Done", nutzbares und potentiell releasebares Product Increment hergestellt wird. Alle Sprints innerhalb eines Entwicklungsvorhabens sollten die gleiche Dauer haben. Der neue Sprint startet sofort nach Abschluss des vorherigen Sprints.

Ein Sprint beinhaltet und umfasst das Sprint Planning, die Daily Scrums, die Entwicklungsarbeit, das Sprint Review und die Sprint Retrospective.

Während des Sprints:

  • werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden,
  • wird der Qualitätsanspruch nicht geschmälert, und
  • kann der Anforderungsumfang zwischen Product Owner und Development Team geklärt und neu ausgehandelt werden, wenn sich neue Erkenntnisse ergeben haben.

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 ein Ziel, was gebaut werden soll, einen Entwurf und einen flexiblen Plan, der die Umsetzung, die Arbeit und das resultierende Product Increment in die richtige Richtung lenkt.

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 das Risiko erhöhen. Sprints ermöglichen Vorhersagbarkeit, indem sie mindestens einmal im Monat Überprüfung und Anpassungen des Fortschritts zu einem bestimmten Sprint-Ziel sicherstellen. Sprints reduzieren dazu noch das Risiko auf die Kosten eines Monats.

[^]

[Seite 8]

Der Sprint

Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden.

Es sind Events mit fester Länge von einem Monat oder weniger, um Konsistenz zu schaffen. Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints.

Alle Arbeiten, die notwendig sind, um das Produkt‐Ziel zu erreichen, einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb der Sprints statt.

Während des Sprints

  • werden keine Änderungen vorgenommen, die das Sprint‐Ziel gefährden würden;
  • nimmt die Qualität nicht ab;
  • wird das Product Backlog nach Bedarf verfeinert; und
  • kann der Scope (Inhalt und Umfang) geklärt und mit dem:der Product Owner:in neu vereinbart werden, sobald mehr Erkenntnisse vorliegen.

Sprints ermöglichen Vorhersagbarkeit, indem sie mindestens jeden Kalendermonat eine Überprüfung und Anpassung der Fortschritte in Richtung eines Produkt‐Ziels gewährleisten. Wenn der Horizont eines Sprints zu lang ist, kann das Sprint‐Ziel hinfällig werden, die Komplexität kann steigen und das Risiko kann zunehmen. Kürzere Sprints können eingesetzt werden, um mehr Lernzyklen zu generieren und das Risiko von Kosten und Aufwand auf einen kleineren Zeitrahmen zu begrenzen. Jeder Sprint kann als ein kurzes Projekt betrachtet werden.

Es gibt verschiedene Vorgehensweisen, um den Fortschritt vorherzusagen, wie Burn‐Down‐Charts, Burn‐ Up‐Charts oder Cumulative‐Flow‐Diagramme. Diese haben sich zwar als nützlich erwiesen, ersetzen jedoch nicht die Bedeutung der Empirie. In komplexen Umgebungen ist unbekannt, was passieren wird. Nur was bereits geschehen ist, kann für eine vorausschauende Entscheidungsfindung genutzt werden.

Ein Sprint könnte abgebrochen werden, wenn das Sprint‐Ziel obsolet wird. Nur der:die Product Owner:in hat die Befugnis, den Sprint abzubrechen.

[^]

[Seite 10]

Einen Sprint abbrechen

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 Development Teams oder des 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 ist ein Abbruch bei der kurzen Dauer der Sprints selten sinnvoll.

Wenn ein Sprint abgebrochen wird, werden alle abgeschlossenen und „Done" Product-BacklogEinträ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 Starten eines neuen Sprints in einem Sprint Planning umorganisieren. Sprint-Abbrüche sind zudem oft schmerzhaft für das Scrum Team; sie sind eher unüblich.

[^]

[siehe Seite 8, „Der Sprint“, letzter Abschnitt:
„in Sprint könnte abgebrochen werden, wenn das Sprint‐Ziel obsolet wird. Nur der:die Product Owner:in hat die Befugnis, den Sprint abzubrechen.“]

[^]

[Seite 10]

Sprint Planning

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 für einen einmonatigen Sprint auf maximal 8 Stunden befristet [Time Box]. Bei kürzeren Sprints wendet man normalerweise weniger Zeit auf. Der Scrum Master sorgt dafür, dass das Ereignis stattfindet und die Teilnehmer dessen Zweck verstehen. Er bringt dem Scrum Team bei, das Ereignis innerhalb der Frist erfolgreich abzuschließen.

Das Sprint Planning beantwortet die folgenden Fragen:

  • Was ist in dem Product Increment des kommenden Sprints enthalten?
  • Wie wird die für die Lieferung des Product Increments erforderliche Arbeit erledigt?

[^]

[Seite 9]

Sprint Planning

Das Sprint Planning initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt. Dieser resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt.

Der:die Product Owner:in stellt sicher, dass die Teilnehmenden vorbereitet sind, die wichtigsten Product‐Backlog‐Einträge zu besprechen, und wie sie dem Produkt‐Ziel zuzuordnen sind. Das Scrum Team kann zu Beratungszwecken auch andere Personen zur Teilnahme am Sprint Planning einladen.

Das Sprint Planning behandelt die folgenden Themen:

 

[^]

[Seite 9]

Thema Eins: Warum ist dieser Sprint wertvoll?

Der:die Product Owner:in schlägt vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprint‐Ziel zu definieren, das verdeutlicht, warum der Sprint für die Stakeholder:innen wertvoll ist. Das Sprint‐Ziel muss vor dem Ende des Sprint Plannings finalisiert sein.

[^]

[Seiten 10-11]

Punkt 1: Was kann in diesem Sprint fertiggestellt werden?

Das Development Team 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 Product Increment, die veranschlagte Kapazität des Development Teams im Sprint sowie die bisherige Leistung desselben. Ausschließlich das Development Team bestimmt die Anzahl der ausgewählten Product-Backlog-Einträge für den kommenden Sprint. Nur es selbst kann beurteilen, was im kommenden Sprint machbar ist.

Während des Sprint Plannings erarbeitet das Scrum Team gemeinsam ein Sprint-Ziel. Das SprintZiel bildet die Messlatte, die durch die Implementierung der Product-Backlog-Einträge im Sprint erreicht wird; es leitet das Development Team in der Frage, warum es dieses Product Increment erstellt.

[^]

[Seite 9]

Thema Zwei: Was kann in diesem Sprint abgeschlossen (Done) werden?

Im Gespräch mit dem:der Product Owner:in wählen die Developer:innen Einträge aus dem Product Backlog aus, die in den aktuellen Sprint aufgenommen werden sollen. Das Scrum Team kann diese Einträge während dieses Prozesses verfeinern, was Verständnis und Vertrauen erhöht.

Die Auswahl, wie viel innerhalb eines Sprints abgeschlossen werden kann, kann eine Herausforderung darstellen. Je mehr die Developer:innen jedoch über ihre bisherige Leistung, ihre zukünftige Kapazität und ihre Definition of Done wissen, desto sicherer werden sie in ihren Sprint‐Vorhersagen sein.

[^]

[Seite 11]

Punkt 2: Wie wird die ausgewählte Arbeit erledigt?

Nach der Vereinbarung des Sprint-Ziels und der Auswahl der Product-Backlog-Einträge für den Sprint entscheidet das Development Team, wie es das Product Increment 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 Development Teams.

Das Development Team beginnt normalerweise mit dem Entwurf des Systems und den Tätigkeiten, die notwendig sind, um ein funktionsfähiges Product Increment zu erstellen. Die Arbeiten können sich in der Größe oder dem geschätzten Aufwand unterscheiden. Auf jeden Fall sollte das Development Team genug Arbeit planen, um zu prognostizieren, was es im kommenden Sprint schaffen zu können glaubt. 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 Development Team organisiert selbst, wie es die Arbeiten im Sprint Backlog angeht, sowohl im Sprint Planning als auch 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 Development Team 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 Development Team kann auch andere Teilnehmer zu dem Meeting einladen, um technische oder fachliche Unterstützung zu erhalten.

Am Ende des Sprint Plannings sollte das Development Team 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 Product Increments arbeiten möchte.

[^]

[Seite 9]

Thema Drei: Wie wird die ausgewählte Arbeit erledigt?

Für jeden ausgewählten Product‐Backlog‐Eintrag planen die Developer:innen die notwendige Arbeit, um ein Increment zu erstellen, das der Definition of Done entspricht. Dies geschieht oft durch Zerlegung von Product‐Backlog‐Einträgen in kleinere Arbeitseinheiten von einem Tag oder weniger. Wie dies geschieht, liegt im alleinigen Ermessen der Developer:innen. Niemand sonst sagt ihnen, wie sie Product‐Backlog‐ Einträge in Increments von Wert umwandeln sollen.

Das Sprint‐Ziel, die für den Sprint ausgewählten Product‐Backlog‐Einträge und der Plan für deren Lieferung werden zusammenfassend als Sprint Backlog bezeichnet.

Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event in der Regel kürzer.

[^]

[Seiten 11-12]

Sprint-Ziel

Das Sprint-Ziel ist ein übergeordneter Zweck für den Sprint, der durch die Implementierung der Product-Backlog-Einträge erreicht werden kann. Es gibt dem Development Team Orientierung, warum sie dieses Product Increment bauen. Das Sprint-Ziel wird während des Sprint Plannings erarbeitet. Das Sprint-Ziel bietet dem Development Team 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 Development Team - statt in verschiedene Richtungen zu laufen - zur Zusammenarbeit motiviert.

Bei seiner Arbeit behält das Development Team 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 Development Team gemeinsam mit dem Product Owner eine Änderung des Sprint-BacklogUmfangs für den laufenden Sprint aus.

[^]

[siehe Seite 12, „Commitment: Sprint-Ziel“: „Das Sprint‐Ziel ist die einzige Zielsetzung für den Sprint. Obwohl das Sprint‐Ziel ein Commitment der Developer:innen ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die erforderlich ist, um es zu erreichen. Das Sprint‐Ziel schafft auch Kohärenz und Fokus und ermutigt somit das Scrum Team, zusammen statt in separaten Initiativen zu arbeiten.

Das Sprint‐Ziel wird während des Sprint‐Planning‐Events erstellt und dann zum Sprint Backlog hinzugefügt. Während die Developer:innen innerhalb des Sprints arbeiten, behalten sie das Sprint‐Ziel im Gedächtnis. Wenn sich herausstellt, dass die Arbeit von ihren Erwartungen abweicht, arbeiten sie mit dem:der Product Owner:in zusammen, um den Umfang des Sprint Backlogs innerhalb des Sprints zu verhandeln, ohne das Sprint‐Ziel zu beeinflussen.“]

[^]

[Seiten 12-13]

Daily Scrum

Das Daily Scrum ist eine Time Box von 15 Minuten für das Development Team. Das Daily Scrum findet an jedem Tag des Sprints statt. Das Development Team plant dabei die Arbeit für die nächsten 24 Stunden. Es überprüft die Arbeitsergebnisse seit dem letzten Daily Scrum und prognostiziert die im Sprint bevorstehende Arbeit, um die Zusammenarbeit und Leistung des Teams zu optimieren. Um die Komplexität zu reduzieren, wird das Daily Scrum an jedem Tag zur gleichen Uhrzeit am gleichen Ort abgehalten.

Das Development Team ü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 Development Team sein Sprint-Ziel erreicht. Das Development Team 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 Increment zum Sprintende zu liefern.

Die Struktur des Ereignisses wird vom Development Team festgelegt und kann auf unterschiedliche Weise durchgeführt werden, sofern die Erreichung des Sprint-Ziels im Fokus steht. Einige Development Teams verwenden Fragen, andere konzentrieren sich eher auf Diskussionen. Hier ist ein Beispiel, was verwendet werden könnte:

  • Was habe ich gestern getan, das dem Development Team geholfen hat, das Sprint-Ziel zu erreichen?
  • Was werde ich heute erledigen, um dem Development Team beim Erreichen des Sprint-Ziels zu helfen?
  • Sehe ich irgendein Hindernis, das mich oder das Development Team daran hindert, das Sprint-Ziel zu erreichen?

Das Development Team 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 Development Team für die Durchführung zuständig. Hierzu bringt der Scrum Master dem Development Team bei, wie es die 15-minütige Time Box des Daily Scrums einhalten kann.

Das Daily Scrum ist ein internes Ereignis für das Development Team. Falls andere Personen anwesend sind, stellt der Scrum Master sicher, dass sie das Meeting nicht stören.

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 Development Teams. Das Daily Scrum ist ein entscheidendes Meeting zur Überprüfung und Anpassung.

[^]

[Seite 10]

Daily Scrum

Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des Sprint‐Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.

Das Daily Scrum ist ein 15‐minütiges Event für die Developer:innen des Scrum Teams. Um die Komplexität zu reduzieren, wird es an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort abgehalten. Falls der:die Product Owner:in oder der:die Scrum Master:in aktiv an Einträgen des Sprint Backlogs arbeitet, nimmt er:sie als Developer:in teil.

Die Developer:innen können Struktur und Techniken beliebig wählen, solange ihr Daily Scrum sich auf den Fortschritt in Richtung des Sprint‐Ziels fokussiert und einen umsetzbaren Plan für den nächsten Arbeitstag erstellt. Das schafft Fokus und fördert Selbstmanagement.

Daily Scrums verbessern die Kommunikation, identifizieren Hindernisse, fördern die schnelle Entscheidungsfindung und eliminieren konsequent die Notwendigkeit für andere Meetings.

Das Daily Scrum ist nicht die einzige Gelegenheit, bei der die Developer:innen ihren Plan anpassen dürfen. Sie treffen sich oftmals während des Tages für detailliertere Diskussionen zur Anpassung oder Neuplanung der restlichen Arbeit des Sprints.

[^]

[Seite 13]

Sprint Review

Am Ende eines Sprints wird ein Sprint Review abgehalten, um das Product Increment 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 Increments 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 Obergrenze [Time Box] von vier Stunden angesetzt. Für kürzere Sprints wird in der Regel ein kürzerer Zeitrahmen veranschlagt. Der Scrum Master stellt sicher, dass das Event stattfindet und die Teilnehmer seinen Zweck verstehen. Der Scrum Master bringt allen Beteiligten bei, das Event innerhalb der Frist [Time Box] durchzuführen.

Das Sprint Review beinhaltet die folgenden Elemente:

  • Die Teilnehmer, bestehend aus dem Scrum Team und wichtigen Stakeholdern, die vom Product Owner eingeladen werden.
  • Der Product Owner erklärt, welche Product-Backlog-Einträge „Done" sind, und welche nicht.
  • Das Development Team stellt dar, was während des Sprints gut lief, welche Probleme aufgetaucht sind, und wie es diese Probleme gelöst hat.
  • Das Development Team führt die fertige Arbeit vor, und beantwortet Fragen zu dem Increment.
  • Der Product Owner stellt den aktuellen Stand des Product Backlogs dar. Er gibt bei Bedarf eine aktualisierte Vorhersage von wahrscheinlichen Ziel- und Lieferterminen auf der Basis des Entwicklungsfortschritts.
  • Alle Teilnehmer erarbeiten gemeinsam, was als nächstes zu tun ist, so dass das Sprint Review wertvollen Input für die kommenden Sprint Plannings liefert.
  • Es erfolgt eine Begutachtung, ob sich durch die Marktsituation oder den möglichen Produkteinsatz neue Erkenntnisse über die wertvollsten nächsten Schritte ergeben haben.
  • Anschließend werden Zeitplan, Budget, die potentiellen Eigenschaften sowie die Markterwartungen für das nächste zu erwartende Produkt-Release überprüft.
  • 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.

[^]

[Seite 10]

Sprint Review

Zweck des Sprint Reviews ist es, das Ergebnis des Sprints zu überprüfen und künftige Anpassungen festzulegen. Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholder:innen vor, und die Fortschritte in Richtung des Produkt‐Ziels werden diskutiert.

Während des Events überprüfen das Scrum Team und die Stakeholder:innen, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat. Auf der Grundlage dieser Informationen arbeiten die Teilnehmenden gemeinsam daran, was als Nächstes zu tun ist. Auch kann das Product Backlog angepasst werden, um neue Möglichkeiten wahrzunehmen. Das Sprint Review ist ein Arbeitstermin, und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken.

Das Sprint Review ist das vorletzte Event des Sprints und ist für einen einmonatigen Sprint auf maximal vier Stunden zeitlich beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.

[^]

[Seite 14]

Sprint Retrospective

Die Sprint Retrospective 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 Obergrenze von drei Stunden angesetzt. Bei kürzeren 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.

Der Scrum Master sorgt dafür, dass das Meeting konstruktiv und produktiv ist. Der Scrum Master lehrt alle, die Time Box einzuhalten. Aufgrund seiner Verantwortung für den ScrumProzess nimmt der Scrum Master als gleichberechtigtes Mitglied an der Sprint Retrospective teil.

Die Sprint Retrospective wird durchgeführt, um

  • zu überprüfen wie der vergangene Sprint in Bezug auf die beteiligten Personen, Beziehungen, Prozesse und Werkzeuge verlief;
  • die wichtigsten gut gelaufenen Elemente und mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen; und
  • einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Scrum Teams zu erstellen.

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 Retrospective erarbeitet das Scrum Team Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Prozesse oder der Definition of Done, sofern diese Änderungen angemessen sind und nicht im Widerspruch mit Produkt- oder Unternehmensstandards stehen.

Zum Ende der Sprint Retrospective 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 Retrospective eine formelle Gelegenheit, sich auf die Überprüfung und Anpassung zu fokussieren.

[^]

[Seiten 10-11]

Sprint Retrospective

Der Zweck der Sprint Retrospective ist es, Wege zur Steigerung von Qualität und Effektivität zu planen.

Das Scrum Team überprüft, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done verlief. Die überprüften Elemente variieren oft je nach Arbeitsdomäne. Annahmen, die das Team in die Irre geführt haben, 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 auch nicht).

Das Scrum Team identifiziert die hilfreichsten Änderungen, um seine Effektivität zu verbessern. Die wirkungsvollsten Verbesserungen werden so schnell wie möglich in Angriff genommen. Sie können sogar in das Sprint Backlog für den nächsten Sprint aufgenommen werden.

Die Sprint Retrospective schließt den Sprint ab. Sie ist für einen einmonatigen Sprint auf maximal drei Stunden beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.

Scrum Poster 2020

Laden Sie hier unser kostenloses Scrum Framework 2020 Poster herunter. Sie können es als visuelle Unterstützung für Ihr Scrum-Team und Ihre Organisation nutzen.

download!
 
Scrum Guide 2017 Scrum Guide 2020

[^]

[Seite 14]

Scrum-Artefakte

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.

[^]

[Seite 11]

Scrum‐Artefakte

Die Artefakte von Scrum repräsentieren Arbeit oder Wert. Sie sind dafür ausgelegt, die Transparenz von Schlüsselinformationen zu maximieren. So haben alle, die sie überprüfen, die gleiche Grundlage für Anpassungen.

Jedes Artefakt beinhaltet ein Commitment, um sicherzustellen, dass Informationen bereitgestellt werden, welche Transparenz und Fokus verbessern, um den Fortschritt messbar zu machen:

  • Für das Product Backlog ist es das Produkt‐Ziel.
  • Für das Sprint Backlog ist es das Sprint‐Ziel.
  • Für das Increment ist es die Definition of Done.

Diese Commitments dienen dazu, Empirie und die Scrum‐Werte für das Scrum Team und seine Stakeholder:innen zu verstärken.

[^]

[Seiten 15-16]

Product Backlog

Das Product Backlog ist eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. Der Product Owner ist für das Product Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich.

Ein Product Backlog ist niemals vollständig. Während seiner ersten Entwicklungsschritte zeigt es 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. Sofern ein Produkt existiert, gibt es auch das dazugehörige Product Backlog.

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. Product-Backlog-Einträge enthalten oft Testbeschreibungen, die ihre Vollständigkeit nachweisen, wenn sie „Done“ sind.

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 Refinement [Verfeinerung] 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. Das Refinement ist ein kontinuierlicher Prozess, in dem der Product Owner und das Development Team gemeinsam die Product-Backlog-Einträge detaillieren. Beim Refinement 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 Development Teams beanspruchen. Der Product Owner kann jedoch jederzeit die Einträge im Product Backlog aktualisieren oder aktualisieren lassen.

Höher eingeordnete 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-BacklogEinträge, mit denen sich das Development Team im kommenden Sprint beschäftigen soll, werden so weit verfeinert, dass jeder von ihnen innerhalb des Sprints fertiggestellt werden kann. Die Product-Backlog-Einträge, für die das der Fall ist, werden als bereit ["Ready"] für die Auswahl durch das Development Team in einem Sprint Planning angesehen. Ein ProductBacklog-Eintrag entwickelt diesen Transparenzgrad in der Regel durch die oben beschriebenen Refinement-Aktivitäten.

Das Development Team ist für alle Schätzungen verantwortlich. Der Product Owner kann das Development Team 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.

[^]

[Seiten 11-12]

Product Backlog

Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden. Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird.

Product‐Backlog‐Einträge, die durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint‐Planning‐Event. Diesen Transparenzgrad erlangen sie in der Regel durch Refinement‐Aktivitäten. Das Refinement des Product Backlogs ist der Vorgang, durch den Product‐Backlog‐Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.

Die Developer:innen, die die Arbeit erledigen werden, sind für die Größenbestimmung umsetzungsverantwortlich. Der:die Product Owner:in kann die Developer:innen beeinflussen, indem er:sie dabei unterstützt, die Product‐Backlog‐Einträge zu verstehen und Kompromisse einzugehen.

 

[^]

[Seite 12]

Commitment: Produkt‐Ziel

Das Produkt‐Ziel beschreibt einen zukünftigen Zustand des Produkts, welches dem Scrum Team als Planungsziel dienen kann. Das Produkt‐Ziel befindet sich im Product Backlog. Der Rest des Product Backlogs entsteht, um zu definieren, „was“ das Produkt‐Ziel erfüllt.

Ein Produkt ist ein Instrument, um Wert zu liefern. Es hat klare Grenzen, bekannte Stakeholder:innen, eindeutig definierte Benutzer:innen oder Kund:innen. Ein Produkt kann eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein.

Das Produkt‐Ziel ist das langfristige Ziel für das Scrum Team. Das Scrum Team muss eine Zielvorgabe erfüllen (oder aufgeben), bevor es die nächste angeht.

[^]

[Seite 16]

Überwachung der Zielerreichung

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 Burnup-Diagramme. Diese haben sich als nützlich erwiesen, allerdings schmälern sie nicht die Bedeutung des empirischen Vorgehens. In komplexen Umgebungen lassen sich zukünftige Ereignisse nicht vorherbestimmen. Nur was bereits geschehen ist, gibt Anhaltspunkte für die zukunftsgerichtete Entscheidungsfindung.

[^]

[siehe Seite 11, „Scrum-Artefakte“, Absatz 2: „Jedes Artefakt beinhaltet ein Commitment, [...] um den Fortschritt messbar zu machen...“

und

Seite 12, „Commitment: Produkt‐Ziel“

und

Seite 8, „Der Sprint“, 2. bis letzter Absatz: „Es gibt verschiedene Vorgehensweisen, um den Fortschritt vorherzusagen, wie Burn‐Down‐Charts, Burn‐ Up‐Charts oder Cumulative‐Flow‐Diagramme. Diese haben sich zwar als nützlich erwiesen, ersetzen jedoch nicht die Bedeutung der Empirie. In komplexen Umgebungen ist unbekannt, was passieren wird. Nur was bereits geschehen ist, kann für eine vorausschauende Entscheidungsfindung genutzt werden.“]

[^]

[Seiten 16-17]

Sprint Backlog

Das Sprint Backlog ist die Menge der für den Sprint ausgewählten Product-Backlog-Einträge, ergänzt um einen Plan, um das Product Increment zu liefern und das Sprint-Ziel zu erreichen. Das Sprint Backlog ist eine Prognose des Development Teams darüber, welche Funktionalität im nächsten Increment enthalten sein wird, sowie über die erforderliche Arbeit, um diese Funktionalität in einem „Done“ Increment zu liefern.

Das Sprint Backlog macht die gesamte Arbeit sichtbar, die das Development Team für notwendig erachtet, um das Sprint-Ziel zu erreichen. Um kontinuierliche Verbesserungen zu gewährleisten, umfasst es mindestens eine wichtige Prozessverbesserung, die in der vorherigen Retrospektive identifiziert wurde.

Das Sprint Backlog ist ein ausreichend detaillierter Plan, um den Fortschritt innerhalb des Sprints im Daily Scrum erkennen zu können. Das Development Team 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 Development Team 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 Development Team 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 Development Team kann sein Sprint Backlog während des Sprints ändern. Das Sprint Backlog ist ein hochgradig sichtbares Echtzeit-Abbild der Arbeit, die das Development Team plant, während des Sprints zu erreichen. Es gehört einzig und allein dem Development Team.

[^]

[Seite 12]

Sprint Backlog

Das Sprint Backlog besteht aus dem Sprint‐Ziel (Wofür), den für den Sprint ausgewählten Product‐ Backlog‐Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie).

Das Sprint Backlog ist ein Plan von und für die Developer:innen. Es ist ein deutlich sichtbares Echtzeitbild der Arbeit, welche die Developer:innen während des Sprints zur Erreichung des Sprint‐Ziels ausführen wollen. Folglich wird das Sprint Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde. Es sollte genügend Details beinhalten, damit sie ihren Fortschritt im Daily Scrum überprüfen können.

[^]

[siehe Seite 11, „Sprint-Ziel“: „Das Sprint-Ziel ist ein übergeordneter Zweck für den Sprint, der durch die Implementierung der Product-Backlog-Einträge erreicht werden kann. Es gibt dem Development Team Orientierung, warum sie dieses Product Increment bauen. Das Sprint-Ziel wird während des Sprint Plannings erarbeitet. Das Sprint-Ziel bietet dem Development Team 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 Development Team - statt in verschiedene Richtungen zu laufen - zur Zusammenarbeit motiviert.“]

[^]

[Seite 12]

Commitment: Sprint‐Ziel

Das Sprint‐Ziel ist die einzige Zielsetzung für den Sprint. Obwohl das Sprint‐Ziel ein Commitment der Developer:innen ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die erforderlich ist, um es zu erreichen. Das Sprint‐Ziel schafft auch Kohärenz und Fokus und ermutigt somit das Scrum Team, zusammen statt in separaten Initiativen zu arbeiten.

Das Sprint‐Ziel wird während des Sprint‐Planning‐Events erstellt und dann zum Sprint Backlog hinzugefügt. Während die Developer:innen innerhalb des Sprints arbeiten, behalten sie das Sprint‐Ziel im Gedächtnis. Wenn sich herausstellt, dass die Arbeit von ihren Erwartungen abweicht, arbeiten sie mit dem:der Product Owner:in zusammen, um den Umfang des Sprint Backlogs innerhalb des Sprints zu verhandeln, ohne das Sprint‐Ziel zu beeinflussen.

[^]

[Seite 17]

Überwachung des Sprint-Fortschritts

Zu jedem Zeitpunkt im Sprint kann die gesamte verbleibende Arbeit an den Sprint-BacklogEinträgen aufsummiert werden. Das Development Team 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 Development Team seinen Fortschritt steuern.

[^]

[siehe Seite 11, „Scrum‐Artefakte“
„Jedes Artefakt beinhaltet ein Commitment, [...] um den Fortschritt messbar zu machen...“

und

Seite 12, „Commitment: Sprint‐Ziel“]

[^]

[Seite 17]

Increment

Das Increment ist das Ergebnis aus allen in einem Sprint fertiggestellten Product-BacklogEinträgen und dem Resultat der Incremente aller früheren Sprints. Am Ende eines Sprints muss das neue Increment „Done" sein; das heißt es muss in einem verwendbaren Zustand sein und die Definition of „Done“ des Teams erfüllen. Ein Increment ist ein Gegenstand inspizierbarer, fertiger Arbeit, der die Empirie am Ende des Sprints unterstützt. Das Increment ist ein Schritt in Richtung einer Vision oder eines Ziels. Es muss auch dann im einsatzfähigen Zustand sein, wenn der Product Owner es aktuell noch gar nicht ausliefern will.

[^]

[Seite 13]

Increment

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

Innerhalb eines Sprints kann mehr als ein Increment erstellt werden. Deren Summe wird im Sprint Review vorgestellt, womit Empirie unterstützt wird. Ein Increment könnte jedoch auch schon vor Ende des Sprints an die Stakeholder:innen geliefert werden. Das Sprint Review sollte niemals als Barriere zur Lieferung von Wert angesehen werden.

Arbeit kann nicht als Teil eines Increments betrachtet werden, solange sie nicht der Definition of Done entspricht.

[^]

[siehe Seiten 17-18, „Definition of Done“: „Es müssen alle verstehen, was „Done“ bedeutet, sobald ein Product-Backlog-Eintrag oder ein Product Increment als „Done“ bezeichnet wird. Obwohl sich dies erheblich von Scrum Team zu Scrum Team unterscheiden kann, 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 Product Increment fertig ist.

Die gleiche Definition leitet das Development Team bei der Entscheidung, wie viele ProductBacklog-Einträge es während des Sprint Plannings selektieren kann. Der Zweck eines jeden Sprints ist es, Incremente potentiell auslieferbarer Funktionalität zu liefern, die der aktuellen Definition of „Done“ des Scrum Teams entsprechen.

Development Teams liefern jeden Sprint ein Increment an Produktfunktionalität. Dieses Increment 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 Increment Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, müssen alle Scrum Teams diese als Minimalziel befolgen.

Wenn „Done" für ein Increment nicht Teil der Konvention der Entwicklungsorganisation ist, muss das Development Team des Scrum Teams eine für das Produkt geeignete Definition of „Done“ formulieren [Anm. d. Übers.: Das heißt nicht, dass Product Owner und Scrum Master nicht eingebunden werden]. Wenn es mehrere Scrum Teams gibt, die am selben System- oder Produktrelease arbeiten, müssen alle Development Teams aller Scrum Teams gemeinsam eine Definition of „Done“ erstellen.

Jedes Increment ist additiv zu allen früheren Incrementen und gründlich getestet, um sicherzustellen, dass alle Incremente 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. Neue Einträge in der Definition of „Done“ können dazu führen, dass noch zu erledigende Arbeit in früheren „Done" Product Incrementen aufgedeckt wird. Jedes einzelne Produkt oder System sollte eine Definition of „Done“ haben, welche den Standard für jegliche daran durchgeführte Arbeit darstellt.“]

[^]

[Seite 13]

Commitment: Definition of Done

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

In dem Moment, in dem ein Product‐Backlog‐Eintrag die Definition of Done erfüllt, wird ein Increment geboren.

Die Definition of Done schafft Transparenz, indem sie allen ein gemeinsames Verständnis darüber vermittelt, welche Arbeiten als Teil des Increments abgeschlossen wurden. Wenn ein Product‐Backlog‐ Eintrag nicht der Definition of Done entspricht, kann es weder released noch beim Sprint Review präsentiert werden. Stattdessen wandert es zur zukünftigen Berücksichtigung in das Product Backlog zurück.

Wenn die Definition of Done für ein Increment Teil der Standards der Organisation ist, müssen alle Scrum Teams diese als Mindestmaß befolgen. Wenn sie kein Organisationsstandard ist, muss das Scrum Team eine für das Produkt geeignete Definition of Done erstellen.

Die Developer:innen müssen sich an die Definition of Done halten. Wenn mehrere Scrum Teams an einem Produkt zusammenarbeiten, müssen sie eine gemeinsame Definition of Done definieren und sich alle daran halten.

[^]

[Seite 17]

Transparenz der Artefakte

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 Development Team 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.

[^]

[siehe Seite 4, „Transparenz“: „... Bei Scrum basieren wichtige Entscheidungen auf dem wahrgenommenen Zustand seiner drei formalen Artefakte. Artefakte, die wenig transparent sind, können zu Entscheidungen führen, die den Wert mindern und das Risiko erhöhen.“]

und

[siehe Seite 11, „Scrum‐Artefakte“: „Die Artefakte von Scrum repräsentieren Arbeit oder Wert. Sie sind dafür ausgelegt, die Transparenz von Schlüsselinformationen zu maximieren. [...] Jedes Artefakt beinhaltet ein Commitment, um sicherzustellen, dass Informationen bereitgestellt werden, welche Transparenz [...] verbessern ...“]

[^]

[Seiten 17-18]

Definition of „Done“

Es müssen alle verstehen, was „Done“ bedeutet, sobald ein Product-Backlog-Eintrag oder ein Product Increment als „Done“ bezeichnet wird. Obwohl sich dies erheblich von Scrum Team zu Scrum Team unterscheiden kann, 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 Product Increment fertig ist.

Die gleiche Definition leitet das Development Team bei der Entscheidung, wie viele ProductBacklog-Einträge es während des Sprint Plannings selektieren kann. Der Zweck eines jeden Sprints ist es, Incremente potentiell auslieferbarer Funktionalität zu liefern, die der aktuellen Definition of „Done“ des Scrum Teams entsprechen.

Development Teams liefern jeden Sprint ein Increment an Produktfunktionalität. Dieses Increment 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 Increment Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, müssen alle Scrum Teams diese als Minimalziel befolgen.

Wenn „Done" für ein Increment nicht Teil der Konvention der Entwicklungsorganisation ist, muss das Development Team des Scrum Teams eine für das Produkt geeignete Definition of „Done“ formulieren [Anm. d. Übers.: Das heißt nicht, dass Product Owner und Scrum Master nicht eingebunden werden]. Wenn es mehrere Scrum Teams gibt, die am selben System- oder Produktrelease arbeiten, müssen alle Development Teams aller Scrum Teams gemeinsam eine Definition of „Done“ erstellen.

Jedes Increment ist additiv zu allen früheren Incrementen und gründlich getestet, um sicherzustellen, dass alle Incremente 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. Neue Einträge in der Definition of „Done“ können dazu führen, dass noch zu erledigende Arbeit in früheren „Done" Product Incrementen aufgedeckt wird. Jedes einzelne Produkt oder System sollte eine Definition of „Done“ haben, welche den Standard für jegliche daran durchgeführte Arbeit darstellt.

[^]

[siehe Seite 13, „Commitment: Definition of Done“: „Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.

In dem Moment, in dem ein Product‐Backlog‐Eintrag die Definition of Done erfüllt, wird ein Increment geboren.

Die Definition of Done schafft Transparenz, indem sie allen ein gemeinsames Verständnis darüber vermittelt, welche Arbeiten als Teil des Increments abgeschlossen wurden. Wenn ein Product‐Backlog‐ Eintrag nicht der Definition of Done entspricht, kann es weder released noch beim Sprint Review präsentiert werden. Stattdessen wandert es zur zukünftigen Berücksichtigung in das Product Backlog zurück.

Wenn die Definition of Done für ein Increment Teil der Standards der Organisation ist, müssen alle Scrum Teams diese als Mindestmaß befolgen. Wenn sie kein Organisationsstandard ist, muss das Scrum Team eine für das Produkt geeignete Definition of Done erstellen.

Die Developer:innen müssen sich an die Definition of Done halten. Wenn mehrere Scrum Teams an einem Produkt zusammenarbeiten, müssen sie eine gemeinsame Definition of Done definieren und sich alle daran halten.“]

[^]

[Seite 19]

Schlussbemerkung

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.

[^]

[Seite 14]

Schlussbemerkung

Scrum ist kostenlos und wird in diesem Guide angeboten. Das Scrum‐Rahmenwerk, wie es hier beschrieben wird, ist unveränderlich. Es ist zwar möglich, nur Teile von Scrum zu implementieren, aber das Ergebnis ist nicht Scrum. Scrum existiert nur in seiner Gesamtheit und funktioniert gut als Container für andere Techniken, Methodiken und Praktiken.

[^]

[Seite 20]

Danksagungen

Menschen

Von den Tausenden Menschen, die zu Scrum beigetragen haben, sollten wir diejenigen besonders hervorheben, die für Scrum in seinen Anfängen von besonderer Bedeutung waren. Jeff Sutherland arbeitete mit Jeff McKenna sowie John Scumniotales, und Ken Schwaber arbeitete mit Mike Smith sowie Chris Martin - und alle arbeiteten zusammen. Viele weitere haben in den folgenden Jahren einen Beitrag geleistet. Ohne deren Hilfe wäre Scrum nicht so ausgefeilt, wie es heute ist.

[^]

[Seite 14]

Danksagungen

Personen

Von den tausenden Personen, die zu Scrum beigetragen haben, sollten wir diejenigen hervorheben, die zu Beginn von besonderer Bedeutung waren: Jeff Sutherland arbeitete mit Jeff McKenna und John Scumniotales, und Ken Schwaber arbeitete mit Mike Smith sowie Chris Martin ‐ und sie alle arbeiteten zusammen. Viele weitere haben in den folgenden Jahren einen Beitrag geleistet. Ohne deren Hilfe wäre Scrum nicht so ausgefeilt, wie es heute ist.

[^]

[Seite 20]

Historie

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 wird an anderer Stelle beschrieben. Zur Würdigung der ersten Orte, an denen Scrum ausprobiert und verfeinert wurde, möchten wir hier Individual, Inc., Newspage, 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.

[^]

[Seite 14]

Scrum‐Guide‐Historie

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 vorherigen Jahren bei der Anwendung von Scrum gewonnen hatten, und stellte die erste formale Veröffentlichung der Definition von Scrum dar.

Der Scrum Guide dokumentiert Scrum, wie es von Jeff Sutherland und Ken Schwaber über 30 Jahre lang weiterentwickelt wurde, gewachsen ist und aufrechterhalten wurde. Andere Quellen liefern Muster, Prozesse und Erkenntnisse, die das Scrum‐Rahmenwerk ergänzen. Diese können zur Steigerung der Produktivität, des Werts, der Kreativität und der Zufriedenheit mit den Ergebnissen führen.

Die vollständige Geschichte von Scrum wird an anderer Stelle beschrieben. Um die ersten Orte zu würdigen, an denen es erprobt wurde und sich bewährt hat, erkennen wir Individual Inc., Newspage, Fidelity Investments und IDX (jetzt GE Medical) als solche an.

[^]

[Seite 20]

Übersetzung

Dieser Guide wurde von der englischen Originalversion, bereitgestellt von Ken Schwaber und Jeff Sutherland, übersetzt. Hierzu beigetragen haben:

2011: Dominik Maximini, Andreas Schliep, Ulf Schneider, Wolfgang Wiedenroth

2013: Jan Gretschuskin, Dominik Maximini, Pascal Naujoks, Sabrina Roos, Andreas Schliep, Wolfgang Wiedenroth

2016: Jan Gretschuskin, Dominik Maximini, Pascal Naujoks, Boris Steiner, Jürgen Halstenberg, Ralph Jocham, Wolf Dieter Moggert, Patrick Koglin, Harald Schlindwein

2017: Sabine Canditt, Jan Gretschuskin, Eva Gysling, Martin Hoppacher, Ralph Jocham, Dominik Maximini, Stefan Mieth, Wolf Dieter Moggert, Pascal Naujoks, Urs Reupke, Anna Rudat, Andreas Schliep, Harald Schlindwein, Peter Schmidt, Boris Steiner

[^]

[Seite 16]

Übersetzung

Dieser Guide wurde von der englischen Originalversion, bereitgestellt von Ken Schwaber und Jeff Sutherland, übersetzt. Hierzu beigetragen haben:

2020: Silke von der Bruck, Sabine Canditt, Jan Gretschuskin, Eva Gysling, Martin Hoppacher, Björn Jensen, Ralph Jocham, Dominik Maximini, Wolf Dieter Moggert, Peter Schmidt, Boris Steiner

2017: Sabine Canditt, Jan Gretschuskin, Eva Gysling, Martin Hoppacher, Ralph Jocham, Dominik Maximini, Stefan Mieth, Wolf Dieter Moggert, Pascal Naujoks, Urs Reupke, Anna Rudat, Andreas Schliep, Harald Schlindwein, Peter Schmidt, Boris Steiner

2016: Jan Gretschuskin, Dominik Maximini, Pascal Naujoks, Boris Steiner, Jürgen Halstenberg, Ralph Jocham, Wolf Dieter Moggert, Patrick Koglin, Harald Schlindwein

2013: Jan Gretschuskin, Dominik Maximini, Pascal Naujoks, Sabrina Roos, Andreas Schliep, Wolfgang Wiedenroth

2011: Dominik Maximini, Andreas Schliep, Ulf Schneider, Wolfgang Wiedenroth

[^]

 

© 2017 Ken Schwaber and Jeff Sutherland. 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 Share-Alike license of Creative Commons.

[^]

 

© 2020 Ken Schwaber and Jeff Sutherland. This publication is 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 Share-Alike license of Creative Commons.

Dieser Vergleich wurde von Johannes Geske, Professional Scrum Trainer™ (PST) bei Scrum.org und Agile Coach bei Amazing Outcomes in Düsseldorf, Deutschland, erstellt. Der Vergleich wird unter der gleichen Lizenz wie der Scrum Guide angeboten, der Attribution Share-Alike license von Creative Commons, die hier und in zusammengefasster Form hier zugänglich ist. Indem Sie diesen Vergleich nutzen, bestätigen Sie, dass Sie die Bedingungen der Attribution Share-Alike license von Creative Commons gelesen haben und damit einverstanden sind, an diese gebunden zu sein.

 

1) Quelle: Scrum Guide 2020 (aufgerufen am: 24‑Feb‑2022)