a
HomeAgile VorgehensweisenWas ist eine User Story in Scrum?

Was ist eine User Story in Scrum?

Wie sieht so eine User-Story aus?

User Stories sind in Scrum die visuelle Form für eine Anforderung im Product Backlog. Dabei versucht eine User Story dies mit einem aussagekräftigen Satz zusammenzufassen, damit das Entwicklungsteam genügend fachliche Informationen besitzt, um Anforderungen umsetzen zu können. Beispiel:

„Als Rolle möchte ich um das Ziel zu erreichen, so dass ich den Nutzen dadurch habe.“

Dabei ist der Schluss der User Story der wirklich wichtigste Teil. Denn dieser beschreibt den Nutzen und damit die Berechtigung für die Anforderung. Achte deshalb vor dem nächsten Sprint darauf, dass dieser Teil aussagekräftig genug ist, sonst kann es passieren, dass das dein Team die Story nicht in den Sprint aufnehmen wird, egal wie wichtig diese für den Product Owner ist.

Wenn du Mitglied des Entwicklungsteams bist, empfehle ich dir/euch, User Stories, die keine aussagekräftige Nutzenaussage besitzen, nicht mit in den Sprint aufzunehmen.

Die INVEST-Kriterien

Was meint dieses Akronym?

  • Independent (unabhängig)
  • Negotiable (verhandelbar)
  • Valuable (werthaltig)
  • Estimable (schätzbar)
  • Small (klein genug)
  • Testable (testbar).

Unabhängig“ meint, dass eine User Story eine in sich abgeschlossene Anforderung sein muss. Das heißt, dass jede User Story für sich selber umgesetzt werden kann, ohne auf die Beendigung einer anderen User Story zu warten oder selbst Basis für eine andere User Story zu sein.

Verhandelbar“ bedeutet, dass eine Anforderung bis zu dem Zeitpunkt, wo eine User Story fix in einem Sprint Backlog aufgenommen wurde, veränderbar sein muss. Bis zu diesem Zeitpunkt können Backlog-Elemente jederzeit verändert oder umgeschrieben werden. Den Vorgang des Änderns nennt man auch „Grooming“.

Werthaltig“ bezieht sich auf den Business Value. Eine User Story muss dem Nutzer / Anwender einen konkreten Mehrwert liefern. Das bedeutet automatisch, dass jede User Story den Business Value des Produktes erhöhen muss.

Schätzbar„: Eine User Story muss schätzbar sein und ist eine zentrale Anforderung für das Entwicklungsteam. Nur so kann das Team festlegen wie viele und welche User Stories es in einen Sprint aufnehmen kann. Deshalb muss der Product Owner eine User Story so beschreiben, dass die Komplexität vom Team abgeschätzt werden kann. Entscheidend für die Planung eines Sprints ist auch die Größe einer User Story. Eine User Story sollte so klein wie möglich sein. Nur so ist es dem Team möglich, mit einer gewissen Zuverlässigkeit den Sprint zu planen.

Testbarkeit„: Testbarkeit bezieht sich auf Umsetzung einer User Story. Eine User Story sollte so beschrieben sein, dass es nach Umsetzung der Anforderung möglich ist, das Ergebnis zu testen.

Die Akzeptanzkriterien

Für den Product Owner wichtigste Bestandteil einer User Story sind die Akzeptanzkriterien. Während die Formulierung einer User Story lediglich eine Kurzbeschreibung der Anforderung ist, sind die Akzeptanzkriterien wie KPIs zu betrachten, mit denen überprüft werden kann, wann eine Anforderung als umgesetzt gilt (Definition of Done).

Akzeptanzkriterien werden darüber hinaus für das Schätzen der Komplexität einer User Story verwendet. Sie geben dem Entwicklungsteam entscheidende Hinweise und Anhaltspunkte, wie hoch der Grad der Komplexität ist.

Teile bitte diesen Inhalt mit:
Bewerte bitte den Inhalt
Keine Kommentare.

Hinterlasse doch ein Kommentar

* Die Checkbox für die Zustimmung zur Speicherung ist nach DSGVO zwingend.

Ich stimme zu.