2. Agiles Arbeiten praktisch

Agiles Arbeiten praktisch

Das vorige Kapitel hat beschrieben, wie agile Verfahren aufgebaut sind. Dieses Kapitel bringt sie zum Laufen: Wie schreibt man eine brauchbare Anforderung? Wie ordnet man hundert Wünsche? Wie schätzt man Arbeit, die man noch nie gemacht hat? Und wie hängen Board, Branch und Merge Request zusammen, damit der Prozess nicht neben der Arbeit herläuft, sondern in ihr steckt?

Das Kapitel endet mit dem Start des Jahresprojekts. Ab hier ist das Vorgehen nicht mehr Theorie, sondern Ihre Arbeitsweise für die nächsten Monate.

User Stories

Eine Anforderung kann man auf viele Arten aufschreiben. Die Formulierung als User Story hat sich durchgesetzt, weil sie drei Dinge erzwingt, die sonst regelmäßig fehlen: die Person, ihren Wunsch und den Grund.

Als <Rolle>
möchte ich <Funktion>,
damit <Nutzen>.

Ein Beispiel aus einer Medienverwaltung:

Als Redakteurin
möchte ich hochgeladene Videos mit Schlagworten versehen,
damit ich sie später wiederfinde, ohne den Dateinamen zu kennen.

Der dritte Teil ist der wertvollste und wird am häufigsten weggelassen. Er beantwortet die Frage, warum die Funktion existiert - und damit auch, ob eine billigere Lösung denselben Zweck erfüllt. Steht der Nutzen da (“später wiederfinden”), fällt auf, dass vielleicht eine Volltextsuche über vorhandene Metadaten genügt und niemand Schlagworte tippen muss.

Akzeptanzkriterien

Die Story sagt, was jemand will. Die Akzeptanzkriterien sagen, woran man erkennt, dass es erfüllt ist. Sie sind kein Nachgedanke, sondern der Vertrag zwischen Product Owner und Team:

Akzeptanzkriterien:
- Ein Video kann beim Hochladen und nachträglich mit Schlagworten versehen werden.
- Mehrere Schlagworte pro Video sind möglich; Duplikate werden verworfen.
- Die Suche nach einem Schlagwort liefert alle Videos mit diesem Schlagwort.
- Ein Video ohne Schlagworte bleibt gültig und erscheint in der Liste.
- Schlagworte sind auf 30 Zeichen begrenzt; längere werden abgelehnt.

Beachtenswert: Die Kriterien nennen auch die Randfälle (keine Schlagworte, Duplikate, Längenbegrenzung). Genau dort entstehen später die Diskussionen darüber, ob etwas ein Fehler oder eine fehlende Anforderung ist.

Eine strengere Schreibweise, die sich später direkt in Tests übersetzen lässt:

Gegeben  ein Video ohne Schlagworte
Wenn     die Redakteurin das Schlagwort "Interview" hinzufügt
Dann     erscheint das Video in der Suche nach "Interview"

INVEST: die Qualitätsprüfung

Ob eine Story brauchbar ist, prüft man an sechs Eigenschaften:

Buchstabe	Bedeutung	Prüffrage
Independent	unabhängig	Lässt sie sich ohne eine andere Story umsetzen?
Negotiable	verhandelbar	Beschreibt sie das Ziel, nicht die technische Lösung?
Valuable	wertvoll	Merkt ein Nutzer, dass sie fertig ist?
Estimable	schätzbar	Weiß das Team ungefähr, was zu tun ist?
Small	klein	Passt sie in einen Sprint (Faustregel: in wenige Tage)?
Testable	testbar	Gibt es ein prüfbares Kriterium für “fertig”?

Die häufigsten Verstöße im Schulprojekt sind S und V: “Als Nutzer möchte ich eine Datenbank, damit die Daten gespeichert werden” ist zu groß und für keinen Nutzer sichtbar. Das ist keine Story, sondern eine technische Aufgabe. Solche Aufgaben darf es geben - sie heißen dann eben Task und hängen an einer Story, statt sich als eine zu verkleiden.

Wenn eine Story zu groß ist

Große Stories (Epics) werden zerlegt, aber entlang des Nutzens, nicht entlang der Technik. Falsch: “Backend bauen”, “Frontend bauen”, “Tests schreiben” - keine dieser drei liefert für sich etwas Brauchbares. Richtig: “Ein Schlagwort hinzufügen”, “Nach einem Schlagwort suchen”, “Ein Schlagwort entfernen” - jede ist für sich fertig und vorführbar.

Das Backlog

Das Product Backlog ist die geordnete Liste aller Wünsche an das Produkt. Zwei Eigenschaften sind wichtig und werden gern übersehen.

Erstens: Es ist geordnet, nicht nur gesammelt. Es gibt keine drei Stories mit “hoher” Priorität - es gibt eine erste, eine zweite und eine dritte. Wer alles wichtig findet, hat nicht priorisiert, sondern die Entscheidung verschoben.

Zweitens: Es ist oben fein und unten grob. Was als Nächstes kommt, ist klein geschnitten, geschätzt und mit Akzeptanzkriterien versehen. Was in drei Monaten kommen könnte, darf ein Halbsatz sein. Alles gleich detailliert auszuarbeiten ist verschwendete Arbeit, weil sich die Hälfte davon ändert.

Für die Priorisierung genügt im Schulprojekt eine einfache Einordnung nach Wert und Aufwand:

	geringer Aufwand	hoher Aufwand
hoher Wert	sofort machen	planen und zerlegen
geringer Wert	nebenbei, wenn Platz ist	streichen

Das rechte untere Feld ist das interessante: Aufgaben mit geringem Wert und hohem Aufwand kommen in fast jedem Projekt vor, und sie werden fast nie gestrichen, sondern immer weiter verschoben. Sie zu streichen ist eine Entscheidung; sie zu verschieben ist keine.

Eine verbreitete Ergänzung ist MoSCoW: Must have, Should have, Could have, Won’t have (this time). Die vierte Kategorie ist die wichtigste, weil sie das explizite Nein festhält - und damit die Diskussion beendet, statt sie im nächsten Sprint zu wiederholen.

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.

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.

Das Verfahren dazu 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.

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.

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 - sie legt fest, was zu “fertig” alles gehört.

Der Optimismus. Geschätzt wird der Fall, in dem nichts dazwischenkommt. Es kommt aber immer etwas dazwischen.

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.

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.

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

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?

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.

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 hinzufuegen"] --> B["Branch<br/>42-add-tags"]
  B --> C["Merge Request<br/>Closes #42"]
  C --> D["Review und Merge"]
  D --> E["Issue schliesst automatisch"]

Praktisch heißt das:

• Jede Story ist ein Issue mit Akzeptanzkriterien als Checkliste.
• Der Branch trägt Nummer und Kurztitel der Story (42-add-tags).
• Der Merge Request verweist mit Closes #42 auf das Issue; beim Merge schließt es sich selbst.
• Die Board-Spalten entsprechen dem tatsächlichen Ablauf (Backlog, Sprint, In Arbeit, Review, Fertig), nicht einem Wunschbild.

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 ist Product Owner (im Schulkontext oft die Lehrkraft oder ein Teammitglied mit dieser Rolle), wer moderiert den Prozess?

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.

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

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.

Lernergebnisse: Was Sie nach diesem Kapitel können sollten

Nach Abschluss dieses Kapitels sollten Schülerinnen und Schüler in der Lage sein:

• Anwenden: Anforderungen als User Stories mit Rolle, Wunsch, Nutzen und Akzeptanzkriterien formulieren.
• Analysieren: Stories anhand von INVEST prüfen und zu große Stories entlang des Nutzens zerlegen.
• Anwenden: ein Backlog ordnen und die Priorisierung nach Wert und Aufwand begründen.
• Erklären: den Zweck relativer Schätzung erklären, Planning Poker durchführen und Velocity zur Sprintplanung nutzen.
• Anwenden: eine Definition of Done aufstellen und im Projekt anwenden.
• Anwenden: Board, Branch und Merge Request so verbinden, dass der Prozessnachweis nebenbei entsteht.
• Beurteilen: Retrospektiven-Ergebnisse in eine konkrete, überprüfbare Maßnahme überführen.

Passende Übungen

• Aufgabe 02 - Vom Wunsch zur Story
• Aufgabe 03 - Jahresprojekt: Sprint 0