Blog

User Stories sind ein grundlegendes Werkzeug in der agilen Produktentwicklung, das dazu dient, die Anforderungen aus der Perspektive der Endnutzer:innen zu beschreiben und den Mehrwert oder das Ziel hinter einer Funktion zu verdeutlichen. Dabei stehen nicht die technischen Details, sondern die Bedürfnisse und Ziele der Nutzer:innen im Mittelpunkt.

Wozu User Stories nutzen?

User Stories fördern die ständige Innovation, indem sie den fachlichen Kontext für Entwickler:innen verständlich machen und gleichzeitig Raum für kreative Lösungsansätze lassen. Sie dienen auch als Kommunikationstool im Team, um gemeinsam über Nutzerprobleme und -lösungen zu diskutieren.

Wo werden User Stories verwendet und wo nicht?

Agile Teams verwenden User Stories, um die Wünsche und Bedürfnisse von Nutzer:innen zu beschreiben und besser einschätzen zu können, besonders im Rahmen von Scrum und Kanban. Sie können auf physischen Karten, Haftnotizen oder in Projektmanagement-Software wie Jira erstellt werden. Der Product Owner ist in der Regel für die Qualität der Stories verantwortlich, während das gesamte Team sie während der Discovery und Delivery nutzt.

User Stories schreiben in 3 Schritten:

1. Persona/Kundentyp – WER: Beschreibung des Endnutzers/der Endnutzerin.
   • Identifizierung der Zielgruppe und ihrer Merkmale.
   • Beschreibung der Person und ihrer Bedürfnisse.
   • Beispiel: „Als Datenerfasserin, die täglich viele Dateien anlegt…“
2. Bedürfnis/Anforderung – WAS: Ziel der Softwarefunktion; was die Funktion erreichen soll für den Nutzer/die Nutzerin.
   • Beschreibung des gewünschten Ergebnisses oder Mehrwerts für den Nutzer.
   • Beispiel: „…möchte ich Dateien duplizieren, damit ich Daten schneller erfassen kann.“
3. Zweck – WARUM und WOZU: Ziel des Nutzers/der Nutzerin bei der Verwendung der Funktion.
   • Klärung des Zwecks und Nutzens der Funktion für den Nutzer.
   • Beispiel: „…damit ich Daten schneller erfassen kann.“

User Stories formulieren und prüfen:

User Stories sollten gemäß der INVEST-Regel und den „3 Cs“ formuliert und geprüft werden.

• INVEST-Regel:

  • Independent (Unabhängig): Jede User Story sollte in sich abgeschlossen und unabhängig von anderen Aufgaben sein.
  • Negotiable (Verhandelbar): User Stories sollten Raum für Diskussionen und Anpassungen bieten, ohne bereits eine Lösung vorzugeben.
  • Valueable (Wertvoll): Jede User Story sollte einen klaren Wert für das Produkt oder den Nutzer liefern.
  • Estimable (Abschätzbar): Die Aufwände für die Umsetzung einer User Story sollten einschätzbar sein.
  • Small/Sized appropriately (Überschaubar): User Stories sollten klein genug sein, um innerhalb eines Sprints umgesetzt werden zu können.
  • Testable (Prüfbar): Jede User Story sollte testbar sein, um sicherzustellen, dass das gewünschte Ergebnis erreicht wurde.

• 3 Cs:

  • Card (Karte): Die User Story sollte kurz und prägnant formuliert sein und auf eine Karte passen.
  • Conversation (Konversation): Jede User Story sollte zu einer Konversation zwischen Team und Kunde führen, um den Kontext und die Anforderungen zu klären.
  • Confirmation (Bestätigung): Verbindliche Akzeptanzkriterien sollten vereinbart werden, um sicherzustellen, dass die User Story erfolgreich umgesetzt wurde.

Job Stories als Alternative:

Job Stories sind eine Alternative zu User Stories und fokussieren sich auf den „Job-to-be-done“. Sie beschreiben, was Nutzer:innen erreichen möchten, unabhängig von ihrer persönlichen Identität.

Beispiel einer Job Story:

Technische Stories:

Technische Stories beschreiben technische Aufgaben, die keinen direkten Nutzen für Nutzer:innen haben, aber für die Softwareentwicklung wichtig sind. Sie helfen dabei, den technischen Kontext für die Business-Seite verständlich zu machen und gemeinsam über Prioritäten zu entscheiden.

Beispiel einer Technischen Story: