---

Scrum anhand einer realen Fallstudie lernen! Das könnte Sie überraschen!

Vor dem ersten Sprint

Alex ist Product Owner eines neuen Softwareprojekts. Zunächst ermittelt er Anforderungen, um den gewünschten Geschäftswert für seinen Kunden zu liefern.

Er muss sicherstellen, dass sein Kunde die richtige Software für greifbare Geschäftsergebnisse erhält. Er dokumentiert wesentliche Anwendungsfälle und bespricht sie mit Architekten, Kundenvertretern und weiteren IT- und Geschäfts-Stakeholdern. (Siehe unsere Scrum-Beispiel)

Die groben Anwendungsfälle und Anforderungen trägt er ein in das Scrum Product Backlog und beginnt mit dem Team eine Schätz- und Priorisierungssitzung. Alle Einträge erhalten eine erste grobe Schätzung und Priorität.

Anna als Scrum Master sorgt für eine gemeinsame Sprache, damit Product Owner, Team und Stakeholder an den angestrebten Zielen ausgerichtet sind. Sie haben also ein ausreichendes Verständnis neuer Konzepte, etwa Anwendungsfall, Backlog und Sprint. Vor allem wird der Scrum-Prozess am Arbeitsplatz richtig angewandt.

Alex zerlegt die groben Anforderungen in einen ersten Entwurf feinerer User Stories und lädt damit zur ersten Sprint-Planung ein.

Sprint 1 - Tag 0

Während der Sprint-Planungstellt Alex Einträge nach absteigender Priorität vor. Das Team klärt Fragen und prüft für jeden Eintrag Kapazität und Wissen zur Entwicklung und Lieferung. Es muss sicherstellen, dass alle nötigen Menschen und technischen Ressourcen vor Sprint-Beginn verfügbar sind. Kritische Voraussetzungen und Abhängigkeiten müssen erfüllt sein.

Während der Sprint-Planung (Was-Teil)prognostizieren die Entwickler, die Stories 1,2,3,6,7 und 8 bis zum Ende für das gemeinsame Sprint-Ziel abzuschließen. Sie übernehmen sie aus dem Product Backlog in das Sprint Backlog. Stories 4 und 5 sind wegen fehlender technischer Infrastruktur diesmal nicht möglich.

Nach dem Was-Teil bittet Anna das Team, die Umsetzung der zugesagten Stories im Wie-Teil zu vertiefen.Die entstehenden Aufgaben werden auf Karten im Sprint Backlog festgehalten. Nun können alle eine Aufgabe wählen und beginnen.

Sprint 1 - Tag 1

Morgens treffen sich die Entwickler zum Daily Scrum. Alle geben eine kurze, präzise Erklärung zu bisheriger Arbeit, aktualisieren Restschätzungen auf den Karten und nennen heutige Pläne sowie blockierende Hindernisse.

Melinda meldet ein Lizenzproblem ihrer Entwicklungsumgebung. Anna prüft, ob andere betroffen sind, und kümmert sich nach dem Treffen darum. Nach etwa 15 Minuten gehen alle wieder an die Arbeit.

Danach aktualisiert Anna das Sprint-Burndown- Diagramm für den Fortschritt. Sie ruft den Anbieter an, bestellt die Lizenz und gibt sie Melinda.

Scrum-Einführung: Eine reale Fallstudie über verschiedene Phasen und Sprints

Sprint 1 - Tag 2

Morgens treffen sich die Entwickler wieder zum Daily Scrum. Nachmittags ist James über das erwartete Ergebnis einer Story unsicher. Er ruft Alex an und klärt das Verständnis. Sobald er weiß, wie es weitergeht, setzt er die Umsetzung fort.

Sprint 1 – Tag 6

Der Tag beginnt mit dem Daily Scrum. Eine Datenbankoptimierungsdiskussion lässt das Treffen über 15 Minuten hinausgehen. Anna erinnert daran, dass das Daily Scrum keine lange Technikdiskussion ist, sondern den Fortschritt zum Sprint-Ziel prüft und den Entwicklerplan anpasst..

Danach meldet Alex (Product Owner) Anna (Scrum Master) neue Kundenanforderungen mit möglichen Folgen für laufende und kommende Sprints. Anna erinnert höflich daran, dass Änderungen das Sprint-Ziel nicht gefährden dürfen. Entwickler und Product Owner können den Umfang bei neuen Erkenntnissen klären und neu verhandeln; nicht jede gewählte Story ist unveränderlich zugesagt. Anna organisiert deshalb eine Backlog-Verfeinerung am Nachmittag, damit Alex die neuen Anforderungen vorstellen kann.

Die Gruppe hilft ihm dabei, die Stories in den Gesamtplan einzuordnen sowie erste Aufgaben, Schätzungen und Prioritäten festzulegen..

Sprint 1 – Tag 10

Am letzten Tag des ersten Sprints lädt Anna das Team ein zum Sprint Review. Auf einem Testserver liegt die aktuelle Version des lieferfähigen Inkrements bereit.

Alex und Kunden-Stakeholder Herr Rich prüfen an der grafischen Oberfläche, ob die Umsetzung den Erwartungen entspricht und der aktuelle Anwendungsstand ausreichend dokumentiert ist.

Am Ende des Reviews fasst Alex zusammen:

• Stories 1,2,6 und 7 wurden wie zugesagt und erwartet geliefert.
• Story 3 ist nicht fertig und wurde nicht gezeigt. Sie geht zur neuen Einordnung ins Product Backlog zurück; Restarbeit kann in der nächsten Planung gewählt werden.
• Story 8 erfüllt die gemeinsame Definition of Done (DoD) nicht. Sie geht zurück ins Product Backlog, wo Kriterien und Restaufgaben vor einer erneuten Auswahl geklärt werden.

Alex und Herr Rich informieren das Team kurz über kommende Änderungen und Herausforderungen der Anforderungen sowie die Richtung der Gesamtstrategie.Herr Rich dankt für Einsatz und Verpflichtung und verlässt den Raum.

Danach trifft sich das Team zur Sprint-Retrospective-Besprechung. Es bespricht Erfolge und Verbesserungen für bessere Prognosen und um Probleme mit Stories 3 und 8 zu vermeiden. Ein Hindernis ist fehlendes Architekturwissen. Anna organisiert einen Systemarchitekten, der das Team zu Beginn des nächsten Sprints anleitet.

Sprint 2 - Tag 1

Alex ergänzt nach Kundentreffen Anforderungen im Product Backlog. Für Story 8 klärt er Kriterien und Restarbeit, behält aber die gemeinsame DoD bei. So versteht das Team das erwartete Ergebnis besser.

Er lädt zur Planung für Sprint 2 ein. Gemeinsam wird ein Ziel vereinbart, und die Entwickler wählen und planen passende Stories. Anna unterstützt die Wirksamkeit des Events; der zweite Sprint beginnt.