Essential Scrum

Book description

  • Umfassendes Scrum-Wissen auf Team-, Produkt- und Portfolio-Ebene
  • Kernkonzepte, Rollen, Planung und Sprints ausführlich erläutert
  • Auch geeignet zur Vorbereitung auf die Scrum-Zertifizierung

Dieses Buch beschreibt das Wesen von Scrum – die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen zu entwickeln.Es ist entstanden, weil der Autor Kenneth S. Rubin als Agile- und Scrum-Berater oft nach einem Referenzbuch für Scrum gefragt worden ist – einem Buch, das einen umfassenden Überblick über das Scrum-Framework bietet und darüber hinaus die beliebtesten Ansätze für die Anwendung von Scrum präsentiert.
Dieses Buch ist der Versuch, die eine entscheidende Quelle für alles Wesentliche über Scrum bereitzustellen.Rubin beleuchtet die Werte, Prinzipien und Praktiken von Scrum und beschreibt bewährte, flexible Ansätze, die Ihnen helfen werden, sie viel effektiver umzusetzen. Dabei liefert er mehr als nur die Grundlagen und weist zudem auf wichtige Probleme hin, die Ihnen auf Ihrem Weg begegnen können.Ob Sie sich nun zum ersten Mal an Scrum versuchen oder es schon seit Jahren benutzen: Dieses Buch weiht Sie in die Geheimnisse des Scrum-Entwicklungsverfahrens ein und vermittelt Ihnen ein umfangreiches Scrum-Wissen auf Team-, Produkt- und Portfolio-Ebene. Für diejenigen, die bereits mit Scrum vertraut sind, eignet es sich als Scrum-Referenz.Rubin hat das Buch nicht für eine bestimmte Scrum-Rolle geschrieben. Stattdessen soll es allen, die direkt oder indirekt mit Scrum zu tun haben, ein gemeinsames Verständnis von Scrum und den Prinzipien, auf denen es beruht, vermitteln.

Aus dem Inhalt:
1. Teil: Kernkonzepte
  • Scrum-Framework
  • Agile Prinzipien
  • Sprints
  • Anforderungen und User Stories
  • Das Product Backlog
  • Schätzungen und Velocity
  • Technische Schulden

2. Teil: Rollen
  • Product Owner
  • Scrum
  • Master
  • Entwicklungsteam
  • Strukturen des Scrum-Teams
  • Manager

3. Teil: Planung
  • Scrum-Planungsprinzipien
  • Mehrstufige Planung
  • Portfolio-Planung
  • Visionsfindung/Produktplanung
  • Release-Planung

4. Teil: Sprints
  • Sprint-Planung
  • Sprint-Ausführung
  • Sprint Review
  • Sprint-Retrospektive

Table of contents

  1. Impressum
  2. Vorwort von Mike Cohn
  3. Vorwort von Ron Jeffries
  4. Einleitung
  5. Danksagungen
  6. Über den Autor
  7. Kapitel 1: Einführung
    1. 1.1 Was ist ​​Scrum?
    2. 1.2 Die Ursprünge von ​Scrum
    3. 1.3 Wieso Scrum?
    4. 1.4 Ergebnisse bei Genomica
    5. 1.5 Kann Scrum Ihnen ​helfen?
      1. 1.5.1 Die ​Complex-Domäne
      2. 1.5.2 Die ​Complicated-Domäne
      3. 1.5.3 Die ​Simple-Domäne
      4. 1.5.4 Die ​Chaotic-Domäne
      5. 1.5.5 Disorder (Nicht-Wissen, Regellosigkeit)
      6. 1.5.6 ​​Unterbrechungsgesteuerte Arbeit
    6. 1.6 Abschließende Bemerkungen
  8. Teil I: Kernkonzepte
  9. Kapitel 2: Das Scrum-Framework​​
    1. 2.1 Überblick
    2. 2.2 Scrum-Rollen
      1. 2.2.1 ​Product Owner
      2. 2.2.2 ​ScrumMaster
      3. 2.2.3 Das ​Entwicklungsteam
    3. 2.3 ​​Scrum-Aktivitäten und ​​Artefakte
      1. 2.3.1 ​​Product Backlog
      2. 2.3.2 ​​Sprints
      3. 2.3.3 ​​​Sprint-Planung
      4. 2.3.4 ​​​Sprint-Ausführung
      5. 2.3.5 ​​Daily Scrum
      6. 2.3.6 ​Fertig (Done)
      7. 2.3.7 Sprint Review
      8. 2.3.8 ​​​Sprint-Retrospektive
    4. 2.4 Abschließende Bemerkungen
  10. Kapitel 3: Agile Prinzipien​
    1. 3.1 Überblick
    2. 3.2 ​Veränderlichkeit und Unsicherheit
      1. 3.2.1 Hilfreiche Veränderlichkeit bereitwillig annehmen
      2. 3.2.2 Iterative und inkrementelle Entwicklung nutzen
      3. 3.2.3 Ausnutzen der Veränderlichkeit durch Inspektion, Anpassung und Transparenz
      4. 3.2.4 Gleichzeitiges Reduzieren aller Formen der Unsicherheit
    3. 3.3 ​​Vorhersage und Anpassung
      1. 3.3.1 Optionen offen halten
      2. 3.3.2 Akzeptieren, dass man es nicht gleich von Anfang an richtig machen kann
      3. 3.3.3 Einen adaptiven, untersuchenden Ansatz bevorzugen
      4. 3.3.4 Änderung auf eine ökonomisch sinnvolle Weise annehmen
      5. 3.3.5 Vorhersagende, im Voraus erfolgende Arbeit mit adaptiver, bedarfsgerechter Arbeit abwägen
    4. 3.4 ​Validiertes Wissen
      1. 3.4.1 Schnelles Validieren wichtiger Annahmen
      2. 3.4.2 Abwägen mehrerer gleichzeitiger ​​Lernschleifen
      3. 3.4.3 Organisieren des Workflows für schnelle Feedbacks
    5. 3.5 ​Work in Process (WIP)
      1. 3.5.1 Wirtschaftlich sinnvolle ​Batch-Größen benutzen
      2. 3.5.2 Lagerbestände erkennen und sinnvoll verwalten
      3. 3.5.3 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Arbeiter
      4. 3.5.4 Verzögerungskosten betrachten
    6. 3.6 ​Fortschritt
      1. 3.6.1 An Echtzeitinformationen anpassen und umplanen
      2. 3.6.2 ​Fortschritt messen, indem man funktionierende Güter validiert
      3. 3.6.3 Auf eine ​wertzentrierte Auslieferung konzentrieren
    7. 3.7 ​​Leistung
      1. 3.7.1 Gehe schnell, aber hetze nicht
      2. 3.7.2 Baue Qualität ein
      3. 3.7.3 Mache alles ohne großes Zeremoniell
    8. 3.8 Abschließende Bemerkungen
  11. Kapitel 4: Sprints​
    1. 4.1 Überblick
    2. 4.2 Timeboxing
      1. 4.2.1 Legt ein ​​WIP-Limit fest
      2. 4.2.2 Erzwingt eine ​​Priorisierung
      3. 4.2.3 Demonstriert ​​Fortschritt
      4. 4.2.4 Verhindert ​​unnötigen Perfektionismus
      5. 4.2.5 Motiviert die ​​Fertigstellung
      6. 4.2.6 Verbessert die ​​Vorhersagbarkeit
    3. 4.3 Kurze ​​​​Zeitdauer
      1. 4.3.1 ​Erleichterte Planung
      2. 4.3.2 ​​​Schnelles Feedback
      3. 4.3.3 Verbesserter ​​Return on Investment
      4. 4.3.4 Begrenzte Fehler
      5. 4.3.5 Wiedererweckte Begeisterung
      6. 4.3.6 Häufige ​Checkpoints
    4. 4.4 ​​Konsistente Dauer
      1. 4.4.1 Vorteile der Kadenz
      2. 4.4.2 Vereinfacht die Planung
    5. 4.5 Keine das Ziel beeinflussenden Änderungen
      1. 4.5.1 Was ist ein ​​Sprint-Ziel?
      2. 4.5.2 ​Gegenseitige Verpflichtung
      3. 4.5.3 Änderungen versus Klärung
      4. 4.5.4 Konsequenzen einer Änderung
      5. 4.5.5 Pragmatisch sein
      6. 4.5.6 ​Abnormaler Abbruch
    6. 4.6 ​​Definition von Fertig (Done)
      1. 4.6.1 Wie lautet die Definition von Fertig?
      2. 4.6.2 Die Definition von Fertig kann sich im Laufe der Zeit weiterentwickeln
      3. 4.6.3 Definition von Fertig versus ​​Akzeptanzkriterien
      4. 4.6.4 Fertig versus ​Fertig-Fertig
    7. 4.7 Abschließende Bemerkungen
  12. Kapitel 5: Anforderungen und User Stories​​
    1. 5.1 Überblick
    2. 5.2 ​​Gespräche
    3. 5.3 Progressive ​​Verfeinerung
    4. 5.4 Was sind User Stories?
      1. 5.4.1 ​Card (Karte)
      2. 5.4.2 ​Conversation (Gespräch)
      3. 5.4.3 ​Confirmation (Bestätigung)
    5. 5.5 Der ​Detaillierungsgrad
    6. 5.6 In gute Stories INVESTieren
      1. 5.6.1 ​Independent (unabhängig)
      2. 5.6.2 ​Negotiable (verhandelbar)
      3. 5.6.3 ​Valuable (werthaltig)
      4. 5.6.4 ​Estimatable (schätzbar)
      5. 5.6.5 ​Passende Größe (klein)
      6. 5.6.6 ​Testable (prüfbar)
    7. 5.7 ​​Nichtfunktionale Anforderungen
    8. 5.8 Stories zum Wissenserwerb​​
    9. 5.9 ​​Stories sammeln
      1. 5.9.1 ​​Workshop zum Schreiben von User Stories
      2. 5.9.2 ​​Story Mapping
    10. 5.10 Abschließende Bemerkungen
  13. Kapitel 6: Das Product Backlog​
    1. 6.1 Überblick
    2. 6.2 ​​Product-Backlog-Elemente
    3. 6.3 ​Merkmale guter Product Backlogs
      1. 6.3.1 ​Detailed appropriately (ausreichend detailliert)
      2. 6.3.2 ​Emergent
      3. 6.3.3 ​Estimated (geschätzt)
      4. 6.3.4 ​Prioritized (priorisiert)
    4. 6.4 ​​Pflege
      1. 6.4.1 Was bedeutet Pflege?
      2. 6.4.2 ​Wer führt die Pflege durch?
      3. 6.4.3 ​Wann findet die Pflege statt?
    5. 6.5 Die ​​Definition von Bereit
    6. 6.6 ​​Flow Management
      1. 6.6.1 ​​Release Flow Management
      2. 6.6.2 ​Sprint Flow Management
    7. 6.7 Welche und wie viele ​Product Backlogs?
      1. 6.7.1 Was ist ein ​Produkt?
      2. 6.7.2 Große Produkte – ​​hierarchische Backlogs
      3. 6.7.3 Mehrere Teams – ein Product Backlog
      4. 6.7.4 Ein Team – mehrere Produkte
    8. 6.8 Abschließende Bemerkungen
  14. Kapitel 7: Schätzung und Velocity​​
    1. 7.1 Überblick
    2. 7.2 Was und wann wir ​schätzen
      1. 7.2.1 Schätzungen für ​​Portfolio-Backlog-Elemente
      2. 7.2.2 ​​Product-Backlog-Schätzungen
      3. 7.2.3 ​Aufgabenschätzungen
    3. 7.3 ​Schätzkonzepte für Product-Backlog-Elemente
      1. 7.3.1 Als ​​Team schätzen
      2. 7.3.2 ​Schätzungen sind keine Verpflichtungen
      3. 7.3.3 ​Exaktheit versus Präzision
      4. 7.3.4 ​Relative Größenschätzung
    4. 7.4 ​Schätzeinheiten für Product-Backlog-Elemente
      1. 7.4.1 ​Story-Punkte
      2. 7.4.2 ​​Idealtage
    5. 7.5 ​​Planungspoker
      1. 7.5.1 ​Schätzskala
      2. 7.5.2 Wie man spielt
      3. 7.5.3 ​Vorteile
    6. 7.6 Was ist ​​Velocity?
    7. 7.7 Einen ​​​​Velocity-Bereich berechnen
    8. 7.8 Die Velocity ​vorhersagen
    9. 7.9 Die Velocity ​beeinflussen
    10. 7.10 ​Missbrauch der Velocity
    11. 7.11 Abschließende Bemerkungen
  15. Kapitel 8: Technische Schulden​
    1. 8.1 Überblick
    2. 8.2 Die ​Folgen technischer Schulden
      1. 8.2.1 ​Unvorhersehbarer Wendepunkt
      2. 8.2.2 ​Zunehmend verzögerte Auslieferung
      3. 8.2.3 ​Beträchtliche Anzahl an Defekten
      4. 8.2.4 ​Steigende Entwicklungs- und Support-Kosten
      5. 8.2.5 Das ​Produkt verkümmert
      6. 8.2.6 ​Schwindende Vorhersehbarkeit
      7. 8.2.7 ​Leistungseinbruch
      8. 8.2.8 ​Allgemeiner Frust
      9. 8.2.9 ​Sinkende Kundenzufriedenheit
    3. 8.3 ​Ursachen der technischen Schulden
      1. 8.3.1 Druck hinsichtlich des Erreichens einer Deadline
      2. 8.3.2 Erfolglose Versuche der ​Velocity-Beschleunigung
      3. 8.3.3 Gerücht: Weniger Testen kann die Velocity beschleunigen
      4. 8.3.4 Schulden bauen auf Schulden auf
    4. 8.4 Technische Schulden müssen ​organisiert werden
    5. 8.5 Die ​Zunahme technischer Schulden überwachen
      1. 8.5.1 ​Bewährte technische Praktiken anwenden
      2. 8.5.2 Eine starke ​Definition von Fertig benutzen
      3. 8.5.3 Die ​wirtschaftlichen Aspekte technischer Schulden richtig verstehen
    6. 8.6 Technische Schulden ​sichtbar machen
      1. 8.6.1 Technische Schulden ​auf geschäftlicher Ebene sichtbar machen
      2. 8.6.2 Technische Schulden ​auf der technischen Ebene sichtbar machen
    7. 8.7 Technische Schulden ​abbauen
      1. 8.7.1 Nicht alle technischen Schulden sollten ​abgebaut werden
      2. 8.7.2 Wenden Sie die ​​Pfadfinderregel an (Bauen Sie die Schulden ab, sobald sie Ihnen begegnen)
      3. 8.7.3 Bauen Sie technische Schulden ​schrittweise ab
      4. 8.7.4 Bauen Sie die technischen Schulden ​mit den höchsten Zinsen zuerst ab
      5. 8.7.5 Technische Schulden abbauen, während man für den Kunden werthaltige Arbeit erledigt
    8. 8.8 Abschließende Bemerkungen
  16. Teil II: Rollen
  17. Kapitel 9: Der Product Owner​​​
    1. 9.1 Überblick
    2. 9.2 ​Hauptaufgaben
      1. 9.2.1 Organisation der ​wirtschaftlichen Belange
      2. 9.2.2 Mitwirkung an der ​Planung
      3. 9.2.3 Pflege des ​​​Product Backlogs
      4. 9.2.4 ​Definition und Verifikation der Akzeptanzkriterien
      5. 9.2.5 Zusammenarbeit mit dem ​Entwicklungsteam
      6. 9.2.6 Zusammenarbeit mit den ​Stakeholdern
    3. 9.3 ​Eigenschaften/Fähigkeiten
      1. 9.3.1 ​Fachwissen
      2. 9.3.2 ​Soziale Kompetenz
      3. 9.3.3 ​Entscheidungsfindung
      4. 9.3.4 ​Verantwortung
    4. 9.4 ​Der Alltag eines Product Owners
    5. 9.5 ​Wer sollte Product Owner sein?
      1. 9.5.1 ​Interne Entwicklung
      2. 9.5.2 ​Gewerbliche Entwicklung
      3. 9.5.3 ​Ausgelagerte Entwicklung
      4. 9.5.4 ​Komponentenentwicklung
    6. 9.6 Product Owner ​kombiniert mit anderen Rollen
    7. 9.7 Das ​Product-Owner-Team
      1. 9.7.1 ​Product-Owner-Stellvertreter
      2. 9.7.2 ​Chief Product Owner
    8. 9.8 Abschließende Bemerkungen
  18. Kapitel 10: ScrumMaster​​​
    1. 10.1 Überblick
    2. 10.2 Wichtigste Aufgaben
      1. 10.2.1 ​Coach
      2. 10.2.2 ​»Dienende Führungskraft«
      3. 10.2.3 ​Prozessautorität
      4. 10.2.4 ​Schutz vor störenden Einflüssen
      5. 10.2.5 ​​Beseitigung von Hindernissen
      6. 10.2.6 ​Berater in der Organisationsentwicklung
    3. 10.3 ​Eigenschaften/Fähigkeiten
      1. 10.3.1 Sachkundig
      2. 10.3.2 Neugierig
      3. 10.3.3 Geduldig
      4. 10.3.4 Teamfähig
      5. 10.3.5 Schützend
      6. 10.3.6 Transparent
    4. 10.4 ​Alltag
    5. 10.5 Die Rolle ausfüllen
      1. 10.5.1 ​Wer sollte ScrumMaster sein?
      2. 10.5.2 Ist die Rolle des ScrumMasters eine ​Vollzeitbeschäftigung?
      3. 10.5.3 ScrumMaster ​in Kombination mit anderen Rollen
    6. 10.6 Abschließende Bemerkungen
  19. Kapitel 11: Das Entwicklungsteam​​​
    1. 11.1 Überblick
    2. 11.2 ​Rollenspezifische Teams
    3. 11.3 Wichtigste ​Aufgaben
      1. 11.3.1 Durchführung des Sprints
      2. 11.3.2 Tägliches ​Untersuchen und Anpassen (​»Inspect and Adapt«)
      3. 11.3.3 ​Pflege des Product Backlogs
      4. 11.3.4 Den ​​Sprint planen
      5. 11.3.5 ​Produkt und Prozess untersuchen und anpassen
    4. 11.4 ​Eigenschaften/Fertigkeiten
      1. 11.4.1 Selbstorganisierend
      2. 11.4.2 ​Funktionsübergreifend vielseitig
      3. 11.4.3 ​​T-förmige Fertigkeiten
      4. 11.4.4 Die ​​Musketier-Einstellung
      5. 11.4.5 ​​Kommunikation mit hoher Bandbreite
      6. 11.4.6 ​Transparente Kommunikation
      7. 11.4.7 Die richtige ​Größe
      8. 11.4.8 ​Fokussiert und verpflichtet
      9. 11.4.9 In einer ​​nachhaltigen Geschwindigkeit arbeiten
      10. 11.4.10 ​Langlebig
    5. 11.5 Abschließende Bemerkungen
  20. Kapitel 12: Die Strukturen des Scrum-Teams​​​
    1. 12.1 Überblick
    2. 12.2 ​​​Funktionsteams versus ​​Komponententeams
    3. 12.3 ​Koordination mehrerer Teams
      1. 12.3.1 ​​​Scrum of Scrums
      2. 12.3.2 Der ​Release-Train
    4. 12.4 Abschließende Bemerkungen
  21. Kapitel 13: Manager​​
    1. 13.1 Überblick
    2. 13.2 ​Teams koordinieren
      1. 13.2.1 ​Grenzen definieren
      2. 13.2.2 ​Ein klares Ziel vorgeben
      3. 13.2.3 ​Teams bilden
      4. 13.2.4 Die ​Teamzusammensetzung ändern
      5. 13.2.5 ​Teams bevollmächtigen
    3. 13.3 ​Teams fördern
      1. 13.3.1 Die Mitarbeiter anspornen
      2. 13.3.2 ​Kompetenz entwickeln
      3. 13.3.3 ​Fachliche Anleitung bieten
      4. 13.3.4 Die ​Integrität des Teams bewahren
    4. 13.4 Die ​Umgebung ausrichten und anpassen
      1. 13.4.1 ​Agile Werte fördern
      2. 13.4.2 ​Organisatorische Hindernisse entfernen
      3. 13.4.3 Die ​​internen Abteilungen ausrichten
      4. 13.4.4 Die ​Partner ausrichten
    5. 13.5 Den ​Wertschöpfungsfluss organisieren
      1. 13.5.1 Die Sichtweise des Systems annehmen
      2. 13.5.2 Die ​wirtschaftlichen Aspekte organisieren
      3. 13.5.3 ​Messungen und Berichte überwachen
    6. 13.6 ​Projektmanager
      1. 13.6.1 ​Projektmanagementaufgaben in einem Scrum-Team
      2. 13.6.2 Eine getrennte ​​Projektmanager-Rolle bewahren
    7. 13.7 Abschließende Bemerkungen
  22. Teil III: Planen
  23. Kapitel 14: Scrum-Planungsprinzipien​​
    1. 14.1 Überblick
    2. 14.2 Gehen Sie nicht davon aus, dass im Voraus erstellte ​Pläne korrekt sind
    3. 14.3 Die ​Vorabplanung sollte hilfreich, aber nicht exzessiv sein
    4. 14.4 Halten Sie sich die ​Planungsoptionen bis zum letzten verantwortbaren Augenblick offen
    5. 14.5 Konzentrieren Sie sich stärker ​auf das Anpassen und Neuplanen als darauf, einem Plan zu genügen
    6. 14.6 Den ​Planungsbestand richtig organisieren
    7. 14.7 Bevorzugen Sie ​kleinere und häufigere Releases
    8. 14.8 ​Lernen Sie schnell dazu und weichen Sie vom Plan ab, wenn es nötig sein sollte
    9. 14.9 Abschließende Bemerkungen
  24. Kapitel 15: Planung auf mehreren Ebenen​​
    1. 15.1 Überblick
    2. 15.2 ​​Portfolio-Planung
    3. 15.3 ​​Produktplanung (Visionsbildung)
      1. 15.3.1 Die Vision
      2. 15.3.2 Allgemeines ​Product Backlog
      3. 15.3.3 ​​Produkt-Roadmap
    4. 15.4 ​​Release-Planung
    5. 15.5 ​​Sprint-Planung
    6. 15.6 ​​Tägliche Planung
    7. 15.7 Abschließende Bemerkungen
  25. Kapitel 16: Portfolio-Planung​​
    1. 16.1 Überblick
      1. 16.1.1 Das ​Timing
      2. 16.1.2 ​Teilnehmer
      3. 16.1.3 Der Prozess
    2. 16.2 ​Zeitplanungsstrategien
      1. 16.2.1 ​​Optimierung der Rendite über die Lebensdauer
      2. 16.2.2 Kalkulation der ​Verzögerungskosten
      3. 16.2.3 ​​Schätzungen mit Genauigkeit statt Präzision
    3. 16.3 ​​Zuflussstrategien
      1. 16.3.1 Den ​wirtschaftlichen Filter anwenden
      2. 16.3.2 ​Zufluss- und Abflussrate ausbalancieren
      3. 16.3.3 ​Sich bietende Gelegenheiten schnell ergreifen
      4. 16.3.4 Planen Sie ​kleinere, häufigere Releases
    4. 16.4 ​​Abflussstrategien
      1. 16.4.1 ​Auf unerledigte Arbeit konzentrieren, nicht auf untätige Mitarbeiter
      2. 16.4.2 ​Einrichten eines WIP-Limits
      3. 16.4.3 ​Auf ein komplettes Team warten
    5. 16.5 Strategien zur Überprüfung der in ​Bearbeitung befindlichen Produkte
      1. 16.5.1 Die ​Grenznutzenrechnung verwenden
    6. 16.6 Abschließende Bemerkungen
  26. Kapitel 17: Visionsfindung (Produktplanung)​
    1. 17.1 Überblick
      1. 17.1.1 Das ​​Timing
      2. 17.1.2 ​Teilnehmer
      3. 17.1.3 Der ​Prozess
    2. 17.2 ​SR4U-Beispiel
    3. 17.3 Die ​Entwicklung der Vision
    4. 17.4 Erstellen eines allgemeinen ​Product Backlogs
    5. 17.5 Die Definition der ​Produkt-Roadmap
    6. 17.6 ​Andere Aktivitäten
    7. 17.7 ​Wirtschaftlich vernünftige Visionsfindung
      1. 17.7.1 Eine ​realistische Vertrauensschwelle anstreben
      2. 17.7.2 Konzentrieren Sie sich auf einen ​kurzfristigen Planungshorizont
      3. 17.7.3 Handeln Sie schnell
      4. 17.7.4 Erwerben Sie ​validiertes Wissen
      5. 17.7.5 Nutzen Sie eine ​inkrementelle Finanzierung
      6. 17.7.6 Lernen Sie ​​schnell dazu und weichen Sie ggf. vom Plan ab (aka Schnelles Scheitern)
    8. 17.8 Abschließende Bemerkungen
  27. Kapitel 18: Release-Planung (längerfristige Planung)​​
    1. 18.1 Überblick
      1. 18.1.1 Das ​Timing
      2. 18.1.2 ​Teilnehmer
      3. 18.1.3 Der ​Prozess
    2. 18.2 ​​Release-Einschränkungen
      1. 18.2.1 Alles fest
      2. 18.2.2 Umfang und Termin fest
      3. 18.2.3 Fester Umfang
      4. 18.2.4 Fester Termin
      5. 18.2.5 Variable Qualität
      6. 18.2.6 ​Einschränkungen aktualisieren
    3. 18.3 Das Product Backlog ​pflegen
    4. 18.4 Die ​minimal freigebbaren Funktionen (Minimum Releasable Features, MRFs) verfeinern
    5. 18.5 ​​Sprint Mapping (Einordnung der Product-Backlog-Elemente)
    6. 18.6 Release-Planung ​mit festem Termin
    7. 18.7 Release-Planung ​mit festem Umfang
    8. 18.8 Die ​Kosten berechnen
    9. 18.9 ​Kommunizieren
      1. 18.9.1 Den ​Fortschritt in einem Release mit festem Umfang kommunizieren
      2. 18.9.2 Den ​Fortschritt in einem Release mit festem Termin kommunizieren
    10. 18.10 Abschließende Bemerkungen
  28. Teil IV: Sprints
  29. Kapitel 19: Die Sprint-Planung​
    1. 19.1 Überblick
      1. 19.1.1 Das ​Timing
      2. 19.1.2 ​Teilnehmer
      3. 19.1.3 Der ​Prozess
    2. 19.2 ​Ansätze für die Sprint-Planung
      1. 19.2.1 ​Zweiteilige Sprint-Planung
      2. 19.2.2 ​Einteilige Sprint-Planung
    3. 19.3 Die ​Kapazität ermitteln
      1. 19.3.1 Was ist die Kapazität?
      2. 19.3.2 Kapazität ​in Story-Punkten
      3. 19.3.3 Die Kapazität ​in Aufwandsstunden
    4. 19.4 ​Product-Backlog-Elemente auswählen
    5. 19.5 Zuversicht erwerben
    6. 19.6 Das Sprint-Ziel ​verfeinern
    7. 19.7 Die Verpflichtung ​finalisieren
    8. 19.8 Abschließende Bemerkungen
  30. Kapitel 20: Die Sprint-Ausführung​​
    1. 20.1 Überblick
      1. 20.1.1 Das ​Timing
      2. 20.1.2 ​Teilnehmer
      3. 20.1.3 Der ​Prozess
    2. 20.2 Die ​Planung der Sprint-Ausführung
    3. 20.3 Flow-Management
      1. 20.3.1 P​arallele Arbeit und ​Ausschwärmen
      2. 20.3.2 Welche Arbeit begonnen werden soll
      3. 20.3.3 Wie man die Arbeit an den Aufgaben organisiert
      4. 20.3.4 Welche Arbeit muss erledigt werden?
      5. 20.3.5 Wer erledigt die Arbeit?
    4. 20.4 ​​Daily Scrum
    5. 20.5 Die Durchführung der Aufgaben – ​Technische Praktiken
    6. 20.6 K​ommunizieren
      1. 20.6.1 Task Board
      2. 20.6.2 Das ​Sprint-Burndown-Chart
      3. 20.6.3 Das ​Sprint-Burnup-Chart
    7. 20.7 Abschließende Bemerkungen
  31. Kapitel 21: Sprint Review​​​
    1. 21.1 Überblick
    2. 21.2 ​Teilnehmer
    3. 21.3 ​Vorarbeiten
      1. 21.3.1 Entscheiden, ​wen man einlädt
      2. 21.3.2 Die Aktivität ​zeitlich planen
      3. 21.3.3 Bestätigen, dass die ​Sprint-Arbeit erledigt ist
      4. 21.3.4 ​Auf die Demonstration vorbereiten
      5. 21.3.5 Festlegen, ​wer was macht
    4. 21.4 Das ​​Vorgehen
      1. 21.4.1 ​Zusammenfassen
      2. 21.4.2 ​Demonstrieren
      3. 21.4.3 ​Diskutieren
      4. 21.4.4 ​Ändern
    5. 21.5 Sprint-Review-​Probleme
      1. 21.5.1 Abnahmen der PBIs
      2. 21.5.2 ​Sporadische Teilnahme
      3. 21.5.3 Umfangreiche Entwicklungsprojekte
    6. 21.6 Abschließende Bemerkungen
  32. Kapitel 22: Die Sprint-Retrospektive​​​
    1. 22.1 Überblick
    2. 22.2 ​Teilnehmer
    3. 22.3 Die Vorarbeit
      1. 22.3.1 Den ​Fokus der Retrospektive definieren
      2. 22.3.2 Die ​Übungen auswählen
      3. 22.3.3 ​Objektive Daten sammeln
      4. 22.3.4 Die Retrospektive ​strukturieren
    4. 22.4 Das ​Vorgehen
      1. 22.4.1 Die ​Atmosphäre gestalten
      2. 22.4.2 ​Gemeinsamer Kontext
      3. 22.4.3 Einsichten identifizieren
      4. 22.4.4 ​Aktionen festlegen
      5. 22.4.5 Die ​Retrospektive schließen
    5. 22.5 Dranbleiben
    6. 22.6 ​Probleme der Sprint-Retrospektive
    7. 22.7 Abschließende Bemerkungen
  33. Kapitel 23: Der Weg nach vorn​
    1. 23.1 Es gibt keinen Endzustand
    2. 23.2 Finden Sie Ihren eigenen Weg
    3. 23.3 ​Best Practices mit anderen teilen
    4. 23.4 Mit ​Scrum den Weg nach vorn finden
    5. 23.5 Immer weiter!
  34. Anhang A: Referenzen
  35. Anhang B: Glossar

Product information

  • Title: Essential Scrum
  • Author(s): Kenneth S. Rubin
  • Release date: May 2014
  • Publisher(s): mitp Verlag
  • ISBN: 9783826690471