Scrum

Scrum ist ein leichtgewichtiges Rahmenwerk für Menschen, Teams und Organisationen um für komplexe Probleme Wert zu generieren.

Das Scrum-Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum-Theorie erforderlich sind.

Scrum macht die relative Wirksamkeit des aktuellen Managements, der Umgebung und der Arbeitstechniken sichtbar, so dass Verbesserungen vorgenommen werden können.

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.

Transparenz, Überprüfung und Anpassung

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.

Drei Arthefakte: Product Backlog, Sprint Backlog und Increment

Transparenz ermöglicht Ü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.

5 Scrum Events

Überprüfung ermöglicht 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.

Von einem Scrum Team wird erwartet, dass es sich in dem Moment anpasst, in dem es durch Überprüfung etwas Neues lernt.

Commitment, Fokus, Offenheit, Respekt und Mut

Commitment sich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen

Primärer Fokus liegt auf der Arbeit des Sprints / auf Ziele.

Das Scrum Team und dessen Stakeholder sind offen in Bezug auf die Arbeit und die Herausforderungen.

Die Mitglieder des Scrum Teams respektieren sich gegenseitig

Die Mitglieder des Scrum Teams haben den Mut, das Richtige zu tun: an schwierigen Problemen zu arbeiten.

Scrum Master, einem Product Owner und Developer

keine Teilteams oder Hierarchien

Teams managen sich selbst

10 oder weniger Personen

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 teilen.

Zusammenarbeit mit den Stakeholdern, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte.

Die Developer sind 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 Experten zur Verantwortung zu ziehen.

Rest variiert

Der Product Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.

Der Product Owner 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.

Kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren - bleibt aber ergebnisverantwortlich.

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

Damit der Product Owner Erfolg haben kann, muss die gesamte Organisation seine 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 Scrum Master ist ergebnisverantwortlich für die Einführung von Scrum - Hilft, die Scrum-Theorie und -Praxis zu verstehen.

Effektivität verbessern - Praktiken innerhalb des Scrum-Rahmenwerks zu verbessern.

Der Scrum Master 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.

Der Scrum Master dient dem Product Owner auf unterschiedliche Weise, unter anderem dadurch,

● bei der Suche nach Techniken zur effektiven Definition des Produkt-Ziels und zum ProductBacklog-Management zu helfen;

● dem Scrum Team dabei zu helfen, die Notwendigkeit klarer und prägnanter Product-BacklogEinträge zu verstehen;

● bei der Etablierung einer empirischen Produktplanung für ein komplexes Umfeld zu helfen; und

● die Zusammenarbeit mit Stakeholdern nach Wunsch oder Bedarf zu fördern (facilitate).

Der Scrum Master 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 beim Verständnis und bei der Umsetzung eines empirischen Ansatzes für komplexe Arbeit zu unterstützen; und

● Barrieren zwischen Stakeholdern und Scrum Teams zu beseitigen.

Jedes Event in Scrum ist eine formelle Gelegenheit, Scrum-Artefakte zu überprüfen und anzupassen.

Transparenz ermöglichen - ansonsten verpasst man die Gelegenheit, zu überprüfen und anzupassen.

Optimalerweise alle Events zur selben Zeit und am selben Ort abhalten, um die Komplexität zu reduzieren.

Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden.

Einem Monat oder weniger, um Konsistenz zu schaffen

Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective

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 Product Owner neu vereinbart werden, sobald mehr Erkenntnisse vorliegen.

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.

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

Für Plan mit auszuführenden Arbeiten für den Sprint.

Der Product Owner stellt sicher, dass die Teilnehmenden vorbereitet sind, die wichtigsten ProductBacklog-Einträge zu besprechen, und wie sie dem Produkt-Ziel zuzuordnen sind.

Warum ist dieser Sprint wertvoll? - Sprint-Ziel, warum der Sprint für die Stakeholder wertvoll ist.

Was kann in diesem Sprint abgeschlossen (Done) werden? Im Gespräch mit dem Product Owner wählen die Developer Einträge aus dem Product Backlog für Sprint aus. - ggf Verfeinern

Wie wird die ausgewählte Arbeit erledigt? - Für jeden ausgewählten Product-Backlog-Eintrag planen die Developer 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.

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.

Fortschritt in Richtung des Sprint-Ziels überprüfen und das Sprint Backlog bei Bedarf anpassen.

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

Falls der Product Owner oder der Scrum Master aktiv an Einträgen des Sprint Backlogs arbeitet, nimmt er als Developer teil

15-minütiges Event für die Developer des Scrum Teams - (bestenfalls)an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort abgehalten.

Ergebnis des Sprints zu überprüfen und künftige Anpassungen festlegen.

Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholdern vor, und die Fortschritte in Richtung des Produkt-Ziels werden diskutiert.

Während des Events überprüfen das Scrum Team und die Stakeholder, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat.

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

Zweck: 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.

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.

Bei einmonatigen Sprint auf maximal drei Stunden beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.

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 zu verstärken.

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.

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 Developer, die die Arbeit erledigen werden, sind für die Größenbestimmung umsetzungsverantwortlich. Der Product Owner kann die Developer beeinflussen, indem er dabei unterstützt, die Product-Backlog-Einträge zu verstehen und Kompromisse einzugehen.

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.

Wofür (Ziel) was (Einträge) wie (Plan für Increments) umgesetzt wird.

Das Sprint Backlog ist ein Plan von und für die Developer.

Sichtbares Echtzeitbild der Arbeit für Sprint

Folglich wird das Sprint Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde.

Das Sprint-Ziel ist die einzige Zielsetzung für den Sprint. Commitment der Developer.

Das Sprint-Ziel wird während des Sprint-Planning-Events erstellt und dann zum Sprint Backlog hinzugefügt.

Wenn sich herausstellt, dass die Arbeit von ihren Erwartungen abweicht, arbeiten sie mit dem Product Owner zusammen, um den Umfang des Sprint Backlogs innerhalb des Sprints zu verhandeln, ohne das Sprint-Ziel zu beeinflussen.

Ein Increment ist ein konkreter Schritt in Richtung des Produkt-Ziels. Jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren.

Ein Increment könnte auch schon vor Ende des Sprints an die Stakeholder geliefert werden.

Definition of Done erforderlich.

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.

Gemeinsames Verständnis darüber vermittelt, welche Arbeiten als Teil des Increments abgeschlossen wurden.

Definition of Done definiert, wann eine Aufgabe oder ein Produktinkrement als vollständig und bereit für die Auslieferung oder Präsentation betrachtet wird. (Grundsätze)

Akzeptanzkriterien definiert wann spezifische Karte für Produkt Owner als erledigt gilt.

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 müssen sich an die Definition of Done halten.

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

Das Scrum-Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum-Theorie erforderlich sind.

Scrum macht die relative Wirksamkeit des aktuellen Managements, der Umgebung und der Arbeitstechniken sichtbar, so dass Verbesserungen vorgenommen werden können.