You are on page 1of 19

Der Scrum Guide

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

 

 

 

 

 
 
Juli 2016 
 
Entwickelt und kontinuierlich verbessert von Ken Schwaber und Jeff Sutherland 
 
 

 

............................................................................................................................org/licenses/by-sa/4............................................................................................................................................................................... 8  Der Sprint ....................................................................................................................................................................................................... 16  Transparenz der Artefakte ............................. 8  Sprint Planning ............................... 3  Scrum: Werte.............. 16  Schlussbemerkung ...................................................... 17  Menschen ................................................. 9  Daily Scrum ......................................................................................................................................................................... 4  Das Scrum Team ............................... 6  Der Scrum Master ............................................................................................................................................................ 7  Scrum Ereignisse ................................................................................................................................... 11  Sprint Review .............................. 14  Sprint Backlog ................................. 5  Das Entwicklungsteam............................................................................................................................................................................. 5  Der Product Owner ................................................................................................................................................................................................................................................................................................................................................................................................................................... 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........................................................................................................................................................ 17  Historie .............. Page | 2  ........... 18  Änderungen im Scrum Guide 2016 im Vergleich zur Version von 2013 ................ Offered for license under the Attribution Share-Alike license of Creative Commons. 17  Danksagungen .............................................................................................................................................................................................................. 19    ©2016 Scrum............................................................................................0/legalcode and also described in summary form at http://creativecommons.................................................................................... 3  Scrum: Theorie ....................................................................................... 13  Scrum Artefakte ................... 13  Product Backlog ..................................................................... accessible at http://creativecommons............................ 16  Definition of Done .................................................................................................... 18  Übersetzung ................................................................................................................................................Inhaltsverzeichnis Zielsetzung des Scrum Guide ...... 15  Inkrement .....................................................................................................................................................................................................................0/...............................................................Org and ScrumInc........................................... 18  Änderungshistorie .............................. 12  Sprint Retrospektive ...............org/licenses/by-sa/4......... 3  Definition von Scrum ..........................

  Artefakten sowie den Regeln.Zielsetzung des Scrum Guide    Scrum ist ein Rahmenwerk zur Entwicklung und Erhaltung komplexer Produkte.  Ereignissen.    Durch die Regeln von Scrum werden die Beziehungen und Wechselwirkungen zwischen den  Ereignissen.    Das Scrum Rahmenwerk besteht aus Scrum Teams und den mit ihnen verbundenen Rollen. die sie miteinander verbinden.     ©2016 Scrum. 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. dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des  Bekannten getroffen werden.org/licenses/by-sa/4. Ereignissen. inkrementellen Ansatz. Ken Schwaber und Jeff Sutherland  haben Scrum entwickelt. Empirie  bedeutet.0/legalcode and also described in summary form at http://creativecommons. Beide  stehen gemeinsam hinter dem Scrum Guide. innerhalb dessen Menschen komplexe adaptive  Aufgabenstellungen angehen können. Die Regeln von Scrum sind in diesem Dokument  beschrieben. Scrum nutzt einen iterativen. Scrum ist weder ein Prozess noch eine Technik zur Erstellung  von Produkten. um  Prognosesicherheit zu optimieren und Risiken zu kontrollieren. Diese Definition besteht aus den Scrum Rollen. produktiv  und kreativ Produkte mit höchstmöglichem Wert auszuliefern. so dass  Sie sich verbessern können.    Scrum ist:     Leichtgewichtig   Einfach zu verstehen   Schwierig zu meistern    Scrum wird seit den frühen 1990er Jahren als Prozessrahmenwerk bei der Entwicklung  komplexer Produkte verwendet.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons. Dieser Leitfaden  beinhaltet die Definition von Scrum. der Scrum Guide wird von ihnen verfasst und veröffentlicht. Scrum macht die  relative Wirksamkeit Ihres Produktmanagements und Entwicklungsvorgehens sichtbar.0/.org/licenses/by-sa/4. sondern ist vielmehr als Rahmenwerk zu verstehen. Artefakten und Regeln. und durch das sie in die Lage versetzt werden.    Bestimmte Taktiken zur Nutzung von Scrum variieren und sind an anderer Stelle beschrieben. Jede Komponente des Rahmenwerks dient einem  spezifischen Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg. Page | 3  .    Scrum: Theorie    Scrum basiert auf der Theorie empirischer Prozesssteuerung oder kurz "Empirie". accessible at http://creativecommons. Rollen und Artefakten bestimmt.    Definition von Scrum     Scrum (n): Ein Rahmenwerk. innerhalb dessen  verschiedene Prozesse und Techniken zum Einsatz gebracht werden können.

 Transparenz erfordert. und   die Arbeitsergebnisse produzierenden und akzeptierenden Personen müssen alle ein  gemeinsames Verständnis der Definition von "Done" teilen. müssen der  Prozess oder das zu bearbeitende Material angepasst werden.Drei Säulen tragen jede empirische Prozesssteuerung: Transparenz. Offenheit und Respekt durch das Scrum Team  verkörpert und gelebt werden. wenn sie gewissenhaft durch kompetente Prüfer dort  vorgenommen werden. damit die Betrachter ein gemeinsames Verständnis  des Gesehenen teilen. dass Aspekte des Prozesses von den akzeptablen Grenzwerten  abweichen und dass das resultierende Produkt so nicht akzeptabel sein wird. accessible at http://creativecommons. Mut. Den größten  Nutzen bringen Überprüfungen. Diese werden im  Abschnitt Scrum Ereignisse beschrieben:   Sprint Planning   Daily Scrum     Sprint Review     Sprint Retrospektive  Scrum: Werte    Wenn die Werte Selbstverpflichtung.Org and ScrumInc. um unerwünschte Abweichungen zu erkennen.org/licenses/by-sa/4. indem sie mit den Scrum Ereignissen. Überprüfung [Inspection]  und Anpassung [Adaptation]. die von allen Teilnehmern geteilt wird.0/. die für das  Ergebnis verantwortlich sind.0/legalcode and also described in summary form at http://creativecommons. Page | 4  . Fokus.    ©2016 Scrum. wo die Arbeit verrichtet wird. Die Mitglieder  des Scrum Teams lernen und erforschen diese Werte. Die Anpassung muss [dann] so  schnell wie möglich vorgenommen werden. um weitere Abweichungen zu minimieren.    Anpassung    Wenn ein Prüfer feststellt. 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.  Überprüfung    Scrum Anwender müssen die Scrum Artefakte und den Fortschritt regelmäßig in Bezug auf die  Erreichung des Sprint‐Ziels überprüfen.  Rollen und Artefakten arbeiten. Offered for license under the Attribution Share-Alike license of Creative Commons. Ihre  Untersuchungen sollten nicht so häufig erfolgen. Überprüfung und  Anpassung lebendig und bauen bei allen Beteiligten Vertrauen zueinander auf. dass sie die Arbeit behindern. dass diese Aspekte nach einem  gemeinsamen Standard definiert werden.org/licenses/by-sa/4. werden die Scrum‐Säulen Transparenz.    Transparenz    Die wesentlichen Aspekte des Prozesses müssen für diejenigen sichtbar sein.    Scrum schreibt vier formale Ereignisse für Überprüfung und Anpassung vor.    Dies umfasst beispielsweise     eine gemeinsame Prozesssprache.

 um Flexibilität. Scrum Team  und Einzelpersonen stark variieren. Mitglieder  von Scrum Teams respektieren sich gegenseitig als fähige. Das Team‐Modell in Scrum wurde  konzipiert.   Den Wert der Arbeit zu optimieren. dass stets eine potentiell nützliche Version des Produkts zur Verfügung steht. Wie dies geschieht.org/licenses/by-sa/4. Scrum Teams sind selbstorganisierend und interdisziplinär. dass das Product Backlog sichtbar. Das Product Backlog‐Management umfasst:     Product Backlog‐Einträge klar zu formulieren. Page | 5  . Offered for license under the Attribution Share-Alike license of Creative Commons. dass alle Beteiligten kompetenter bei der  Erfüllung dieser fünf Werte werden. dem Entwicklungsteam. transparent und für alle klar ist sowie  zeigt. das Richtige zu tun und an  schwierigen Problemen zu arbeiten. um die Arbeit zu erledigen. die für das Management des Product Backlogs  verantwortlich ist. accessible at http://creativecommons. die Ziele des Scrum  Teams zu erreichen.  Der Product Owner kann die oben genannten Arbeiten selbst tun oder sie durch das  Entwicklungsteam erledigen lassen. eigenverantwortliche Individuen.Org and ScrumInc. dass das Entwicklungsteam die Product Backlog‐Einträge im erforderlichen  Maße versteht.0/legalcode and also described in summary form at http://creativecommons.0/. kann je nach Organisation.    Der Product Owner ist die einzige Person. Kreativität und Produktivität zu optimieren. sowie dem Scrum  Master. anstatt dieses durch andere  Personen außerhalb des Teams vorgegeben zu bekommen. Die Mitglieder des Scrum Teams haben den Mut. und   sicherzustellen.org/licenses/by-sa/4. Das Scrum Team und seine Stakeholder sind sich einig. die erforderlich sind. offen mit allen  Belangen ihrer Arbeit und den damit verbundenen Herausforderungen umzugehen. Selbstorganisierende Teams  entscheiden selbst.     Das Scrum Team    Ein Scrum Team besteht aus dem Product Owner. Jeder fokussiert sich auf die Arbeit im Sprint und die Ziele  des Scrum Teams.    Scrum Teams liefern Produkte iterativ und inkrementell und maximieren somit die  Gelegenheiten für Feedback. wie sie ihre Arbeit am besten erledigen.Der erfolgreiche Einsatz von Scrum beruht darauf. ohne dabei von  Personen außerhalb des Entwicklungsteams abhängig zu sein. 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.    ©2016 Scrum. Interdisziplinäre Teams verfügen  über alle Kompetenzen. woran das Scrum Team als nächstes arbeiten wird. Sie verpflichten sich persönlich dazu.   Das Sicherstellen. Der Product Owner bleibt jedoch immer  rechenschaftspflichtig [accountable]. die das Entwicklungsteam erledigt. dass Ziele und Missionen optimal erreicht  werden können.  Der Product Owner    Der Product Owner ist für die Wertmaximierung des Produkts sowie der Arbeit des  Entwicklungsteams verantwortlich.   Die Einträge im Product Backlog so zu sortieren. Die inkrementelle Auslieferung von "fertigem" [Done] Produkt  sorgt dafür.

org/licenses/by-sa/4. accessible at http://creativecommons. wie es aus dem Product Backlog potentiell auslieferbare Funktionalität  erzeugen soll.0/. um ein Produkt‐Inkrement zu erstellen. Er kann zwar die Wünsche eines  Komitees im Product Backlog wiedergeben. Es gibt keine Ausnahmen von  dieser Regel. Niemand darf vom Entwicklungsteam verlangen. wie "Test" oder "Analyse". aber diejenigen.    Entwicklungsteams sind von der Organisation so strukturiert und befähigt.  um bedeutende Arbeit innerhalb eines Sprints erledigen zu können.Org and ScrumInc. um durch einen  ©2016 Scrum.    Das Entwicklungsteam    Das Entwicklungsteam besteht aus Profis. Sie haben als Team alle Fähigkeiten.Der Product Owner ist eine einzelne Person.  andere Anforderungen zu bearbeiten. um flink zu bleiben und groß genug. nach den  Angaben einer anderen Person als denen des Product Owners zu arbeiten.   Scrum kennt keine weiteren Unterteilungen innerhalb des Entwicklungsteams. muss die gesamte Organisation seine    Entscheidungen respektieren.    Größe des Entwicklungsteams    Die optimale Größe des Entwicklungsteams ist klein genug. Offered for license under the Attribution Share-Alike license of Creative Commons. Große Entwicklungsteams erzeugen eine zu hohe Komplexität.   Individuelle Mitglieder des Entwicklungsteams können zwar spezialisierte Fähigkeiten oder  Spezialgebiete haben. die einen Eintrag des Product  Backlogs in seiner Priorität verändern möchten. Kleinere Entwicklungsteams können  eventuell kein potentiell auslieferbares Produkt‐Inkrement liefern. die  notwendig sind. Page | 6  . 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.0/legalcode and also described in summary form at http://creativecommons.    Entwicklungsteams weisen die folgenden Eigenschaften auf:     Sie sind selbstorganisierend. Weniger als drei Mitglieder  des Entwicklungsteams reduzieren die Interaktion und führen zu geringeren  Produktivitätssteigerungen [als bei größeren Teams]. Niemand (nicht einmal der Scrum Master) sagt dem  Entwicklungsteam. Es gibt keine  Ausnahmen von dieser Regel. die am Ende eines jeden Sprints ein fertiges  Inkrement übergeben. Mehr als neun Mitglieder erfordern zu viel  Koordination. Nur Mitglieder der Entwicklungsteams  erstellen das Produkt‐Inkrement. Die daraus resultierende Synergie optimiert die  Gesamteffizienz und ‐effektivität des Entwicklungsteams.org/licenses/by-sa/4. dass sie ihre eigene  Arbeit selbst organisieren und managen. welches potentiell auslieferbar ist. da sie möglicherweise nicht  über alle benötigten Fähigkeiten verfügen. aber die Rechenschaftspflicht obliegt dem Team als Ganzem.    Damit der Product Owner erfolgreich sein kann. Dies ist  unabhängig von der Arbeit. Dem Entwicklungsteam ist es nicht erlaubt.   Scrum kennt keine Titel außer "Entwickler" für Mitglieder des Entwicklungsteams. Die Entscheidungen des Product Owners sind in Inhalt und  Reihenfolge des Product Backlogs sichtbar. ungeachtet  von bestimmten zu adressierenden Domänen. müssen sich an den Product Owner wenden. die diese Personen erledigen.   Entwicklungsteams sind interdisziplinär tätig. kein Komitee.

 sofern sie nicht ebenso die Arbeit aus dem Sprint Backlog erledigen. prägnanter Product Backlog  Einträge im Scrum Team.  Der Dienst des Scrum Masters für das Entwicklungsteam    Der Scrum Master dient dem Entwicklungsteam auf verschiedene Arten.   Vermitteln eines Verständnisses für die Notwendigkeit klarer.   Unterstützung des Entwicklungsteams bei der Schaffung hochwertiger Produkte. Offered for license under the Attribution Share-Alike license of Creative Commons.  Der Scrum Master ist ein Servant Leader für das Scrum Team. dass das Scrum Team die Theorie.   Vermitteln des richtigen Verständnisses von Agilität und ihrer Anwendung. Er tut  dies. die  Zusammenarbeit so zu optimieren.   Unterstützen bei Bedarf oder auf Anfrage bei der Durchführung von Scrum Ereignissen.   Sicherstellen.    Der Scrum Master    Der Scrum Master ist für das Verständnis und die Durchführung von Scrum verantwortlich. Page | 7  .org/licenses/by-sa/4. 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. die das Entwicklungsteam aufhalten.     Coachen des Entwicklungsteams in Organisationen. dass der Product Owner weiß.  ©2016 Scrum.   Planen von Scrum‐Implementierungen innerhalb der Organisation.  Der Dienst des Scrum Masters an der Organisation    Der Scrum Master dient der Organisation auf verschiedene Arten. dass es  den größten Wert erzeugt.org/licenses/by-sa/4. unter anderem durch das     Vermitteln von Techniken für eine effektive Verwaltung des Product Backlogs. indem er dafür sorgt.Org and ScrumInc.   Beseitigen von Hindernissen. welche ihrer Interaktionen mit  dem Team sich hilfreich auswirken und welche nicht. Der Scrum Master hilft  denjenigen.    Der Dienst des Scrum Masters für den Product Owner    Der Scrum Master dient dem Product Owner auf verschiedene Arten. Praktiken und Regeln von Scrum  einhält. accessible at http://creativecommons.empirischen Prozess gemanagt werden zu können. unter anderem durch:     Coachen des Entwicklungsteams hin zu Selbstorganisation und funktionsübergreifender  Teamarbeit. wie er das Product Backlog so anordnet. Product Owner und Scrum Master zählen  nicht zu dieser Zahl dazu.   Schaffen eines Verständnisses für Produktplanung in einem empirischen Arbeitsumfeld. Der Scrum Master hilft dabei. in denen Scrum noch nicht vollständig  angenommen und verstanden wird. zu verstehen. unter anderem durch das:     Leiten und Coachen der Organisation bei der Einführung von Scrum.     Unterstützen bei Bedarf oder auf Anfrage bei der Durchführung von Scrum Ereignissen. die kein Teil des Scrum Teams sind.0/legalcode and also described in summary form at http://creativecommons. dass der durch das Scrum Team generierte Wert maximiert  wird.0/.

  Scrum Ereignisse    In Scrum werden vorgeschriebene Ereignisse verwendet.0/legalcode and also described in summary form at http://creativecommons. Diese Ereignisse sind genau dazu gedacht.  an den kritischen Stellen Transparenz und Überprüfung zu ermöglichen.org/licenses/by-sa/4.Org and ScrumInc. Arbeit und Ergebnis in die richtige Richtung führt.   Zusammenarbeiten mit anderen Scrum Mastern. und   der Anforderungsumfang kann zwischen Product Owner und Entwicklungsteam geklärt und  neu ausgehandelt werden. die Daily Scrums.    Der Sprint  Das Herz von Scrum ist der Sprint. wenn sich neue Erkenntnisse ergeben haben. Der  neue Sprint startet sofort nach Abschluss des vorigen Sprints. dass nur so viel Zeit wie nötig aufgewendet und Verschwendung  vermieden wird. Alle  Ereignisse haben eine zeitliche Beschränkung (Time Box). Besprechungen zu minimieren. um eine Regelmäßigkeit herzustellen  und die Notwendigkeit anderer. Unterstützen von Kollegen und Stakeholdern.   wird der Qualitätsanspruch nicht geschmälert. Page | 8  . um die Effektivität von Scrum‐ Implementierungen innerhalb der Organisation zu verbessern. so dass jedes Ereignis eine maximale  Dauer hat. die Entwicklungsarbeit. der die  Umsetzung.0/. accessible at http://creativecommons.  Mit Ausnahme des Sprints als Container für alle anderen Ereignisse ist jedes Scrum Ereignis eine  formale Gelegenheit zur Überprüfung und Anpassung.  das Sprint Review und die Sprint Retrospektive. Die Dauer eines Sprints steht zu seinem Beginn fest und darf weder gekürzt noch  verlängert werden. Jeder  Sprint hat einen definierten Leistungsumfang.org/licenses/by-sa/4. innerhalb dessen  ein fertiges ("Done"). eine Time Box von maximal einem Monat. Das Weglassen  irgendeines dieser Ereignisse führt zu verringerter Transparenz und ist eine verpasste  Gelegenheit den Ist‐Stand zu erfassen und darauf zu reagieren [Inspect & Adapt]. einen Entwurf und einen flexiblen Plan. 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. sobald sie ihren Zweck  erfüllt haben. nutzbares und potenziell auslieferbares Produkt‐Inkrement hergestellt  wird. die das Sprint‐Ziel gefährden.   Auslösen von Veränderungen zur Produktivitätssteigerung des Teams.    ©2016 Scrum. Wie mit einem Projekt will man mit einem Sprint etwas Bestimmtes erreichen.  Jeder Sprint kann als ein Projekt mit einem Zeithorizont von maximal einem Monat gesehen  werden. Dies stellt sicher. Scrum und empirische Produktentwicklung zu  verstehen und umzusetzen. Alle Sprints innerhalb eines Entwicklungsvorhabens sollten die gleiche Dauer haben.    Während des Sprints:     werden keine Änderungen vorgenommen. nicht in Scrum definierter. Die anderen Ereignisse dürfen beendet werden.    Ein Sprint beinhaltet und umfasst das Sprint Planning. Offered for license under the Attribution Share-Alike license of Creative Commons.

 In der Regel sollte ein Sprint dann abgebrochen  werden.    Das Sprint Planning ist auf eine Time Box von maximal 8 Stunden für einen einmonatigen Sprint  beschränkt. Der Product Owner beschreibt das Ziel. kann sich die Definition des Ergebnisses ändern. das mit dem Sprint erreicht werden soll. dass das Ereignis stattfindet und die Teilnehmer seinen Zweck verstehen. Dieser Plan entsteht  durch die gemeinschaftliche Arbeit des gesamten Scrum Teams.  ©2016 Scrum. vor dem Ablauf seiner Time Box.    Wenn ein Sprint abgebrochen wird. Sprint‐Abbrüche sind zudem oft  schmerzhaft für das Scrum Team. Dazu ist  nur der Product Owner berechtigt.org/licenses/by-sa/4. die Komplexität ansteigen und  sich das Risiko erhöhen.0/legalcode and also described in summary form at http://creativecommons. Wenn ein Teil der Arbeit potentiell auslieferbar ist. Bei kürzeren Sprints wendet man normalerweise weniger Zeit auf. oder sich andere Markt‐ oder  technologische Rahmenbedingungen ändern.h. da sich alle Teammitglieder zum Start des neuen  Sprints in einem Sprint Planning neu finden müssen. Page | 9  .org/licenses/by-sa/4. werden alle abgeschlossenen und "Done" Product Backlog‐ Einträge begutachtet. wenn die Fortführung unter den gegenwärtigen Umständen keinen Sinn mehr macht.    Das Sprint Planning beantwortet die folgenden Fragen:      Was ist in dem Produkt‐Inkrement des kommenden Sprints enthalten?   Wie wird die für die Lieferung des Produkt‐Inkrements erforderliche Arbeit erreicht?   Punkt 1: Was kann in diesem Sprint fertiggestellt werden?    Das Entwicklungsteam erstellt eine Prognose über die Funktionalität. Sprints reduzieren dazu noch das Risiko auf die Kosten eines Monats. daher müssen diese Einträge häufiger neu geschätzt werden.Sprints sind auf einen Kalendermonat beschränkt. Die bislang daran geleistete Arbeit  verliert schnell an Wert.0/. wird sie vom Product  Owner meistens abgenommen. Offered for license under the Attribution Share-Alike license of Creative Commons. 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. indem sie mindestens  einmal im Monat Überprüfung und Anpassungen des Fortschritts zu einem bestimmten Sprint‐ Ziel ermöglichen. die im Sprint entwickelt  werden soll. das Ereignis innerhalb der Time Box erfolgreich abzuschließen.  Allerdings macht der Abbruch bei der kurzen Dauer der Sprints selten Sinn.    Sprint Planning    Im Sprint Planning wird die Arbeit für den kommenden Sprint geplant. des Entwicklungsteams oder Scrum Masters vornimmt. accessible at http://creativecommons. Wenn der Zeithorizont eines Sprints zu groß  gewählt wird. d. abgebrochen werden. Der Scrum  Master sorgt dafür. sie sind eher unüblich. Sprints ermöglichen eine Vorhersagbarkeit. wenn das Sprint‐Ziel obsolet wird. Er  bringt dem Scrum Team bei. Das kann  vorkommen.    Ein Sprint würde dann abgebrochen werden. auch wenn er oder sie den Abbruch auf Anraten der  Stakeholder.    Sprint‐Abbrüche verbrauchen Ressourcen.Org and ScrumInc. Alle unvollständigen Product Backlog‐Einträge werden neu  geschätzt und wieder in das Product Backlog aufgenommen.    Einen Sprint abbrechen    Ein Sprint kann vorzeitig. wenn das Unternehmen seine Zielrichtung wechselt.

Org and ScrumInc. es leitet das  Entwicklungsteam in der Frage. welche ‐ wenn sie in dem Sprint abgeschlossen werden ‐ das  Ziel erfüllen. das neueste Produkt‐ Inkrement. wie es die Arbeiten im Sprint Backlog angeht. warum es dieses Produkt‐Inkrement erstellt. was im kommenden Sprint  fertiggestellt werden kann.0/legalcode and also described in summary form at http://creativecommons. wie es als selbstorganisiertes Team an der Erreichung des Sprint‐ Ziels und der Erstellung des gewünschten Produkt‐Inkrements arbeiten möchte. die ausgewählten Product Backlog‐Einträge zu klären und  ggf.    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 Entwicklungsteam. dass es sich zu viel  oder zu wenig Arbeit vorgenommen hat.    Nach der Prognose der Product Backlog‐Einträge für den Sprint durch das Entwicklungsteam  formuliert das ganze Scrum Team ein Sprint‐Ziel aus. wie es das Produkt‐Inkrement erstellen möchte. 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. was im  kommenden Sprint machbar ist.org/licenses/by-sa/4.  damit die Funktionalität in einen "Done"‐Zustand gebracht werden kann. Auf jeden Fall sollte das  Entwicklungsteam genug Arbeit planen.     Am Ende des Sprint Plannings sollte das Entwicklungsteam in der Lage sein. Page | 10  . Die Arbeiten können sich in  der Größe oder dem geschätzten Aufwand unterscheiden. Das ganze Scrum Team erarbeitet gemeinsam ein Verständnis über die  Arbeitsinhalte des Sprints. Es kann nur selbst beurteilen.und die Product Backlog‐Einträge. Als Sprint Backlog  bezeichnet man die Auswahl der Product Backlog‐Einträge für den jeweiligen Sprint plus den  Umsetzungsplan des Entwicklungsteams. nach Bedarf. im Sprint selbst. Offered for license under the Attribution Share-Alike license of Creative Commons. Ausschließlich das Entwicklungsteam bestimmt die Anzahl der ausgewählten  Product Backlog‐Einträge für den kommenden Sprint. kann es die ausgewählten Product Backlog‐Einträge  neu mit dem Product Owner aushandeln. Das Sprint‐Ziel bildet die Messlatte. Das Entwicklungsteam kann auch andere Teilnehmer  zu dem Meeting einladen.    Der Product Owner kann dabei helfen.     Als Eingangsgrößen für das Meeting dienen das Product Backlog. Wenn das Entwicklungsteam herausfindet.    Das Entwicklungsteam beginnt normalerweise mit dem Systementwurf und den notwendigen  Arbeiten zur Erstellung des funktionsfähigen Produkt‐Inkrements. um zu prognostizieren. die veranschlagte Kapazität des Entwicklungsteams im Sprint sowie die bisherige  Leistung desselben.          ©2016 Scrum. um technische oder fachliche Unterstützung zu erhalten. Das  Entwicklungsteam organisiert selbst. Kompromisse einzugehen. beginnend  mit dem Sprint Planning und. Die für die ersten Sprint‐Tage geplanten Arbeiten sind nach  Abschluss des Meetings in kleinere Einheiten ‐ oft von einem Tag oder weniger ‐ zerlegt. accessible at http://creativecommons.0/. Product Owner und  Scrum Master zu schildern. die  durch die Implementierung der Product Backlog‐Einträge im Sprint erreicht wird.org/licenses/by-sa/4.

0/legalcode and also described in summary form at http://creativecommons. die durch die Implementierung  des Product Backlog [‐Einträge] erreicht werden kann. die bis zum nächsten Daily Scrum erreicht werden könnten. warum sie dieses Produkt‐Inkrement bauen.    Um die Komplexität zu reduzieren. welches das Entwicklungsteam ‐ statt in  verschiedene Richtungen zu laufen ‐ zur Zusammenarbeit motiviert.org/licenses/by-sa/4.  Das Sprint‐Ziel bietet dem Entwicklungsteam eine gewisse Flexibilität in Bezug auf die im Sprint  zu implementierende Funktionalität. Falls es sich  zeigt.    ©2016 Scrum. die als Sprint‐Ziel angesehen werden kann. handelt das  Entwicklungsteam gemeinsam mit dem Product Owner eine Änderung des Sprint Backlog‐ Umfangs für den laufenden Sprint aus. Das Daily Scrum erhöht die  Wahrscheinlichkeit. dass der Arbeitsumfang von den ursprünglichen Erwartungen abweicht. dass das Entwicklungsteam sein Sprint‐Ziel erreicht. accessible at http://creativecommons. innerhalb derer das Entwicklungsteam seine  Aktivitäten synchronisiert und an der Planung für die nächsten 24 Stunden arbeitet. Das  geschieht durch die Überprüfung der Arbeit seit dem letzten Daily Scrum und der Prognose der  Arbeitsergebnisse. Page | 11  . wird das Daily Scrum an jedem Tag zur gleichen Uhrzeit am  gleichen Ort abgehalten. um das Sprint‐Ziel zu erreichen und das erwartete Inkrement zum Sprintende zu liefern. um dem Entwicklungsteam bei der Erreichung des  Sprint‐Ziels zu helfen?   Sehe ich irgendwelche Hindernisse. Offered for license under the Attribution Share-Alike license of Creative Commons. das dem Entwicklungsteam hilft.  Das Entwicklungsteam oder einzelne Mitglieder treffen sich häufig direkt nach dem Daily Scrum  für detailliertere Diskussionen. Die ausgewählten Product Backlog‐Einträge bilden eine  zusammenhängende Funktionalität. Während des Meetings schildern die Mitglieder des  Entwicklungsteams:     Was habe ich gestern erreicht. Anpassungen oder Umplanungen der Arbeit im Sprint.Org and ScrumInc.     Daily Scrum    Das Daily Scrum ist eine Time Box von 15 Minuten. 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. Das Entwicklungsteam  sollte Tag für Tag im Blick haben. das Sprint‐Ziel zu  erreichen?   Was werde ich heute erledigen.Sprint‐Ziel    Das Sprint‐Ziel ist eine übergeordnete Zielsetzung für den Sprint.org/licenses/by-sa/4. implementiert es die entsprechende Funktionalität und Technologie.    Bei seiner Arbeit behält das Entwicklungsteam sein Sprint‐Ziel vor Augen. die mich oder das Entwicklungsteam vom Erreichen  des Ziels abhalten?  Das Entwicklungsteam überprüft im Daily Scrum seinen Fortschritt in Richtung des Sprint‐Ziels  und den Trend bei der Abarbeitung der Sprint Backlog‐Einträge. Das Sprint‐Ziel  kann aber auch jedes andere verbindende Element sein. Um dieses zu  erreichen. wie es als selbstorganisiertes Team zusammenarbeiten  möchte. Das Sprint‐Ziel wird während des  Sprint Planning erarbeitet. Es gibt dem Entwicklungsteam  Orientierung.0/.

 welche Product Backlog‐Einträge "Done" sind. keinen  Statusreport.Org and ScrumInc.  ©2016 Scrum. 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. auf der Basis des  Entwicklungsfortschritts. um das [Produkt‐]Inkrement zu  überprüfen und das Product Backlog bei Bedarf anzupassen.   Das Entwicklungsteam führt die "Done"‐ Arbeiten vor. und welche nicht.   Es erfolgt eine Begutachtung.org/licenses/by-sa/4. dass ein Daily Scrum stattfindet. was während des Sprints gut lief.  identifizieren zu beseitigende Hindernisse.   Der Product Owner stellt den aktuellen Stand des Product Backlogs dar.   Das Entwicklungsteam stellt dar.0/.0/legalcode and also described in summary form at http://creativecommons. fokussieren und fördern die schnelle  Entscheidungsfindung und erhöhen den Wissensstand des Entwicklungsteams.    Für einen einmonatigen Sprint wird für dieses Meeting eine Time Box von 4 Stunden angesetzt. Er zeigt  allen Teilnehmern. Hierzu bringt der Scrum Master dem  Entwicklungsteam bei. Offered for license under the Attribution Share-Alike license of Creative Commons. die vom  Product Owner eingeladen werden. Das Daily Scrum  ist ein entscheidendes Meeting zur Überprüfung und Anpassung.  Für kürzere Sprints wird in der Regel ein kürzerer Zeitrahmen veranschlagt. ist das  Entwicklungsteam für die Durchführung zuständig. Der Scrum Master  kümmert sich um die Organisation des Meetings und die Vorbereitung der Teilnehmer. ob sich durch die Marktsituation oder den möglichen  Produkteinsatz neue Erkenntnisse über die wertvollsten nächsten Schritte ergeben haben. welche Probleme  aufgetaucht sind. bestehend aus dem Scrum Team und wichtigen Stakeholdern.org/licenses/by-sa/4.    Sprint Review    Am Ende eines Sprints wird ein Sprint Review abgehalten.     Daily Scrums verbessern die Kommunikation. machen andere Meetings überflüssig. den Wert des Produkts  steigernden Punkten. Er gibt bei Bedarf  eine aktualisierte Vorhersage eines Fertigstellungstermins.   Alle Teilnehmer erarbeiten gemeinsam. und wie es diese Probleme gelöst hat.    Das Sprint Review beinhaltet die folgenden Elemente:     Die Teilnehmer. Beim Sprint Review handelt es sich um ein informelles Meeting. Zusammen mit eventuellen Änderungen am Product Backlog während des Sprints  bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen. dass nur Mitglieder des Entwicklungsteams  am Daily Scrum aktiv teilnehmen. Die Vorführung des Inkrements ist als Anregung für Feedback und die Basis für die  Zusammenarbeit gedacht. so dass das Sprint  Review wertvollen Input für die kommenden Sprint Plannings liefert. und beantwortet Fragen zu dem  Inkrement.   Der Product Owner erklärt. wie sie das Meeting innerhalb der Time Box halten können.Während der Scrum Master dafür sorgt. Während des Sprint Reviews  beschäftigen sich das Scrum Team und die Stakeholder gemeinsam mit den Ergebnissen des  Sprints. wie es die 15‐minütige Time Box des Daily Scrums einhalten kann. was als nächstes zu tun ist.    Der Scrum Master sorgt für die Einhaltung der Regel. Page | 12  . accessible at http://creativecommons.

accessible at http://creativecommons.0/.org/licenses/by-sa/4.  Der Scrum Master bestärkt das Scrum Team darin. das die möglichen  Product Backlog‐Einträge für den kommenden Sprint enthält. um     zu überprüfen wie der vergangene Sprint in Bezug auf die beteiligten Personen. Budget. Auch wenn jederzeit  Verbesserungen eingeführt werden können. um Transparenz sowie Möglichkeiten  zur Überprüfung und Anpassung zu schaffen. Prozesse und Werkzeuge verlief. Aufgrund seiner Verantwortung für den Scrum Prozess nimmt der Scrum Master als  gleichberechtigtes Mitglied an der Sprint Retrospektive teil. In jeder Sprint Retrospektive erarbeitet das Scrum Team  Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Definition  of Done.Org and ScrumInc. Page | 13  . 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. Die in Scrum definierten Artefakte wurden speziell  ©2016 Scrum. um neue Chancen zu nutzen.    Sprint Retrospektive    Die Sprint Retrospektive bietet dem Scrum Team die Gelegenheit.    Die Sprint Retrospektive wird durchgeführt.org/licenses/by-sa/4. bietet die Sprint Retrospektive eine formelle  Gelegenheit.  Zum Ende der Sprint Retrospektive sollte das Scrum Team Verbesserungen für den kommenden  Sprint identifiziert haben. Die Umsetzung dieser Verbesserungen im nächsten Sprint ist die  Anpassungsleistung zur Selbstüberprüfung des Scrum Teams.   die wichtigsten gut gelaufenen Elemente und mögliche Verbesserungen zu identifizieren  und in eine Reihenfolge zu bringen. Er sorgt dafür. dass die Time Box eingehalten  wird.   Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog. Der Scrum Master sorgt dafür. Das Product Backlog kann auch  umfassend umgearbeitet werden. Anschließend werden Zeitplan.    Scrum Artefakte    Die Artefakte von Scrum repräsentieren Arbeit oder Wert. und   einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Scrum Teams zu  erstellen. für kürzere Sprints  ist das Meeting in der Regel kürzer. sich auf die Überprüfung und Anpassung zu fokussieren. seine Entwicklungsprozesse und ‐praktiken  innerhalb des Scrum Prozessrahmenwerks zu verbessern.     Sie findet zwischen dem Sprint Review und dem nächsten Sprint Planning statt. die potentiellen Eigenschaften sowie die  Markterwartungen für das nächste zu erwartende Produkt‐Release überprüft. sich selbst zu überprüfen und  einen Verbesserungsplan für den kommenden Sprint zu erstellen.  Beziehungen.0/legalcode and also described in summary form at http://creativecommons. um im kommenden Sprint effektiver  und befriedigender arbeiten zu können. Offered for license under the Attribution Share-Alike license of Creative Commons. Für einen  einmonatigen Sprint wird hierfür eine Time Box von drei Stunden angesetzt. dass das Meeting stattfindet  und alle Teilnehmer dessen Zweck verstehen.

 die Schätzung und den Wert. um für das Produkt klar herauszustellen. die  Reihenfolge. Anforderungen  werden nie aufhören. Das  Scrum Team bestimmt. 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. um die anstehende Arbeit am Produkt zu beschreiben.org/licenses/by-sa/4. was  es braucht. die die Änderungen an dem Produkt in zukünftigen Releases  ausmachen. Der Product Owner ist  für das Product Backlog. Während seiner ersten  Entwicklungsschritte zeigt es nur die anfangs bekannten und am besten verstandenen  Anforderungen auf. dessen Wertsteigerung  sowie durch das Feedback des Marktes zu einer längeren. dass sie die Transparenz der wesentlichen Informationen maximieren. Schätzungen erstellt. Marktbedingungen oder der Technologie können  Änderungen am Product Backlog nach sich ziehen.    Als Verfeinerung [Refinement] des Product Backlogs wird der Vorgang angesehen. Funktionalitäten. seine Inhalte. Das Product Backlog entwickelt sich mit dem Produkt und dessen Einsatz  weiter. Page | 14  . Sie sollte  normalerweise nicht mehr als 10% der Kapazität des Entwicklungsteams beanspruchen.0/legalcode and also described in summary form at http://creativecommons. in dem der  Product Owner und das Entwicklungsteam gemeinsam die Product Backlog‐Einträge detaillieren. In diesem Fall  kann ein Gruppierungsattribut für die Product Backlog‐Einträge verwendet werden. Die Product Backlog‐ ©2016 Scrum. Ein Product Backlog‐Eintrag enthält als Attribute eine Beschreibung. accessible at http://creativecommons. desto weniger Details sind bekannt. den Zugriff darauf und die Reihenfolge der Einträge  verantwortlich.  Bei der Verfeinerung des Product Backlogs werden die Einträge begutachtet und revidiert. Es ist dynamisch. sich zu ändern. Der  Product Owner kann jedoch jederzeit die Einträge im Product Backlog aktualisieren oder  aktualisieren lassen. Daher ist das Product Backlog ein lebendes Artefakt. Das Product Backlog existiert so lange wie das dazugehörige  Produkt. um für alle  ein gleiches Verständnis über das Artefakt zu schaffen.    Product Backlog    Das Product Backlog ist eine geordnete Liste von allem.  Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt.    Im Product Backlog werden alle Features. um seiner Aufgabe angemessen zu sein.    Höher angeordnete Product Backlog‐Einträge sind generell klarer und weisen mehr Details auf  als niedrigere. Ein Product Backlog ist niemals vollständig.0/. es passt sich konstant an.  Änderungen an den Geschäftsanforderungen. was in dem Produkt enthalten sein kann. Präzisere Schätzungen entstehen auf der Basis von größerer Klarheit und  Detailtiefe ‐ je niedriger der Rang. Dann wird ein einziges  Product Backlog benutzt. Verbesserungen und  Fehlerbehebungen aufgelistet. Die Verfeinerung ist ein kontinuierlicher Prozess. Offered for license under the Attribution Share-Alike license of Creative Commons.Org and ScrumInc.    Häufig arbeiten mehrere Scrum Teams gemeinsam an einem Produkt.so entworfen. im Wettbewerb zu bestehen und den  erforderlichen Nutzen zu bieten. in dem  Details zu Einträgen hinzugefügt. ausführlicheren Liste.    Das Product Backlog entwickelt sich mit dem Einsatz eines Produktes. wann und wie diese Verfeinerungsarbeit erfolgt.org/licenses/by-sa/4. oder die Reihenfolge der Einträge im  Product Backlog bestimmt werden.

