Definition of Ready

Scrum selbst stellt keine festen Anforderungen an den Inhalt oder Aufbau einer User-Story. Für eine reibungslose Umsetzung im Team ist es jedoch wichtig, dass alle Teammitglieder ein gemeinsames Verständnis davon haben, was eine User-Story beinhalten sollte.

In diesem Dokument werden bewährte Praktiken und Empfehlungen für die Erstellung von User-Stories gesammelt, um die Anforderung des Kunden bestmöglich zu erfassen um dann Änderungen am Produkt möglichst effizient und effektiv umsetzen zu können.

Die klassische User-Story-Formel

Eine weit verbreitete Struktur ist das User-Story-Template:

Als [Rolle] möchte ich [Funktion], damit [Nutzen].

Beispiel:

*Als Tester möchte ich eine Liste aller fehlschlagenden Testfälle sehen, damit ich schneller die Ursache eines Fehlers analysieren kann.

Diese Struktur hilft, den Fokus auf den Nutzen des zu entwickelnden Features aus Sicht des Endbenutzers zu legen.

Akzeptanzkriterien definieren

Akzeptanzkriterien sind Bedingungen, die erfüllt sein müssen, damit die Story als „done“ gilt. Sie machen die Anforderungen messbar und testbar.

Beispiel::

  • Es gibt eine Filterfunktion, um nach fehlgeschlagenen Testfällen zu suchen.

  • Die Liste zeigt das Datum, den Fehlercode und eine kurze Beschreibung.

  • Die Liste wird automatisch aktualisiert, wenn neue Fehler auftreten.

INVEST-Kriterien für gute User-Stories

Das INVEST-Prinzip stellt sicher, dass eine Story gut geschnitten und umsetzbar ist:

  • Independent – Unabhängig von anderen Stories

  • Negotiable – Verhandelbar, nicht bis ins Detail festgelegt

  • Valuable – Liefert einen klaren Nutzen

  • Estimable – Kann realistisch geschätzt werden

  • Small – Klein genug für eine Umsetzung in einem Sprint

  • Testable – Klare Akzeptanzkriterien zur Überprüfung