heroische Führungskraft

Mentor

Sekretär..in

Coach

Team Boss

Durch Schulungsmaßnahmen (on the job)

Durch Governance mit entsprechenden negativen Konsequenzen bei Verstoß

Durch Coaching des Scrum Teams als Ganzes sowie von Individuen

Durch regelmäßige Berichte über Regelverstöße

Scrum Master

Product Owner

Developers

Scrum definiert genau 3 Artefakte: Product Backlog, Spint Backlog und Increment

Jedes Scrum Artefakt hat ein zugehöriges "Commitment"

Scrum definiert genau 3 Events

Alle in Scrum definierten Events sind timeboxed

Das Product Backlog ist eine fixe, geordnete Liste der Dinge, die zur Produktentwicklung/-verbesserung benötigt werden.

Der Product Backlog ist NICHT die einzige Quelle von Arbeit, die durch das Scrum Team zu erledigen ist.

Die Product Backlog Elemente werden im Refinement in kleinere, präzisere Elemente zerlegt und weiter definiert.

Das Produkt‐Ziel ist Teil des Product Backlogs und beschreibt das derzeit gültige (Produkt-)Ziel für das Scrum Team.

Das Sprint Backlog liefert drei Arten von Informationen bzgl. des Sprints: Wofür (ist der Sprint), Was (wollen wir umsetzen) und Wie (wollen wir es umsetzen).

Das Sprint Backlog ist für den anstehenden Sprint fix und darf nicht aktualisiert werden.

In einem konkreten Sprint Backlog können mehrere Sprintziele definiert sein.

Die Developer commiten sich darauf, alle für den Sprint ausgewählten Einträge des Produktbacklogs umzusetzen.

Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein.

Innerhalb eines Sprints soll genau ein Increment erstellt werden.

Das Increment wird im Rahmen des Sprint-Reviews durch den Produkt Owner abgenommen.

Die Definition of Done (DoD) ist eine formale Beschreibung des Ziel-Zustands des Increments.

Wenn ein Product‐Backlog‐Eintrag nicht der DoD entspricht, kann er weder released noch demonstriert (Review) werden.

Vor dem Sprint findet eine Sprint-Planung statt.

Zwischen Sprints kann eine Pause liegen um Dinge zu klären.

Während des Sprints werden keine Änderungen vorgenommen, die das Sprint‐Ziel gefährden würden.

Ein Sprint könnte abgebrochen werden, wenn das Sprint‐Ziel obsolet wird.

Während des Sprints kann der Scope (Inhalt und Umfang) geklärt und mit dem Product Owner neu vereinbart werden.

brechen die Developer den Sprint ab.

bricht der Product Owner den Sprint ab

arbeiten die Developer mit dem Product Owner zusammen, um unter Beibehaltung des Sprintziels den Umfang des Sprint Backlogs zu verhandeln.

Das Sprint Planning initiiert den Sprint, indem es u.a. die für den Sprint auszuführenden Arbeiten darlegt.

Der Productowner, der Scrum Master und die Developer können zu Beratungszwecken auch andere Personen zur Teilnahme am Sprint Planning einladen.

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

Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung der commiteten Produkt Backlog Einträge zu überprüfen.

Das Daily Scrum liefert die Grundlage für die Developer den Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu auf die Erfüllung des Sprint-Ziels auszurichten.

Das Daily Scrum ist die einzige Gelegenheit, bei der die Developer ihren Plan anpassen dürfen.

Das Daily Scrum dient dazu, dem Product Owner zu berichten, woran gearbeitet wird und welche Probleme es gibt.

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

Während des Sprint Reviews kann das Product Backlog

angepasst werden, um neue Möglichkeiten wahrzunehmen.

Das Sprint Review ist ein Arbeitstermin und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken.

Das Sprint Review ist das letzte Event des Sprints.

Es ist das wichtigste Event aus Sicht des Scrum Masters.

Die Sprint Retrospective schließt den Sprint ab.

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

Das Scrum Team identifiziert die hilfreichsten Änderungen, um seine Effektivität zu verbessern.

In einer komplexen Domäne kann auf die Durchführung von Sprint-Retrospektiven verzichtet werden.

Vergleichende/abstrakte Schätzungen sind i.d.R. schneller durchführbar als das Schätzen absoluter Größen.

Menschen fällt es viel leichter Dinge zueinander in Relation zu setzen als absolute Aussagen zu treffen.

Durch die Diskussion mit und zwischen den Developern über die User Storys bekommen die für die Umsetzung verantwortlichen Developer ein gemeinsames Verständnis von der Story.

Absolute Schätzungen unterstützen die empirische Prozesssteuerung, welche im komplexen Umfeldern empfehlenswert ist.

Komplexität

Aufwands

Dauer

Das Sprint Planning behandelt u.a. das Thema "WARUM ist dieser Sprint wertvoll?"

Das Sprint Planning behandelt u.a. das Thema

"WAS kann in diesem Sprint abgeschlossen (Done) werden?"

Das Sprint Planning behandelt u.a. das Thema

"WIE wird die ausgewählte Arbeit erledigt?"

Die im Sprint Planning getroffenen Aussagen dürfen im Sprint nicht mehr geändert werden.

User Stories sind primär eine Beschreibungsschablone zur Erstellung einer Spezifikation.

User Stories sind unvollständig bis sie mit den Developern im Dialog diskutiert wurden.

Es ist empfehlenswert auch aus der Sicht von Nicht-Nutzern (z.B. Architekten etc.) User Stories zu schreiben.

Sie müssen in einem Sprint umsetzbar sein.

Unabhängigkeit voneinander

Absolut lösungsunabhängig

verhandelbar und letztlich verhandelt

schätzbar

nicht zwingend in einem (1) Sprint umsetzbar (done)

müssen einen Wert liefern

Die Akzeptanzkriterien dienen der Abnahme durch die Stakeholder

klein (Umsetzbar in einem Sprint)

müssen testbar sein (Akzeptanzkriterien)

sind zwingend eine formale textuelle Beschreibung von Anforderungen

Bilden von Spikes

Zerlegen nach Schritten im Ablauf

Identifizieren von unterschiedlichen Interfaces

Schneiden entlang von architekturellen Schichten

Inkrementelles Abarbeiten von Akzeptanzkriterien

Schneiden entlang von Nutzungsszenarien (-pfaden)

PO für Schneiden verantwortlich machen

Schneiden entlang der Eingangs- / Ausgangsdatenstrukturen

erweitern der Timebox zur Umsetzung

Inkrementelles Umsetzen von (Business) Regeln

Ja

Nein