Anforderung aus Nutzersicht: 'Als [Rolle] möchte ich [Funktion], um [Nutzen]'.
Eine User Story beschreibt eine Anforderung aus der Perspektive des Nutzers im Format: Als [Rolle] möchte ich [Funktion], um [Nutzen]. Dieses Format zwingt dazu, jede Anforderung mit einem konkreten Nutzen zu verknüpfen, statt bloß technische Aufgaben zu formulieren. User Stories sind das gängigste Format für Product-Backlog-Items und machen Anforderungen für alle Beteiligten verständlich.
Ein gutes Beispiel: Als Kunde möchte ich Produkte nach Preis filtern, um schneller passende Artikel zu finden. Die Story benennt die Rolle, die gewünschte Funktion und den Grund. Im Refinement prüft das Team die Story anhand des INVEST-Akronyms: Ist sie unabhängig von anderen Stories, verhandelbar im Detail, wertvoll für den Nutzer, schätzbar im Aufwand, klein genug für einen Sprint und testbar? Wenn eine Story zu groß ist, wird sie in kleinere Stories zerlegt, die jeweils eigenständig Wert liefern.
User Stories gehen auf Kent Beck und Extreme Programming zurück. Das INVEST-Akronym stammt von Bill Wake. Wichtig ist, dass die Story selbst nur ein Gesprächsanlass ist. Die eigentliche Klärung findet in der Diskussion zwischen Product Owner und Team statt.
Methoden anwenden statt nur kennen. Trainings und Workshops ansehen
