User Stories und Akzeptanzkriterien: Anforderungen verständlich formulieren

Kurz: Eine User Story beschreibt eine Anforderung aus Sicht des Nutzers in einem Satz; Akzeptanzkriterien legen fest, wann sie als erfüllt gilt.

Genauer: Lange Pflichtenhefte werden oft nicht gelesen. Agile Teams schreiben Anforderungen als kurze Geschichten, die Nutzen und Zweck zeigen und im Gespräch konkretisiert werden.

Im Detail

Das Format

Als möchte ich , damit . Beispiel: „Als Kundin möchte ich meine Bestellung per E-Mail bestätigt bekommen, damit ich weiß, dass sie angekommen ist.“ Die drei Teile beantworten Wer? Was? Warum? Das „damit“ verhindert Funktionen ohne Zweck. Die Geschichte ist kein vollständiger Vertrag, sondern ein Anlass zum Gespräch.

Gute Stories: INVEST

• Independent (unabhängig)
• Negotiable (verhandelbar)
• Valuable (wertvoll für Nutzer/Kunde)
• Estimable (schätzbar)
• Small (klein genug für einen Sprint)
• Testable (prüfbar) Zu große Stories („Epics“) werden in kleinere zerlegt.

Akzeptanzkriterien

Sie beschreiben konkret, wann die Story fertig ist, am besten im Format Given – When – Then:

• Gegeben der Warenkorb ist nicht leer, wenn ich bezahle, dann erhalte ich eine Bestätigungs-E-Mail mit Bestellnummer.
• E-Mail kommt innerhalb von 5 Minuten; enthält Artikel, Summe, Lieferadresse.
• Bei ungültiger E-Mail-Adresse wird eine Fehlermeldung angezeigt. Sie sind prüfbar (ja/nein), vollständig genug und bilden die Grundlage für Tests (siehe BDD) und die Abnahme.

Einbettung im Projekt

Stories stehen im Product Backlog, werden priorisiert und im Sprint umgesetzt. Die Definition of Done (DoD) gilt für alle Stories (Code reviewt, Tests grün, dokumentiert, deployt), die Akzeptanzkriterien für eine Story. In der IHK-Dokumentation kannst du Anforderungen als User Stories mit Kriterien darstellen und Lasten-/Pflichtenheft ergänzen. Ergänzend: Use-Case-Diagramme, Prototypen, Skizzen.

Siehe auch: Agile Methoden, Lastenheft und Pflichtenheft, BDD, Abnahme und Übergabe