Der Scrum Guide - die Regeln für Scrum

Der Scrum Guide kennt die Regeln für Scrum. Er ist damit deine Bibel und enthält alles, was du wissen musst. Aber er lässt eines offen: die konkrete Anwendung. Die findest du bei mir und meinem Service für dich.

Rollen

Artefakte

Events

Im Scrum Guide findest du die Grundlagen, die du brauchst um Scrum erfolgreich anwenden zu können. Dort findest du die Basics, die du beherrschen musst. Mit 3 Rollen, 3 Artefakten und 5 Events enthält der Scrum Guide fokussiert alles nötige, was du brauchst, um komplexe Produkte zu entwickeln.

Der Scrum Guide in deutsch

Für die Zielgruppe Deutschland gibt es - ähnlich zu vielen anderen Sprache - eine Version des Scrum Guides auf deutsch. Diese wird von einer Community übersetzt.

Scrum Guide deutsch

Scrum Guide PDF

Du kannst dir den Scrum Guide in deutsch bequem von der Webseite scrumguides.org herunterladen und in Ruhe studieren.

Kostenloser Download

Das aktuelle Dokument steht dir kostenlos zur Verfügung. Mit einem einfachen Klick (2017 direkt hier) steht dir das PDF zur Verfügung.

Aktualisierung

Das Dokument wird aktualisiert (z.B. Scrum Guide 2020) und immer aktuell gehalten. Durch die Fokussierung auf das Wichtigste finden nur wenige Aktualisierungen statt.

Theorie

Scrum ist einfach (nur wenige Seiten zu lesen), aber nicht leicht (in der praktischen Umsetzung). Ich helfe dir gerne bei der Praxis.

Historie von Scrum 

Im Folgenden findest du die Geschichte von Scrum und dem Scrum Guide. Ein wahrlich fantastische Reise in ein faszinierende Framework, was viel in der Entwicklung von Produkten geändert hat.

Der Scrum Guide heute

6

Versionen

2010

1. Version

25

Anzahl Seiten deutsch

19

Anzahl Seiten englisch

Wir gehen weit zurück ins Jahr 1986 und zu einem Paper "The New New New Product Development Game". Werden dann die verschiedenen Stationen von Scrum genauer beleuchten und alle Download Quellen zu weiterführenden Material betrachten.

1986

The New New Product Development Game

Der Ursprung des Scrum Guides liegt weit zurück. Im Jahr 1986 haben die zwei Japaner Hirotaka Takeuchi und Ikujiro Nonaka in ihrem Artikel in der Harvard Business Review den Begriff "Scrum" in ihrem Paper "The New New New Product Development Game" benutzt. Er tauchte im Zusammenhang mit der Produktentwicklung auf. Und spannend, nicht im reinen Softwarezusammenhang - eine Aussage, die sich bis heute immer noch hartnäckig hält. Auch wenn damals Scrum tatsächlich auf Rugby bezogen war und bis heute noch einige Parallelen aufweist, hat sich die Geschichte weiterentwickelt.

 New New Product Development Game bei HBR ansehen

1995

OOPSLA - Object-Oriented Programming, Systems, Languages & Applications

Jeff Sutherland und Ken Schwaber haben 1995 auf der OOPSLA einen Vortrag gehalten und Scrum war das Thema. Sie verwendeten als Grundlage das oben genannte "The New New New Product Development Game" als Grundlage und beschrieben ihre Erfahrungen mit Scrum seit der frühen 90er. Seit 1995 sind nach wie vor viele Dinge von damals fester Bestandteil von Scrum und dem Scrum Guide. Hier entstand dann auch der Zusammenhang zwischen Scrum und der Software!

 Download OOPSLA - Object-Oriented Programming, Systems, Languages & Applications

1998

SCRUM: An extension pattern language for hyperproductive software development

SCRUM: Eine Erweiterungsmustersprache für die hyperproduktive Software-Entwicklung
1998 veröffentlichten Mike Beedle, Martine Devos, Yonat Sharon, Jeff Sutherland und Ken Schwaber SCRUM: Eine Erweiterungsmustersprache für die hyperproduktive Softwareentwicklung. "Dieses Papier von 1998 galt als das erste, das Scrum als eine Reihe von (benannten) Praktiken (nicht nur Rollen, Artefakte und Zeremonien/Events) beschreibt" - Brad Appleton. Der Scrum Master wird zum ersten Mal erwähnt, als Teamleiter und Entferner von "Blockaden".

 Download SCRUM: An extension pattern language for hyperproductive software development 

2001

Agiles Manifest

Das Manifest für die Entwicklung agiler Software muss Teil dieser Liste sein. Scrum hat dieses Manifest beeinflusst und das Manifest hat Scrum beeinflusst. Ein Schlüsselbeispiel ist, dass Scrum in den kommenden Jahren ein neues Ereignis einführte: die Retrospektive:

Fun Story: Wie Jeff selbst gerne erzählt, hat sich die Bedeutung des Namens wie folgt hergeleitet: Eigentlich sollte das agile Manifest zuerst adaptive Manifest heißen. Da Jim Highsmith aber schon mit Adaptive Software Development einen Begriff geprägt hatte, wurde ein neuer Name gewählt - nicht, dass der Kollege das ganze Business bekommen hätte ;-)

 Webseite Agile Manifest aufrufen

2001

Erstes Scrum Buch

Im Jahr 2001 veröffentlichten Ken Schwaber und Mike Beedle das Buch "Agile Software-Entwicklung mit Scrum". Dieses Buch ist sehr anschaulich über zahlreiche Scrum-Praktiken, insbesondere über die Rolle des Scrum-Masters. Damit gab es nun auch die erste Literatur, das Buch ist immer noch zu bekommen, zum Beispiel bei Amazon

 Buch bei Amazon ansehen

2003

Artikel "Was ist Scrum?"

Das Scrum 2003-Papier von Ken Schwaber kann als eine nächste Inkrementierung der Scrum-Definition betrachtet werden und stellt den Product Owner vor.

 Download "what is Scrum?"

2004

Agile Project Management with Scrum

Dieses Buch liest sich als ein "How to use Scrum", aber es erklärt auch die Theorie, die Rollen, den Ablauf und die Artefakte von Scrum, wie es 2004 definiert wurde.

 Buch bei Amazon ansehen

2004

User Stories applied

Im Jahr 2004 veröffentlichte Mike Cohn sein Buch 'User Stories Applied'. Während dieses Buch in erster Linie ein Leitfaden für den Umgang mit User Stories in einer agilen Umgebung ist, enthält es auch ein Kapitel zur Erläuterung von Scrum. Für die - zwar nicht verpflichtend im Scrum Guide genannten - User Stories und die Technik des Planning Pokers, hatte dieses Buch einen hohen Einfluss. 

 Buch bei Amazon ansehen

2009

Succeeding with Agile: Software Development using Scrum

Im Jahr 2009 veröffentlichte Mike Cohn das Buch "Succeeding with Agile: Software Development using Scrum". Mike Cohn taucht tief in die Welt von Scrum ein, wobei er das Buch "Agile Software-Entwicklung mit Scrum" aus dem Jahr 2001 und das Papier von Ken Schwaber aus dem Jahr 2003 als Referenzen und als Quelle verwendet. Aber auch dieses Buch war sehr einflussreich und somit ausschlaggebend für die Einführung von Scrum.

 Buch bei Amazon ansehen

2010

Erste Version des Scrum Guides

Der erste Scrum-Guide wurde 2010 veröffentlicht und ist seitdem die richtige Quelle für Scrum. Der Scrum Guide ist in deutsch und vielen anderen Sprachen verfügbar. Er wird durch die Community übersetzt und hat seit diesem Jahre einige an Aktualisierungen erhalten. Diese sind weiter unten dann jeweils einzeln vorgestellt.

 Scrum Guides Webseite

Änderungen 2010 bis 2020

Die Änderungen über die Jahre 2010 bis 2020 findest du auf der Review Seite des Scrum Guides. Die wichtigsten Änderungen habe ich für dich hier kurz und knackig zusammengefasst. Du findest jeweils das Jahr der Veröffentlichung des Scrum Guides.

1. Version

2010

  • Erste Version des Scrum Guides
  • List Element
  • List Element

2. Version

2011

  • Fokussierung durch Entfernen von Referenzen und Tipps
  • Änderungen beim Commitment des Entwicklungsteam zur Arbeit im Sprint 
  • Entfernung von Release Planung und Burndown Chart als notwendige Elemente
  • Sprint Plan als Forecast eingeführt

3. Version

2011

  • Kleinere textuelle Anpassungen

4. Version

2013

  • Grooming zu Refinement
  • Sprint Planung 1 und 2 als ein Event
  • Daily Scrum Fragen
  • Stärkerer Fokus auf Wert im Scrum Guide

5. Version

2016

  • Scrum Werte eingefügt
  • List Element
  • List Element

6. Version

2017

  • Daily Scrum Fragen Änderungen
  • KVP Elemente im Sprint Backlog
  • Nutzung von Scrum

Änderungen in deutsch

Im Folgenden habe ich die Änderungen am Scrum Guide übersetzt und stelle sie hier bereit. Wenn dich dich englische Beschreibung interessiert, dann schaue einfach unter der Review Seite nach.

Jahr 2017 zu 2020 (18.11.20 - 25 Jahre Scrum Guide)

weniger präskriptiv

  • Im Laufe der Jahre wurde der Scrum-Guide immer präskriptiver. Die Version 2020 zielte darauf ab, Scrum wieder zu einem minimal ausreichenden Rahmenwerk zu machen, indem die präskriptive Sprache entfernt oder aufgeweicht wurde. z.B. wurden Daily Scrum-Fragen entfernt, die Sprache um PBI-Attribute aufgeweicht, die Sprache um Retro-Items im Sprint Backlog aufgeweicht, der Sprint Abbruch verkürzt und vieles mehr.

Ein Team, fokussiert auf ein Produkt

  • Ziel war es, das Konzept eines separaten Teams innerhalb eines Teams zu beseitigen, das zu einem "Stellvertreter"- oder "wir und sie"-Verhalten zwischen dem PO- und dem Dev-Team geführt hat. Es gibt jetzt nur noch ein Scrum-Team, das sich auf dasselbe Ziel konzentriert und drei verschiedene Arten von Verantwortlichkeiten hat: PO, SM und Entwickler.

Einführung des Produktziels

  • Der Scrum-Guide 2020 führt das Konzept eines Produktziels ein, um das Scrum-Team auf ein größeres wertvolles Ziel auszurichten. Jeder Sprint sollte das Produkt näher an das übergeordnete Produktziel bringen.

Eine Heimat für Sprint-Ziel, Definition des Erreichten und Produktziel

  • Frühere Scrum Guides beschrieben Sprint-Ziel und Definition of Done, ohne ihnen wirklich eine Identität zu geben. Sie waren nicht ganz Artefakte, sondern hingen irgendwie an Artefakten. Mit der Hinzufügung von "Produktziel" bietet die Version 2020 mehr Klarheit darüber. Jedes der drei Artefakte enthält nun "Verpflichtungen" gegenüber den Artefakten. Beim Product Backlog handelt es sich um das Produktziel, beim Sprint Backlog um das Sprint-Ziel und beim Increment um die Definition von Done (jetzt ohne " ") . Sie existieren, um Transparenz und Fokus auf den Fortschritt jedes Artefakts zu bringen.

Selbstverwaltung über Selbstorganisation

  • Frühere Scrum Guides bezeichneten Entwicklungsteams als selbstorganisierend, indem sie auswählen, wer und wie sie arbeiten soll. Mit einem stärkeren Fokus auf das Scrum-Team betont die Version 2020 ein selbstverwaltendes Scrum-Team, das wählt, wer, wie und woran es arbeiten soll.

Drei Sprintplanungsthemen

  • Zusätzlich zu den Sprint-Planning-Themen "Was" und "Wie" legt der 2020 Scrum Guide den Schwerpunkt auf ein drittes Thema, "Warum", das sich auf das Sprint-Ziel bezieht.

Allgemeine Vereinfachung der Sprache für ein breiteres Publikum

  • Der Scrum-Guide 2020 hat einen Schwerpunkt auf die Eliminierung redundanter und komplexer Aussagen sowie die Beseitigung aller verbleibenden Rückschlüsse auf die IT-Arbeit (z.B. Test, System, Design, Anforderung, etc.) gelegt. Der Scrum-Guide umfasst jetzt weniger als 13 Seiten.

Jahr 2016 zu 2017

Abschnitt über die Anwendung von Scrum hinzugefügt

  • Erforschung und Identifizierung von lebensfähigen Märkten, Technologien und Produktfähigkeiten;
  • Produkte und Verbesserungen zu entwickeln;
  • Freigabe von Produkten und Verbesserungen, so oft wie möglich pro Tag;
  • Entwicklung und Aufrechterhaltung von Cloud- (online, sicher, on-demand) und anderen Betriebsumgebungen für die Produktnutzung; und
  • Produkte zu erhalten und zu erneuern.

Scrum wurde zur Entwicklung von Software, Hardware, eingebetteter Software, Netzwerken interagierender Funktionen, autonomen Fahrzeugen, Schulen, Regierung, Marketing, Verwaltung des Betriebs von Organisationen und fast allem, was wir in unserem täglichen Leben als Individuen und Gesellschaften verwenden, eingesetzt.

Da die Technologie-, Markt- und Umweltkomplexität und ihre Wechselwirkungen rapide zugenommen haben, wird der Nutzen von Scrum im Umgang mit der Komplexität täglich unter Beweis gestellt. Scrum erwies sich als besonders effektiv beim iterativen und inkrementellen Wissenstransfer. Scrum wird heute weitgehend für Produkte, Dienstleistungen und das Management der Mutterorganisation eingesetzt. Die Essenz von Scrum ist ein kleines Team von Menschen. Das einzelne Team ist sehr flexibel und anpassungsfähig. Diese Stärken wirken weiterhin in einzelnen, mehreren, vielen und Netzwerken von Teams, die die Arbeit und die Arbeitsprodukte von Tausenden von Menschen entwickeln, freigeben, betreiben und aufrechterhalten. Sie arbeiten zusammen und interagieren durch ausgeklügelte Entwicklungsarchitekturen und Zielveröffentlichungsumgebungen.

Wenn die Worte "entwickeln" und "Entwicklung" im Scrum-Guide verwendet werden, beziehen sie sich auf komplexe Arbeit, wie die oben genannten Arten.

Der Wortlaut im Abschnitt Der Scrum-Master wurde geändert, um die Rolle besser verständlich zu machen. Der Text lautet jetzt

  • Der Scrum Master ist für die Förderung und Unterstützung von Scrum, wie im Scrum Guide definiert, verantwortlich. Der Scrum Master tut dies, indem er jedem hilft, die Scrum-Theorie, Praktiken, Regeln und Werte von Scrum zu verstehen.
  • Der Scrum Master ist ein servant-leader für das Scrum Team. Der Scrum Master hilft denjenigen außerhalb des Scrum Teams zu verstehen, welche ihrer Interaktionen mit dem Scrum Team hilfreich sind und welche nicht. Der Scrum Master hilft allen, diese Interaktionen zu ändern, um den vom Scrum Team geschaffenen Wert zu maximieren.

Zum Abschnitt Scrum Master Service für den Product Owner hinzugefügt

  • Sicherstellen, dass Ziele, Umfang und Produktbereich von jedem im Scrum-Team so gut wie möglich verstanden werden.

Den ersten Absatz des Abschnitts "Daily Scrum" zum Lesen aktualisiert

  • Das Daily Scrum ist ein 15-minütiges, zeitlich begrenztes Ereignis für das Entwicklungsteam. Das Daily Scrum wird an jedem Tag des Sprints durchgeführt. Dabei plant das Entwicklungsteam die Arbeit für die nächsten 24 Stunden. Dadurch wird die Zusammenarbeit und Leistung des Teams optimiert, indem die Arbeit seit dem letzten Daily Scrum begutachtet und die Arbeit für den kommenden Sprint prognostiziert wird. Das Daily Scrum wird jeden Tag zur gleichen Zeit und am gleichen Ort abgehalten, um die Komplexität zu reduzieren.

Der Abschnitt über das Daily Scrum wurde aktualisiert, um Klarheit über die Ziele des Daily Scrum einschließlich dieses Textes zu schaffen

  • Die Struktur des Treffens wird vom Entwicklungsteam festgelegt und kann auf verschiedene Weise durchgeführt werden, wenn es sich auf Fortschritte in Richtung des Sprint-Ziels konzentriert. Einige Entwicklungsteams werden Fragen verwenden, andere werden eher diskussionsbasiert sein. Hier ist ein Beispiel dafür, was verwendet werden könnte:
  • Was habe ich gestern getan, das dem Entwicklungsteam geholfen hat, das Sprint-Ziel zu erreichen?
  • Was werde ich heute tun, um das Entwicklungsteam bei der Erreichung des Sprint-Ziels zu unterstützen?
  • Sehe ich ein Hindernis, das mich oder das Entwicklungsteam daran hindert, das Sprint-Ziel zu erreichen?

Mehr Klarheit über die ZeitSCHEIBEN / TIMEBOXEN

  • Mit den Wörtern "höchstens" werden alle Fragen gestrichen, bei denen die Time-Box für Veranstaltungen eine maximale Länge bedeutet, die aber auch kürzer sein könnte.

Dem Abschnitt Sprint Backlog hinzugefügt

  • Um eine kontinuierliche Verbesserung zu gewährleisten, enthält er mindestens eine Art und Weise, in der das Team mit hoher Priorität arbeitet, die in der vorherigen Rückblick-Sitzung festgelegt wurde.

Dem Abschnitt Inkrement wurde Klarheit hinzugefügt

  • Ein Inkrement ist ein Korpus von überprüfbarer, "erledigter" Arbeit, der die Empirie am Ende des Sprints unterstützt. Das Inkrement ist ein Schritt in Richtung einer Vision oder eines Ziels.

Jahr 2013 zu 2016

Ein Abschnitt über Scrum-Werte

  • Wenn die Werte Engagement, Mut, Fokus, Offenheit und Respekt vom Scrum-Team verkörpert und gelebt werden, werden die Scrum-Säulen Transparenz, Kontrolle und Anpassung lebendig und bauen Vertrauen für alle auf. Die Mitglieder des Scrum-Teams lernen und erforschen diese Werte, während sie mit den Scrum-Ereignissen, Rollen und Artefakten arbeiten.
  • Die erfolgreiche Anwendung von Scrum hängt davon ab, dass die Menschen diese fünf Werte immer besser leben können. Die Menschen setzen sich persönlich dafür ein, die Ziele des Scrum-Teams zu erreichen. Die Mitglieder des Scrum-Teams haben Mut, das Richtige zu tun und an schwierigen Problemen zu arbeiten. Jeder konzentriert sich auf die Arbeit des Sprints und die Ziele des Scrum-Teams. Das Scrum Team und seine Stakeholder sind sich einig, dass sie offen über die gesamte Arbeit und die Herausforderungen bei der Durchführung der Arbeit sind. Die Mitglieder des Scrum-Teams respektieren sich gegenseitig als fähige, unabhängige Menschen.

Jahr 2011 zu 2013

Ein Abschnitt über Artefakt-transparenz wurde hinzugefügt

  • Scrum setzt auf Transparenz. Entscheidungen zur Wertoptimierung und Risikokontrolle werden auf der Grundlage des wahrgenommenen Zustands der Artefakte getroffen. In dem Maße, in dem die Transparenz vollständig ist, haben diese Entscheidungen eine solide Grundlage. In dem Maße, in dem die Artefakte unvollständig transparent sind, können diese Entscheidungen fehlerhaft sein, der Wert kann abnehmen und das Risiko kann zunehmen.

Sprint Planning ist jetzt ein EVENT

  • Zwei Themen werden darin behandelt: Was kann in diesem Sprint getan werden, und wie wird die gewählte Arbeit durchgeführt werden. Nachdem das Entwicklungsteam die Product Backlog Items für den Sprint prognostiziert hat, erstellt das Scrum Team ein Sprint-Ziel. Das Sprint-Ziel schafft Kohärenz in der Arbeit des Entwicklungsteams, die in getrennten Initiativen ohne ein gemeinsames Ziel nicht vorhanden wäre. Beachte die formale Aufnahme eines Sprint-Ziels.

Das Product Backlog wird eher verfeinert als gepflegt

  • Die verfeinerten Elemente des Product Backlog sind transparent, gut genug verstanden und granular genug, um als Input für die Sprintplanung und für die Auswahl für den Sprint zu dienen. Product Backlog-Items mit dieser Transparenz werden "Ready" genannt. Ready und Done sind zwei Zustände, die die Transparenz verstärken.

Scrum schreibt seine Veranstaltungen vor, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings, die nicht in Scrum definiert sind, zu minimieren.

  • Alle Ereignisse sind zeitgesteuerte Ereignisse, so dass jedes Ereignis eine maximale Dauer hat. Ein Sprint, als Container-Ereignis, hat eine feste Dauer, die nicht verkürzt oder verlängert werden kann. Die verbleibenden Ereignisse können immer dann enden, wenn der Zweck des Ereignisses erreicht ist; dabei ist sicherzustellen, dass eine angemessene Zeit aufgewendet wird, ohne dabei Verschwendung zuzulassen.

Die Bedeutung des Daily Scrum als Planungsereignis wird verstärkt

  • Zu oft wird es als ein Status-Ereignis angesehen. Das Entwicklungsteam sollte jeden Tag verstehen, wie es beabsichtigt, als selbstorganisierendes Team zusammenzuarbeiten, um das Sprint-Ziel zu erreichen und bis zum Ende des Sprints die erwartete Steigerung zu erreichen. Der Input für die Sitzung sollte sein, wie das Team das Sprint-Ziel erreicht; das Ergebnis sollte ein neuer oder überarbeiteter Plan sein, der die Bemühungen des Teams zur Erreichung des Sprint-Ziels optimiert. Zu diesem Zweck wurden die drei Fragen neu formuliert, um das Team gegenüber dem Einzelnen zu betonen:
  • Was habe ich gestern getan, das dem Entwicklungsteam geholfen hat, das Sprint-Ziel zu erreichen?
  • Was werde ich heute tun, um dem Entwicklungsteam zu helfen, das Sprint-Ziel zu erreichen?
  • Sehe ich ein Hindernis, das mich oder das Entwicklungsteam daran hindert, das Sprint-Ziel zu erreichen?

Das Konzept des Wertes wird verstärkt, um es in der Sprint-Review zu verwenden

  • Während des Sprint-Review arbeiten das Scrum-Team und die Stakeholder gemeinsam an dem, was im Sprint getan wurde. Auf dieser Grundlage und auf der Grundlage aller Änderungen am Product Backlog während des Sprints arbeiten die Teilnehmer gemeinsam an den nächsten Schritten, die zur Optimierung der Wertschöpfung unternommen werden können. 

Jahr 2010 zu 2011

Die Entwicklungsteams verpflichten sich nicht, die während einer Sprintplanungs-Sitzung geplanten Arbeiten abzuschließen

  • Das Entwicklungsteam erstellt eine Prognose der Arbeiten, von denen es glaubt, dass sie erledigt werden, aber diese Prognose wird sich ändern, wenn während des Sprints mehr bekannt wird.

Scrum schreibt kein Burn-down-Diagramm zur Überwachung des Fortschritts vor

  • Das Entwicklungsteam erstellt eine Prognose der Arbeiten, von denen es glaubt, dass sie erledigt werden, aber diese Prognose wird sich ändern, wenn während des Sprints mehr bekannt wird.

Scrum schreibt kein Burn-down-Diagramm zur Überwachung des Fortschritts vor. Scrum verlangt nur das

  • Die verbleibende Arbeit für einen Sprint wird summiert und täglich bekannt gemacht.
  • Die Tendenz, die Arbeit für einen Sprint abzuschließen, wird während des gesamten Sprints beibehalten.

Release Planung

  • Die Release-Planung ist eine wertvolle Sache bei der Verwendung von Scrum, wird aber von Scrum selbst nicht verlangt.

Das Sprint Backlog besteht aus den für den Sprint ausgewählten Product-Backlog-Elementen sowie einem Plan für deren Auslieferung

  • Es gibt kein erforderliches Konzept der "Sprint Backlog Items" mehr, obwohl diese Technik einen guten Plan machen kann. Ein sich selbst organisierendes Entwicklungsteam hat immer einen Plan.

Product Backlog

  • Das Product Backlog ist "geordnet" und nicht "priorisiert", was dem Product Owner Flexibilität bietet, um den Wert unter seinen oder ihren einzigartigen Umständen zu optimieren.

Backlog Grooming

  • Hinzu gekommen ist die Praxis des Product Backlog Groomings (später erst Refinement).

Tipps entfernt

  • Viele Tipps, optionale Praktiken und Techniken wurden entfernt.

Entwicklungsteam

  • Das Team von Personen, das die Arbeit zur Erstellung eines Inkrements ausführt, ist das Entwicklungsteam. Unabhängig von der Arbeit, die die einzelnen Teammitglieder leisten, werden sie als Entwickler bezeichnet.

Hinweise entfernt

  • Der Bezug auf "Chicken and Pigs" wurde entfernt.
  • Der Verweis auf unerledigte Arbeit wurde entfernt.

Inhalte des Scrum Guides

Wenn dich weitere tiefergehende Konzepte interessieren, dann schau doch in meinen Artikel nach, die ich zu diesem Thema veröffentliche.

Simple and easy.

Scrum Guide als Online Kurs?

Ich habe in meinem Online Kurs neben den Grundlagen des Scrum Guides, agilen Manifest noch viele weiterführende Konzepte integriert. Festige dein Wissen am besten jetzt sofort!

Jetzt direkt zum Kurs!

Über Sebastian Schneider

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

Kontakt
>