Org and ScrumInc. die auch die  Arbeit erledigen werden. allerdings ersetzen sie nicht die  Wichtigkeit des empirischen Vorgehens. Die Product Backlog‐Einträge. accessible at http://creativecommons. das Sprint Backlog entwickelt sich so während des Sprints. werden sie vom Entwicklungsteam zum Sprint Backlog  hinzugefügt. mit denen sich das Entwicklungsteam im kommenden Sprint beschäftigen soll.  um diese Funktionalität in einem fertigen – „Done“ ‐ Inkrement zu liefern. Der  Product Owner vermerkt diese gesamte verbleibende Arbeit mindestens zu jedem Sprint  Review. für die das der Fall ist. um den Fortschritt innerhalb des Sprints  im Daily Scrum erkennen zu können. sowie über die erforderliche Arbeit. Offered for license under the Attribution Share-Alike license of Creative Commons. Er vergleicht diesen Betrag mit der verbleibenden Arbeit in früheren Sprint Reviews.    Fortschrittskontrolle in Richtung eines Ziels    Die verbleibende Arbeit zur Erreichung eines Ziels kann jederzeit aufsummiert werden. Der Product Owner kann das  Entwicklungsteam dahingehend beeinflussen. 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. Diese Information  wird allen Stakeholdern präsentiert. um das Sprint‐Ziel zu erreichen. wie Burndown‐ oder  Burnupdiagramme.    Sprint Backlog     Das Sprint Backlog ist die Menge der für den Sprint ausgewählten Product Backlog‐Einträge.0/. dass jeder von ihnen innerhalb der Time Box des Sprints auf "Done" gebracht  werden kann. Wenn sich Bestandteile des Plans als unnötig erweisen. Das Sprint Backlog ist eine Prognose des Entwicklungsteams darüber. Nur was geschehen ist. während das Entwicklungsteam den Plan abarbeitet und mehr über die noch benötigten  Schritte zur Erreichung des Sprint‐Ziels lernt. Ein  Product Backlog‐Eintrag entwickelt diesen Transparenzgrad in der Regel durch die oben  beschriebenen Verfeinerungs‐Aktivitäten. Diese haben sich als nützlich erwiesen.    Das Entwicklungsteam ist für alle Schätzungen verantwortlich.Einträge. Page | 15  . In komplexen Umgebungen lassen sich zukünftige  Ereignisse nicht vorherbestimmen. gibt Anhaltspunkte für die  zukunftsgerichtete Entscheidungsfindung. um  den Fortschritt der Arbeiten im Verhältnis zur restlichen Zeit zu begutachten. wird die Schätzung  der verbleibenden Arbeit aktualisiert.    Das Sprint Backlog ist ein ausreichend detaillierter Plan.    Wenn weitere Arbeiten erforderlich sind. die das Entwicklungsteam für notwendig  erachtet.0/legalcode and also described in summary form at http://creativecommons.  ergänzt um den Plan für die Lieferung des Produkt‐Inkrements sowie zur Erfüllung des Sprint‐ Ziels. Diese Entwicklung  erfolgt. Das Entwicklungsteam passt das Sprint Backlog während  des Sprints an. werden als "Ready"  angesehen ‐ bereit für die Auswahl durch das Entwicklungsteam in einem Sprint Planning. werden  so weit verfeinert.  ©2016 Scrum. dass er ihm beim Verständnis der Einträge hilft  oder Kompromisse eingeht. Die endgültige Schätzung erfolgt immer von denen.org/licenses/by-sa/4.org/licenses/by-sa/4.    Das Sprint Backlog macht die gesamte Arbeit sichtbar.    Zur Fortschrittsprognose werden diverse Planungspraktiken eingesetzt. welche  Funktionalität im nächsten Inkrement enthalten sein wird. Wenn eine Arbeit durchgeführt wird oder abgeschlossen wurde.

 die bestmöglichen Praktiken zu finden und anzuwenden. um die Wahrscheinlichkeit.    Definition of Done    Es müssen alle verstehen. die Erkennung von Mustern. Es gibt  Methoden für den Umgang mit fehlender Transparenz.    Inkrement    Das Inkrement ist das Ergebnis aus allen in einem Sprint fertiggestellten Product Backlog‐ Einträgen und dem Resultat der Inkremente aller früheren Sprints.  sichtbar zu machen. sie ist ein Weg.Org and ScrumInc. und die Erkennung  von Abweichungen zwischen den erwarteten und den tatsächlichen Resultaten auf. Nur das Entwicklungsteam kann sein Sprint Backlog während des Sprints  ändern.    Überwachung des Sprint‐Fortschritts  Zu jedem Zeitpunkt im Sprint kann die gesamte verbleibende Arbeit an den Sprint Backlog‐ Einträgen aufsummiert werden. wenn vollständige Transparenz  nicht gewährleistet werden kann. den es  zu beschreiten gilt. Bei einer unvollständigen Transparenz können Entscheidungen auf Sand gebaut  sein.org/licenses/by-sa/4.    Der Scrum Master muss mit dem Product Owner. Diese Arbeit bedeutet zumeist Lernen. Wert kann gemindert und das Risiko erhöht werden. Entscheidungen zur Wertoptimierung und Risikokontrolle  werden auf der Basis des festgestellten Zustands der Artefakte vorgenommen. Es muss auch dann im einsatzfähigen Zustand sein. Offered for license under the Attribution Share-Alike license of Creative Commons.0/legalcode and also described in summary form at http://creativecommons. Das Sprint Backlog ist ein hochgradig sichtbares Echtzeit‐Abbild der Arbeit. die das  Entwicklungsteam plant.    Transparenz der Artefakte    Scrum basiert auf Transparenz. mit dem Scrum Team und der Organisation an der  Verbesserung der Transparenz der Artefakte zu arbeiten. intensives Zuhören. accessible at http://creativecommons. das Sprint‐Ziel zu erreichen.0/. ob die Artefakte wirklich vollkommen transparent sind. Diese  Entscheidungen haben in dem Maß eine solide Basis. Page | 16  . Obwohl sich dies erheblich von Scrum Team zu  ©2016 Scrum. Transparenz fällt einem nicht in den Schoß. Das Entwicklungsteam verfolgt diese gesamte Restarbeit  mindestens zu jedem Daily Scrum. während des Sprints zu erreichen. 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. Durch die Nachverfolgung der verbleibenden Arbeit während des Sprints  kann das Entwicklungsteam seinen Fortschritt steuern. in dem die Transparenz der Artefakte  umfassend ist. Ein Scrum Master spürt mangelnde Transparenz durch die  Überprüfung der Artefakte. sobald ein Product Backlog‐Eintrag oder ein  Produkt‐Inkrement als „Done“ bezeichnet wird. Am Ende eines Sprints muss  das neue Inkrement "Done" sein. das heißt es muss in einem verwendbaren Zustand sein und  die Definition of Done des Teams erfüllen. der Scrum Master muss jedem dabei  helfen. Es gehört einzig und allein dem  Entwicklungsteam. dem Entwicklungsteam und anderen  Beteiligten herausfinden.  wenn der Product Owner es aktuell noch gar nicht ausliefern will.     Die Aufgabe des Scrum Masters ist es.  Überzeugen und Verändern. was „Done“ bedeutet.org/licenses/by-sa/4.werden sie entfernt.

 Wenn "Done" für ein Inkrement nicht Teil der Konvention  der Entwicklungsorganisation ist.org/licenses/by-sa/4. wie viele Product  Backlog‐Einträge es während des Sprint Plannings selektieren kann. Dieses  Inkrement ist vollständig verwendbar.  um strengere Kriterien für eine höhere Qualität sicherzustellen. die der aktuellen  Definition of Done des Scrum Teams entsprechen. es zu releasen. Ereignisse  und Regeln von Scrum sind unveränderlich. Wenn die Definition of Done für ein Inkrement Teil der  Konventionen. sowie Ken  ©2016 Scrum. Standards oder Richtlinien der Entwicklungsorganisation ist. Der Zweck eines jeden  Sprints ist es. Scrum existiert nur in seiner Gesamtheit und  funktioniert sehr gut als Container für andere Techniken. Es ist zwar möglich. müssen alle Teammitglieder ein gemeinsames Verständnis davon  haben wann Arbeit fertig ist. Wenn es mehrere Scrum Teams gibt. Methoden und Praktiken. Artefakte. Inkremente potentiell auslieferbarer Funktionalität zu liefern.: Das heißt nicht. Offered for license under the Attribution Share-Alike license of Creative Commons. Dies erfolgt durch die Definition  of Done des Scrum Teams und wird dazu verwendet festzustellen. die zu Scrum beigetragen haben. dass sie ihre jeweilige Definition of Done erweitern. dass Product  Owner und Scrum Master nicht eingebunden werden]. um  sicherzustellen. die für Scrum in seinen ersten zehn Jahren von besonderer Bedeutung  waren.  Jedes Inkrement ist additiv zu allen früheren Inkrementen und gründlich getestet. die  am selben System‐ oder Produktrelease arbeiten.0/legalcode and also described in summary form at http://creativecommons. Page | 17  .org/licenses/by-sa/4. Übers.    Entwicklungsteams liefern jeden Sprint ein Inkrement an Produktfunktionalität.Scrum Team unterscheidet.0/. welcher mit Jeff McKenna arbeitete. d. müssen alle Scrum  Teams diese als Minimalziel befolgen.    Danksagungen    Menschen    Von den tausenden Menschen.Org and ScrumInc. sollten wir diejenigen  besonders hervorheben. 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. so dass der Product Owner sich jederzeit dazu  entscheiden kann. dass alle Inkremente gemeinsam funktionieren. nur Teile von Scrum einzusetzen  ‐ das Ergebnis ist dann aber nicht Scrum. müssen alle Entwicklungsteams aller Scrum  Teams gemeinsam eine Definition of Done erstellen. wann die Arbeit an einem  Produkt‐Inkrement fertig ist. muss das Entwicklungsteam des Scrum Teams eine für das  Produkt geeignete Definition of Done formulieren [Anm. Jedes einzelne Produkt oder  System sollte eine Definition of Done haben.    Die gleiche Definition leitet das Entwicklungsteam bei der Entscheidung. accessible at http://creativecommons.    Von gereiften Scrum Teams wird erwartet. Am Anfang standen Jeff Sutherland.    Schlussbemerkung    Scrum ist kostenlos und wird in Form dieses Guides angeboten. um Transparenz zu gewährleisten. welche den Standard für jegliche daran  durchgeführte Arbeit darstellt. Die Rollen.

 Ohne deren Hilfe wäre Scrum nicht so ausgefeilt. die das Rahmenwerk von Scrum ergänzen. Wolfgang Wiedenroth  2013: Jan Gretschuskin.org/licenses/by-sa/4.7:    Ergänzung des Abschnitts zum Thema Scrum Werte.    Übersetzung  Dieser Guide wurde von der englischen Originalversion.org/licenses/by-sa/4. Offered for license under the Attribution Share-Alike license of Creative Commons. accessible at http://creativecommons..Schwaber. Diese Präsentation dokumentierte im Kern die Erkenntnisse. Sabrina Roos. Damit lassen sich die Produktivität.  Version 1.    Die Geschichte von Scrum kann man heute schon als recht lang ansehen. Page | 18  . bereitgestellt von Ken Schwaber und  Jeff Sutherland. Harald Schlindwein    Änderungshistorie  Version 1. Pascal Naujoks. Ulf Schneider. so wie es seit über 20 Jahren von Jeff Sutherland und Ken  Schwaber konzipiert und weiterentwickelt wird. 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. die  Ken und Jeff in den vorher vergangenen Jahren bei der Anwendung von Scrum gewonnen  hatten.  Inc. Dominik Maximini. Hierzu beigetragen haben:  2011: Dominik Maximini. Boris Steiner. die Kreativität und der Stolz auf das Erreichte beständig erhöhen.1 bis 1.Org and ScrumInc. Andreas Schliep.6:  Kleine Fehlerkorrekturen bzgl. Sprachliche  Überarbeitung einzelner Sätze. Viele weitere haben in  den folgenden Jahren einen Beitrag geleistet.  Version 1. Pascal Naujoks.  Ralph Jocham.  der Wert.0/legalcode and also described in summary form at http://creativecommons.0:      Komplette Neuübersetzung des Scrum Guides. Andreas Schliep. Dominik Maximini. Prozesse  und Einsichten.    ©2016 Scrum.0/. möchten wir hier Individual. Patrick Koglin.    Historie    Ken Schwaber und Jeff Sutherland haben Scrum gemeinsam zum ersten Mal auf der OOPSLA  Konferenz 1995 präsentiert. an denen Scrum ausprobiert und verfeinert wurde. übersetzt. Andere Quellen liefern Ihnen Modelle. Fidelity Investments und IDX (heute GE Medical) hervorheben. welcher mit Mike Smith und Chris Martin zusammenarbeitete.  wie es heute ist.    Der Scrum Guide dokumentiert Scrum. Zur Würdigung der  ersten Orte.  Wolfgang Wiedenroth  2016: Jan Gretschuskin. Rechtschreibung und Verständlichkeit. Wolf Dieter Moggert. Jürgen Halstenberg.

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. Ein Abschnitt zu den Werten von Scrum. Sie verpflichten sich persönlich dazu.Org and ScrumInc. Page | 19  .org/licenses/by-sa/4. Fokus. offen mit allen Belangen ihrer Arbeit und den damit verbundenen  Herausforderungen umzugehen.org/licenses/by-sa/4. Offenheit und Respekt durch das  Scrum Team verkörpert und gelebt werden. werden die Scrum‐Säulen Transparenz.0/legalcode and also described in summary form at http://creativecommons. Die Mitglieder des Scrum Teams haben den Mut. Jeder fokussiert sich auf die  Arbeit im Sprint und die Ziele des Scrum Teams. Mitglieder von Scrum Teams respektieren sich  gegenseitig als fähige. Rollen und Artefakten arbeiten. Mut. accessible at http://creativecommons. Offered for license under the Attribution Share-Alike license of Creative Commons.      ©2016 Scrum. Das Scrum Team und seine Stakeholder  sind sich einig. das  Richtige zu tun und an schwierigen Problemen zu arbeiten.    Wenn die Werte Selbstverpflichtung.  indem sie mit den Scrum Ereignissen.  Überprüfung und Anpassung lebendig und bauen bei allen Beteiligten Vertrauen  zueinander auf. die Ziele  des Scrum Teams zu erreichen. dass alle Beteiligten kompetenter bei  der Erfüllung dieser fünf Werte werden.Änderungen im Scrum Guide 2016 im Vergleich zur Version von  2013  1.    Der erfolgreiche Einsatz von Scrum beruht darauf. eigenverantwortliche Individuen. Die Mitglieder des Scrum Teams lernen und erforschen diese Werte.