Wie schreibst du gute User Stories?

Das Standard-Format

Als [Rolle] möchte ich [Funktion], damit [Nutzen]. Beispiel: Als Kunde möchte ich meinen Warenkorb speichern, damit ich später bestellen kann. Drei Teile: Wer ist beteiligt (Persona-Bezug)? Was wird gewünscht (Funktion)? Warum (Nutzen)? Der Nutzen-Teil ist der wichtigste, er rechtfertigt die Story.

Akzeptanz-Kriterien

Pro Story 3-5 Kriterien, die testbar definieren, wann die Story erfüllt ist. Format: Given/When/Then oder einfache Liste. Beispiel: Warenkorb bleibt 30 Tage gespeichert. Warenkorb wird bei Login automatisch geladen. Leerer Warenkorb wird nicht gespeichert. Diese Kriterien sind Vertragsteil zwischen Team und Product Owner.

INVEST-Kriterien

Gute User Stories sind: Independent (von anderen Stories unabhängig), Negotiable (Detail verhandelbar), Valuable (echter Wert), Estimable (schätzbar), Small (passt in einen Sprint), Testable (überprüfbar). Wer eine Story schreibt, die nicht INVEST-konform ist, sollte sie aufteilen oder neu formulieren.

Stories vs. Tasks

User Stories beschreiben Kundennutzen. Tasks beschreiben technische Umsetzung. Beispiel: Story = Als Kunde möchte ich… Tasks = Datenbankschema anpassen, API-Endpunkt bauen, UI-Komponente entwickeln. Stories gehören in Product Backlog, Tasks in Sprint Backlog. Diese saubere Trennung verhindert, dass Backlog mit Technik-Details überfrachtet wird.