5. Agiles Arbeiten II – Schätzen, DoD und Sprint

Nach diesem Kapitel kannst du:

• den Zweck relativer Schätzung erklären, Planning Poker durchführen und mit der Velocity einen Sprint planen.
• eine Definition of Done aufstellen und von den Akzeptanzkriterien einer Story abgrenzen.
• Board, Branch und Merge Request über die Story verbinden und ein Projekt mit Sprint 0 starten.
• Ergebnisse einer Retrospektive beurteilen und in eine konkrete, überprüfbare Maßnahme überführen.

Im vorigen Kapitel hast du Anforderungen als User Stories formuliert, geprüft und das Backlog geordnet. In der Matura-Analogie steht die Stoffliste jetzt geordnet da; offen ist, wie groß die einzelnen Kapitel sind, wie viel in eine Woche passt und wann ein Kapitel „sitzt”.

Schätzen

Schätzen heißt nicht, die Zukunft vorherzusagen. Es heißt, Aufgaben relativ zueinander einzuordnen, damit planbar wird, wie viel in einen Sprint passt.

Wie lange du für das Matura-Kapitel Integralrechnung brauchst, weißt du nicht auf die Stunde genau. Dass es ungefähr doppelt so groß ist wie Folgen und Reihen, kannst du dagegen ziemlich sicher sagen. Genau diese Art von Aussage ist eine Schätzung im agilen Sinn.

Story Points statt Stunden

Deshalb wird nicht in Stunden geschätzt, sondern in Story Points: einer einheitenlosen Zahl für Umfang, Komplexität und Unsicherheit zusammen. Üblich ist eine Skala mit wachsenden Abständen (1, 2, 3, 5, 8, 13, 20), weil die Unsicherheit mit der Größe wächst. Zwischen 1 und 2 lässt sich sinnvoll unterscheiden, zwischen 19 und 20 nicht.

	Schätzung in Stunden	Schätzung in Story Points
Frage	Wie lange brauche ich?	Wie groß ist das im Vergleich zu jener Story?
Hängt ab von	wer es macht und wie gut der Tag läuft	nur von der Aufgabe selbst
Wird gelesen als	Zusage	Planungsgrundlage
Unsicherheit	versteckt sich in einer genauen Zahl	steckt sichtbar in den groben Stufen

Planning Poker

Das Verfahren zum gemeinsamen Schätzen heißt Planning Poker:

1. Der Product Owner stellt die Story vor, das Team fragt nach.

2. Alle wählen gleichzeitig und verdeckt eine Zahl. Gleichzeitig deshalb, weil sonst die erste genannte Zahl alle anderen beeinflusst.

3. Höchste und niedrigste Schätzung begründen ihre Wahl. Genau hier liegt der Ertrag: Abweichungen decken unterschiedliche Annahmen auf („Ich dachte, wir haben die Anbindung schon”).

4. Neue Runde, bis die Schätzungen nah beieinanderliegen. Perfekte Einigkeit ist nicht das Ziel.

Als Ablauf zusammengefasst, mit der Schleife zurück zur verdeckten Wahl, solange die Schätzungen auseinanderliegen:

flowchart LR
  A["1 PO stellt Story vor,<br/>Team fragt nach"] --> B["2 Alle wählen gleichzeitig<br/>und verdeckt eine Zahl"]
  B --> C["3 Höchste und niedrigste<br/>Schätzung begründen"]
  C --> D{"Nah<br/>beieinander?"}
  D -- nein --> B
  D -- ja --> E["Schätzung steht"]

Ihr könnt auch die Open Source App ausprobieren: https://github.com/hellomuthu23/planning-poker

Velocity

Nach ein bis zwei Sprints kennt das Team seine Velocity: die Summe der Punkte, die es tatsächlich fertigstellt. Damit wird die Planung des nächsten Sprints zur Rechenaufgabe statt zur Hoffnung.

Konkret heißt das: Ein Team hat in den ersten drei Sprints 18, 23 und 19 Punkte fertiggestellt. Für den vierten Sprint plant es mit etwa 20 Punkten (die Linie im Diagramm), nicht mit den 30, die es gerne schaffen würde. Gezählt werden dabei nur Stories, die die Definition of Done vollständig erfüllen. Eine zu 90 % fertige Story zählt null Punkte.

xychart-beta
  title "Velocity der ersten drei Sprints"
  x-axis ["Sprint 1", "Sprint 2", "Sprint 3"]
  y-axis "Story Points" 0 --> 30
  bar [18, 23, 19]
  line [20, 20, 20]

Warum Schätzungen so oft danebenliegen

Drei wiederkehrende Ursachen, alle beobachtbar:

Die vergessene Arbeit. Geschätzt wird das Programmieren, vergessen werden Tests, Review, Fehlerbehebung, Dokumentation und das Warten auf Rückmeldung. Die Definition of Done verhindert genau das, weil sie festlegt, was zu „fertig” alles gehört.

Der Optimismus. Geschätzt wird der Fall, in dem nichts dazwischenkommt. Es kommt aber immer etwas dazwischen. Dieses Phänomen ist so verlässlich, dass es einen eigenen, halb scherzhaften Namen hat, Hofstadters Gesetz: „Es dauert immer länger als erwartet, selbst wenn man Hofstadters Gesetz berücksichtigt.” Der Witz daran ist ernst gemeint: Auch das bewusste Einplanen von Verzögerung verhindert die nächste Verzögerung nicht zuverlässig.

Die Zahl als Versprechen. Sobald eine Schätzung als Zusage behandelt wird, schätzt niemand mehr ehrlich, sondern defensiv. Schätzungen sind Planungsgrundlage, keine Verträge. Wer sie als Vertrag verwendet, bekommt aufgeblähte Zahlen und lernt nichts.

Wo begegnet dir das? Bei jedem Lieferdienst, der „in 25-35 Minuten” anzeigt statt „in 27 Minuten”. Die Spanne ist ehrlicher als eine genaue Zahl, aus demselben Grund, aus dem Story Points grobe Stufen haben.

Weiterlesen

• Mike Cohn, Agile Estimating and Planning - die Standardreferenz zu Story Points, Planning Poker und Velocity.
• Mountain Goat Software: Planning Poker - kurze Beschreibung des Verfahrens von Mike Cohn, der es bekannt gemacht hat.

Kurz nachgedacht

Ein Team hat in drei Sprints 12, 21 und 14 Punkte fertiggestellt. Im Backlog stehen oben Stories mit 8, 5, 5, 3 und 8 Punkten. Welche Stories nimmt das Team in den nächsten Sprint, und was solltest du über die Schwankung von 12 auf 21 im Sprint-Review-Gespräch fragen?

Auflösung

Der Durchschnitt liegt bei etwa 16 Punkten. Das Team nimmt die oberen drei Stories (8 + 5 + 5 = 18) oder bleibt vorsichtig bei 8 + 5 + 3 = 16, wenn die Reihenfolge das zulässt. Die Schwankung ist ein Hinweis, keine Schande: Wurden im 12-Punkte-Sprint Stories nicht fertig und erst im nächsten gezählt? Dann ist das ein Thema für die Retrospektive, nicht für die Schätzung.

Definition of Done

Die Definition of Done ist die für alle Stories gleiche Antwort auf die Frage, wann etwas fertig ist. Sie wird einmal vereinbart und gilt dann ohne weitere Diskussion. Ein realistisches Beispiel für ein Schulprojekt:

Eine Story ist fertig, wenn:
- die Akzeptanzkriterien erfuellt sind,
- der Code auf einem Branch entstanden und per Merge Request gereviewt wurde,
- automatische Tests fuer die neue Funktion existieren und die Pipeline gruen ist,
- die Dokumentation (API-Beschreibung, README) angepasst ist,
- die Funktion auf dem gemeinsamen Stand vorfuehrbar ist.

Ohne diese Liste bedeutet „fertig” für jede Person etwas anderes, und der Unterschied fällt erst im Review auf - also genau dann, wenn keine Zeit mehr ist.

In der Matura-Analogie ist „Kapitel gelesen” kein Fertig-Kriterium. Eines wäre: „Zusammenfassung geschrieben, alle Übungsaufgaben gerechnet, eine alte Maturaaufgabe ohne Unterlagen gelöst”. Anders als bei der Matura-Vorbereitung gilt die DoD aber nicht für dich allein, sondern verbindlich für das ganze Team. Genau darin liegt ihr Wert.

Akzeptanzkriterien und DoD im Vergleich

	Akzeptanzkriterien	Definition of Done
Gilt für	genau eine Story	alle Stories gleich
Beschreibt	fachlich, was die Funktion leisten muss	qualitativ, wie fertig sie sein muss
Beispiel	„Duplikate werden verworfen”	„Pipeline ist grün”
Wird festgelegt	pro Story, vom Product Owner mit dem Team	einmal, vom Team

Im Review werden also immer beide Listen abgehakt:

flowchart LR
  S["Story umgesetzt"] --> A{"Alle Akzeptanz-
  kriterien erfüllt?"}
  A -- nein --> W["weiterarbeiten, zählt null Punkte"]
  A -- ja --> D{"DoD vollständig erfüllt?"}
  D -- nein --> W
  D -- ja --> F["fertig, zählt für die Velocity"]

Merksatz

Eine Story ist erst fertig, wenn ihre Akzeptanzkriterien und die gesamte Definition of Done erfüllt sind.

Der Sprint im Alltag

flowchart LR
  A[Backlog geordnet] --> B[Planning: Auswahl und Ziel]
  B --> C[Umsetzung: Story - Branch - MR]
  C --> D[Review: Ergebnis zeigen]
  D --> E[Retrospektive: Vorgehen anpassen]
  E --> A

Sprint Planning. Zwei Fragen: Was übernehmen wir (aus dem geordneten Backlog, begrenzt durch die Velocity)? Und wie gehen wir es an (Zerlegung in Tasks)? Am Ende steht ein Sprint-Ziel in einem Satz. Es hilft, wenn während des Sprints entschieden werden muss, was zuerst fällt.

Daily. 15 Minuten, im Stehen, zur selben Zeit. Kein Bericht an die Lehrkraft, sondern Abstimmung im Team und das frühe Aussprechen von Hindernissen. Diskussionen, die länger dauern, werden vertagt und im kleineren Kreis geführt. In Schulprojekten ersetzt ein Board-Check zu Beginn jeder Projekteinheit das tägliche Daily (siehe „Scrum light + Kanban“ in Kapitel 06).

Review. Vorgeführt wird lauffähige Software, keine Folien. Was nicht vorführbar ist, gilt als nicht fertig. Die Rückmeldung fließt ins Backlog.

Retrospektive. Der Blick auf die Zusammenarbeit. Ein einfaches, im Unterricht bewährtes Format:

Was lief gut?	Was lief schlecht?	Was ändern wir konkret?
Reviews kamen meist am selben Tag	zwei Stories hingen drei Tage im Review	ab sofort: jede:r schaut vor dem Daily in die Review-Spalte; verantwortlich: Lea, Kontrolle in der nächsten Retro

Entscheidend ist die dritte Spalte: eine Maßnahme, benannt, mit einer verantwortlichen Person, überprüfbar im nächsten Sprint. Retrospektiven, die nur sammeln, hören nach drei Runden von selbst auf, weil alle merken, dass sich nichts ändert.

Unbrauchbare Maßnahme	Brauchbare Maßnahme
„Wir sollten besser kommunizieren.”	„Blockaden kommen sofort in den Team-Channel, nicht erst ins Daily; Ben prüft beim nächsten Daily, ob das passiert ist.”
„Mehr testen.”	„Kein MR ohne mindestens einen neuen Test; der Reviewer lehnt sonst ab.”

Wo begegnet dir das? In jedem Praktikumsbetrieb mit Softwareentwicklung, der agil arbeitet: Das Daily ist dort oft der erste Termin des Tages, an dem auch Praktikant:innen teilnehmen.

Board und Git verbinden

Der Prozess soll nicht neben der Arbeit herlaufen, sondern in ihr stecken. Das gelingt, wenn Story, Branch und Merge Request denselben Namen tragen:

flowchart LR
  A["Issue #42<br/>Schlagworte hinzufügen"] --> B["Branch<br/>feature/42-add-tags"]
  B --> C["Merge Request<br/>Closes #42"]
  C --> D["Review und Merge nach dev"]
  D --> E["Issue schließt automatisch"]

Praktisch heißt das:

• Jede Story ist ein Issue mit Akzeptanzkriterien als Checkliste.
• Der Branch trägt Nummer und Kurztitel der Story (feature/42-add-tags).
• Der Merge Request verweist mit Closes #42 auf das Issue. Beim Merge schließt es sich selbst, sofern der Ziel-Branch der Default-Branch des Projekts ist (im Git-Workflow light ist das dev, siehe Kapitel 07).
• Die Board-Spalten entsprechen dem tatsächlichen Ablauf (Backlog, Sprint, In Arbeit, Review, Fertig), nicht einem Wunschbild. Wie das in GitLab über mehrere Sprints aussieht, zeigt der Abschnitt „Issue Boards über mehrere Sprints“ in Kapitel 06.

Der Nutzen zeigt sich am Sprintende: Die Board-Historie ist das Sprint-Protokoll, und niemand muss nachträglich rekonstruieren, wer was wann gemacht hat. Für die Beurteilung des Jahresprojekts ist genau dieser Nachweis relevant.

Das Board, das nur am Freitag stimmt

Die häufigste Fehlbedienung: Karten werden erst kurz vor dem Review verschoben. Damit ist das Board kein Arbeitsmittel mehr, sondern Nacharbeit, und es zeigt nie den Zustand, für den es gebaut wurde. Regel: Die Karte wandert, wenn die Arbeit wandert, nicht danach.

Sprint 0: der Projektstart

Bevor der erste richtige Sprint beginnt, braucht das Projekt einen Rahmen. Dieser Vorlauf heißt üblicherweise Sprint 0 und liefert:

1. Team und Rollen. Wer aus dem Team ist Product Owner, wer übernimmt im ersten Sprint die Prozessrolle? Die Lehrkraft ist Stakeholder (siehe „Scrum light + Kanban“ in Kapitel 06). Dazu mit der Lehrkraft die Sprinttermine festlegen: meist zwei bis drei Wochen pro Sprint, angepasst an Ferien, Schularbeiten und Projekttage, die Review-Termine fix im Kalender.

2. Produktidee in drei Sätzen. Für wen, welches Problem, welcher Nutzen. Wenn das nicht in drei Sätzen gelingt, ist die Idee noch nicht klar genug.

3. Initiales Backlog. 10 bis 20 Stories, die oberen fünf mit Akzeptanzkriterien und Schätzung, darunter darf es grob bleiben.

4. Definition of Done. Einmal vereinbart, schriftlich, für alle sichtbar, inklusive der Vorgaben der Lehrkraft (siehe „Vorgaben der Lehrkraft“ in Kapitel 06).

5. Technischer Rahmen. Repository, Board, Pipeline, ein lauffähiges Gerüst - genug, dass die erste Story tatsächlich fertig werden kann.

flowchart LR
  A["Team und Rollen"] --> B["Produktidee in drei Sätzen"]
  B --> C["Initiales Backlog"]
  C --> D["Definition of Done"]
  D --> E["Technischer Rahmen"]
  E --> F["Erste Story kann starten"]

Der Maßstab für Sprint 0 ist einfach: Am Ende muss die erste Story starten können, ohne dass noch etwas geklärt werden muss.

Zusatzmaterialien

• Mike Cohn, Agile Estimating and Planning - lohnt sich, wenn deine Velocity stark schwankt und du verstehen willst, woran das liegt.
• GitLab Docs: Issues - die technische Grundlage für den Abschnitt „Board und Git verbinden”, inklusive Boards, Labels und Milestones.

Zum Anhören

Diesen Text kannst du dir kostenlos mit der Vorlesefunktion deines Browsers oder Betriebssystems vorlesen lassen, z. B. in Microsoft Edge über „Laut vorlesen”.

Lernergebnisse: Was du nach diesem Kapitel können solltest

• Erklären: den Zweck relativer Schätzung erklären, Planning Poker durchführen und mit der Velocity einen Sprint planen.
• Anwenden: eine Definition of Done aufstellen und von den Akzeptanzkriterien einer Story abgrenzen.
• Anwenden: Board, Branch und Merge Request über die Story verbinden und ein Projekt mit Sprint 0 starten.
• Beurteilen: Ergebnisse einer Retrospektive beurteilen und in eine konkrete, überprüfbare Maßnahme überführen.

Passende Übungen

Eine eigene Übung hat dieses Kapitel nicht: Die 70 Praxisminuten setzen Aufgabe 02 aus Kapitel 04 fort. Die nächste Übung, Aufgabe 03 - Jahresprojekt Sprint 0, folgt in Kapitel 07.

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules