User Story

Kein langes Lastenheft ("Das System muss..."). Sondern ein kurzer Satz auf einem Klebezettel/Ticket. Format: "Als [Rolle] möchte ich [Ziel], damit [Nutzen]." Beispiel: "Als Kunde möchte ich per PayPal bezahlen, damit ich meine Kreditkarten-Daten nicht eingeben muss." Es beschreibt das Was und Warum, nicht das Wie (Technik). Das Wie entscheiden die Entwickler.

Merksatz: Eine kurze, einfache Beschreibung einer Softwarefunktion aus der Perspektive des Endbenutzers, die den Mehrwert für diesen Benutzer in den Mittelpunkt stellt.

Die 3 Cs:

Card: Der Titel/Text (kurz).
Conversation: Das Wichtigste! Entwickler und Product Owner reden darüber ("Geht auch Apple Pay?").
Confirmation: Akzeptanzkriterien (Acceptance Criteria). Wann ist es fertig?
- "Button ist sichtbar."
- "Bei Klick öffnet sich PayPal."
- "Nach Zahlung kommt Erfolgsmeldung."

1. INVEST Kriterien (Gute Stories)

Independent: Kann unabhängig von anderen gebaut werden.
Negotiable: Ist verhandelbar (kein Befehl).
Valuable: Bringt dem User Wert.
Estimable: Kann geschätzt werden (nicht zu vage).
Small: Passt in einen Sprint.
Testable: Man kann prüfen, ob sie geht.

2. Gherkin Syntax (BDD)

Für Akzeptanzkriterien nutzt man oft Given-When-Then: GIVEN I am on the checkout page WHEN I click "Pay with PayPal" THEN I should be redirected to PayPal.com Das kann man automatisieren (Cucumber Tests).

3. Vertical Slicing

Wie schneidet man eine Story klein? Nicht horizontal ("Erst Datenbank, dann API, dann UI"). Das liefert keinen Wert. Sondern vertikal ("Ein rudimentärer PayPal-Button, der funktioniert"). Lieber eine dünne Scheibe Torte (Boden + Creme + Kirsche) als nur den Boden essen.

1. Story Mapping (Die Landkarte)

Statt einer langen flachen Liste (Backlog), nutzt man oft Story Mapping. Man ordnet Stories horizontal nach dem Zeitablauf ("User Flow"):

Suchen -> 2. In den Warenkorb -> 3. Bezahlen. Vertikal ordnet man sie nach Wichtigkeit. In der obersten Reihe liegen die absolut kritischen Stories für das MVP (Minimum Viable Product). So sieht das Team sofort: "Wir bauen gerade die fancy Wunschliste (Phase 3), obwohl die Bezahlung noch gar nicht geht!"

2. Definition of Ready (DoR) vs. Done (DoD)

Wann darf eine Story überhaupt "angefangen" werden?

DoR (Ready): Ist sie verständlich? Hat sie Akzeptanzkriterien? Ist sie geschätzt? Wenn nein, darf das Team sie im Sprint ablehnen.
DoD (Done): Ist sie programmiert? Getestet? Dokumentiert? Vom Product Owner abgenommen? Ohne eine klare DoD gibt es am Ende des Sprints Streit: "Der Code ist fertig!" – "Ja, aber wo sind die Tests?". Die DoD ist der Qualitätsvertrag des Teams.

3. User Personas

"Als Rolle..." ist oft zu abstrakt. Gute Teams nutzen Personas. Das sind fiktive Charaktere mit Namen, Alter und Bedürfnissen. "Als Rentner Herbert, der schlecht sieht..." führt zu einer Story über Schriftgröße. "Als Power-Userin Sarah, die nur die Tastatur nutzt..." führt zu einer Story über Shortcuts. Das hilft dem Team, echte Empathie zu entwickeln, statt nur technische Features abzuarbeiten.