Wie detailliert muss eine User Story geschrieben sein?

Pauschal kann man sagen:
Grade so detailliert, dass das Team offene Fragen während des Sprints, in dem die Story umgesetzt wird, rechtzeitig klären kann.
Das hängt also auch von den vorhandenen Skills im Team ab. Wenn z.B. kein Konzepter-Skill im Team vorhanden ist, dann muss das UI/UX-Konzept im Vorfeld erstellt werden. Auch dann, wenn es so umfangreich ist, dass es in dem Sprint nicht rechtzeitig genug fertiggestellt werden kann, um die Folgetätigkeiten auch noch abzuschließen.

Verwandte Artikel:

Wie schätzt man nichtfunktionale Stories in Storypoints / Funktionspunkten ab?

Teams, die User Stories üblicherweise in Storypoints abschätzen die auf Funktionalität statt auf Aufwand beruhen, kommen bei der Abschätzung von Stories ins Strudeln, die keinen funktionalen Charakter haben.

Das könnten z.B. längere Analysestories sein, oder das Austauschen eines Quellsystems gegen ein anderes.

Zu überlegen ist dabei, ob diese Stories denn überhaupt Punkte bekommen sollten. Oder ob Analysetätigkeiten einfach die Velocity senken. Wenn über die Velocity der fachliche Fortschritt gemessen werden soll, erscheint das passender. Wenn es Gründe für eine Abschätzung gibt, kann man die Frage stellen: Um welchen Wert würde die Velocity im Sprint absinken?

Bei technisch motivierten Stories, wie z.B. der Austausch eines Quellsystems gegen ein anderes, kann man die Funktionsänderung an der Schnittstelle abschätzen. In dem Fall ist es nicht die Funktion, die der User sieht, sondern der Entwickler bzw. das eigene System. Vielleicht lässt sich auch feststellen, welche Funktionen für den User gleich bleiben müssen und das sind dann die abzuschätzenden Funktionen. Das mag auf den ersten Blick zu viel erscheinen, andererseits müssen diese Funktionen getestet werden und je nach Änderung des Quellsystems müssen auch einige Businessobjekte oder gar Abläufe geändert werden. Das Risiko des Unbekannten ist mit einer höheren Abschätzung besser abgedeckt, als mit einer geringen.

Verwandte Artikel:

Zwei User Story Beispiele

Ein einfaches Beispiel

Überschrift: Anwendung starten

Story: Als Autor möchte ich nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen, um Zeit zu sparen.

(Quelle: Wikipedia)

Ein ausführlicheres Beispiel

Überschrift: Datenschutzerklärung System Sales Assistant

Story: Jeder Anwender der Anwendung muss vor der Verwendung personenbezogener Daten bestätigen, dass er die Datenschutzerklärung beachtet, um den rechtlichen Anforderungen des Datenschutzgesetz §4711 zu genügen.

Akzeptanzkriterien:

  • Bei jeder Anmeldung am System wird eine Textinformation angezeigt, die bestätig werden muss. Maximal jedoch einmal je Benutzer und Quartal.
  • Wenn der Anwender die Information nicht bestätigt, beendet sich die Anwendung.
  • Die Textinformation muss durch eine Person in der Rolle „Betrieblicher Datenschutzbeauftragter“ ohne neue Distribution der Anwendung redaktionell gepflegt werden können.

Folgendes ist nicht angefordert:

  • Die Textinformation muss nicht archiviert werden.
  • Die Bestätigungen müssen nicht gespeichert oder weitergemeldet werden.

Bemerkungen zu den Beispielen

  • Die Überschrift erleichtert das optische Auffinden in einem Stapel von User Stories. Unabhängig davon, ob sie an der Wand hängen, oder in einem elektronischen System wie z.B. Jira.
  • Das einfache Beispiel funktioniert gut für Teams, die schon lange zusammen an den Produkt arbeiten und großes Domainenwissen haben. Ein neu gegründetes Team benötigt i.d.R. mehr Spezifikationen.
  • Der Detailgrad einer User Story wächst mit der Zeit. Zur Releaseplanung und Priorisierung gibt es nur einfache Stories Sätze / Epics / Features, aber dafür decken diese möglichst vollständig den Release Umfang ab.
  • Nach erster Priorisierung werden die Stories für die kommenden 2-3 Sprints in Product Backlog Refinement Workshops detailliert, so dass zum Sprint Planning I schon einige der Punkte vorhanden sind:
  • Überschrift
  • User Story
  • Akzeptanzkriterien
  • Abschätzung in Story Points
  • Ermittlung und Klärung technischer sowie organisatorischer Abhängigkeiten

Bei Bedarf noch

  • Nicht-Anforderungen
  • Funtionale Ablaufdiagramme
  • UX-Design / Kreativ Konzept / Wire Frames
  • Vermaßtes UI-Design
  • Testfälle

Das hilft dem Team dabei, die Story auch wirklich in einem Sprint umsetzen zu können.

Verwandte Artikel: