4. Agiles Arbeiten I – User Stories und Backlog

Nach diesem Kapitel kannst du:

• Anforderungen als User Stories mit Rolle, Wunsch, Nutzen und Akzeptanzkriterien formulieren.
• User Stories mit INVEST prüfen, von technischen Aufgaben unterscheiden und zu große Stories entlang des Nutzens zerlegen.
• ein Backlog ordnen und die Priorisierung nach Wert und Aufwand begründen.

Kapitel 02 hat beschrieben, wie agile Verfahren aufgebaut sind. Dieses Kapitel und die drei folgenden bringen 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?

Ein Vorhaben, das du gerade selbst planst, hat genau dieselbe Struktur: die Matura-Vorbereitung. Du hast eine lange Stoffliste, zu wenig Zeit für alles, Kapitel von sehr unterschiedlicher Größe und irgendwann die Frage, ob ein Kapitel „sitzt”. Wer dafür eine geordnete Liste, eine ehrliche Schätzung und ein klares Kriterium für „fertig” hat, arbeitet bereits agil, nur ohne die Fachbegriffe. Dieses Bild begleitet dich durch die Kapitel 04 bis 07.

flowchart LR
  A["Stoffliste für die Matura"] --- B["Product Backlog"]
  C["Integralrechnung ist doppelt so groß wie Folgen"] --- D["Story Points"]
  E["Kapitel pro Woche"] --- F["Velocity"]
  G["Kapitel sitzt erst, wenn ..."] --- H["Definition of Done"]

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

Begriffe vorab

• User Story: eine Anforderung aus Sicht einer Person, formuliert als Rolle, Wunsch und Nutzen.
• Akzeptanzkriterium (acceptance criterion): eine prüfbare Bedingung, an der man erkennt, dass eine bestimmte Story erfüllt ist.
• Product Backlog: die geordnete Liste aller Wünsche an das Produkt (aus Kapitel 02 bekannt).
• Story Point: eine einheitenlose Zahl für den relativen Umfang einer Story.
• Velocity: die Summe der Story Points, die ein Team pro Sprint tatsächlich fertigstellt.
• Definition of Done (DoD): die für alle Stories gleiche Liste dessen, was zu „fertig” gehört.
• Issue und Merge Request (MR): in GitLab der Eintrag für eine Aufgabe bzw. der Antrag, einen Branch nach einem Review in einen anderen zu übernehmen.

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 Nutzen als Prüfwerkzeug

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.

Ohne den dritten Teil wäre die Story nur „Als Redakteurin möchte ich Videos mit Schlagworten versehen”. Das ist technisch dieselbe Aufgabe, aber ohne den Maßstab, an dem sich eine billigere Alternative überhaupt erkennen ließe. Der Nutzen ist damit nicht nur Motivation, sondern ein Prüfwerkzeug gegen Überbau.

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.

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 lässt sich später direkt in Tests übersetzen (Kapitel 20):

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

Damit ist der Weg von der Anforderung zum Test vollständig. Jede Stufe macht die vorige prüfbarer:

flowchart LR
  S["User Story: Rolle, Wunsch, Nutzen"] --> K["Akzeptanzkriterien inklusive Randfälle"]
  K --> G["Gegeben - Wenn - Dann"]
  G --> T["automatischer Test (Kapitel 20)"]

Weiterlesen

• Wikipedia: User story - Herkunft und Varianten des Formats, inklusive der INVEST-Kriterien.
• Martin Fowler: User Story - kurz, warum eine Story ein Anlass für ein Gespräch ist und keine vollständige Spezifikation.

INVEST: die Qualitätsprüfung für Stories

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”?

Story oder technische Aufgabe?

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 Task und hängen an einer Story, statt sich als eine zu verkleiden.

	User Story	Task
Beschreibt	einen Nutzen für eine Person	einen technischen Arbeitsschritt
Beispiel	„… möchte ich nach einem Schlagwort suchen, damit …”	„Tabelle video_tags mit Index anlegen”
Vorführbar im Review	ja	nein, nur als Teil einer Story
Steht im	Product Backlog	Sprint Backlog, unter ihrer Story

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.

flowchart TD
  E["Epic: Schlagworte für Videos"]
  subgraph falsch["✗ nach Technik zerlegt"]
    T1["Backend bauen"]
    T2["Frontend bauen"]
    T3["Tests schreiben"]
  end
  subgraph richtig["✓ nach Nutzen zerlegt"]
    N1["Schlagwort hinzufügen"]
    N2["Nach Schlagwort suchen"]
    N3["Schlagwort entfernen"]
  end
  E --> falsch
  E --> richtig

Der Test für jedes Teilstück ist dieselbe Frage wie im Review: Lässt es sich allein vorführen? Links ist die Antwort dreimal nein, rechts dreimal ja.

Wo begegnet dir das? In den Issue-Listen großer Open-Source-Projekte auf GitLab oder GitHub. Gut gepflegte Projekte trennen dort Feature-Wünsche aus Nutzersicht sichtbar von technischen Aufgaben, oft mit eigenen Labels.

Kurz nachgedacht

Mach aus „Als Nutzer möchte ich eine Datenbank, damit die Daten gespeichert werden” eine echte User Story für eine Rezept-App. Welche INVEST-Eigenschaft erfüllt deine Version, die das Original verletzt?

Auflösung

Zum Beispiel: „Als Hobbykoch möchte ich ein Rezept speichern, damit ich es nach dem Schließen der App wiederfinde.” Die Datenbank ist jetzt ein Task unter dieser Story. Die neue Version ist Valuable (der Nutzer merkt, dass sie fertig ist) und Small (ein Rezept speichern statt „die Datenbank”). Sie ist außerdem Negotiable, weil sie offenlässt, wie gespeichert wird.

Das Backlog ordnen

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.

In der Matura-Analogie: Das Kapitel für nächste Woche hast du schon in Unterkapitel und Übungsaufgaben zerlegt. Für das Thema im April reicht vorerst die Überschrift auf der Stoffliste.

Nach Wert und Aufwand priorisieren

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

Eingetragen sehen ein paar Wünsche an die Medienverwaltung so aus:

quadrantChart
  title Wert gegen Aufwand
  x-axis geringer Aufwand --> hoher Aufwand
  y-axis geringer Wert --> hoher Wert
  quadrant-1 planen und zerlegen
  quadrant-2 sofort machen
  quadrant-3 nebenbei wenn Platz ist
  quadrant-4 streichen
  Schlagwort hinzufügen: [0.2, 0.85]
  Volltextsuche: [0.7, 0.8]
  Dunkles Farbschema: [0.25, 0.3]
  Videoschnitt im Browser: [0.85, 0.2]

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 ausdrückliche Nein festhält. Damit endet die Diskussion, statt sich im nächsten Sprint zu wiederholen.

Merksatz

Priorisieren heißt reihen und streichen - eine Liste, in der alles „hoch” ist, ist nicht priorisiert.

Wo begegnet dir das? In jeder Release-Ankündigung einer App, in der ein lange gewünschtes Feature „vorerst nicht geplant” ist. Das ist ein öffentlich gemachtes Won’t have (this time).

Weiterlesen

• Wikipedia: MoSCoW-Priorisierung - die vier Kategorien und typische Fehler bei ihrer Anwendung.

Zusatzmaterialien

• Jeff Patton, User Story Mapping - zeigt, wie einzelne Stories zu einem großen Ganzen zusammengesetzt werden, über das Ordnen des Backlogs aus diesem Kapitel hinaus.
• Wikipedia: User story - Herkunft und Varianten des Story-Formats, hilfreich, wenn du im Praktikum auf eine andere Schreibweise triffst.

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

• Anwenden: Anforderungen als User Stories mit Rolle, Wunsch, Nutzen und Akzeptanzkriterien formulieren.
• Analysieren: User Stories mit INVEST prüfen, von technischen Aufgaben unterscheiden und zu große Stories entlang des Nutzens zerlegen.
• Anwenden: ein Backlog ordnen und die Priorisierung nach Wert und Aufwand begründen.

Passende Übungen

• Aufgabe 02 - Vom Wunsch zur Story

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules