Was ist eine User Story in Scrum?

Die Anforderungen werden am besten als User Storys definiert. Sie werden in der Sprache des Kunden beschrieben. Es werden die Erwartungen des Kunden an das Produkt, den Service oder den Prozess beschrieben. Beispielsweise kann ein Nutzer über eine Suchmaske die Produktliste durchsuchen und bekommt ein Ergebnis. Technische Details und Prozesse werden weggelassen. In einer guten User Story muss das Wer, Was und das Warum geklärt werden. User Story's werden über ein Template beschrieben: Als ein <Typ von Nutzer (Kunde, Nutzer, Rolle); Wer>, möchte ich <ein Ziel (Funktion, Anforderung); Was> so dass / damit <Nutzen (Grund); Warum>. In einer User Story muss das Ziel klar kommuniziert sein. Als ein Nutzer, möchte dieser nach einer Kunden-ID suchen damit ein Kunde schneller gefunden werden kann. Diese Darstellung hilft den Stack Holdern das Bedürfnis des Kunden besser zu verstehen. Die User Story wird nach Priorität und Story Point sortiert. Die Priorität ist die Wichtigkeit und Wertschöpfung einer User Story und der Story Point der Aufwand zur Umsetzung einer User Story. Sollten User Stories umfangreicher sein so können Sie unterteilt und einen Epic zugeordnet werden. Sollte eine User Story noch umfangreicher werden so wird ein Theme definiert.

In Jira kann die Epic-Version folgendermaßen aktiviert und mit Create Epic erstellt werden.

Eine User Story kann einen Epic sodann folgendermaßen zugeordnet werden.

Eine technische Aufgabenbeschreibung könnte wie lauten: Implementation einer Möglichkeit zur Verteilung von E-Mails an verschiedene Empfänger. Mit der Sprachschablone würde Sie folgendermaßen in eine User Story überführt werden. Der Nutzer der App/Software für berufliche Zwecke, möchte die Möglichkeit haben, seine E-Mails an verschieden Empfänger zu versenden, damit er die E-Mail nur einmal formulieren muss und diese direkt weiteren Empfänger zukommen lassen kann (ohne diesen Vorgang mehrfach zu wiederholen und somit Arbeit und Zeit einsparen (Automatisierung);Ist optional; je nach Kontext).

Jede User Story ist erst abgeschlossen wenn es den Qualitätskriterien der Definition of Done genügt zum Beispiel:

• Code erstellt?
• Softwaredokumentation erstellt?
• Bedienungsanleitung erstellt?
• Tests erstellt und bestanden (z.B. Code Coverage)?

Eine User Story muss nach den INVEST Kriterien aufgebaut sein. Independent oder Unabhängig. Jede User Story muss klar von einer anderen User Story abgrenzbar sein. Negotiable oder Verhandelbar. Die User Story muss verhandelt und angepasst werden können solange Sie im Product Backlog ist. Valuable oder Wertschöpfend. User Stories müssen einen Mehrwert für den Nutzer generieren. Estimable oder Einschätzbar. Der Aufwand der User Story muss beim Sprint-Planning klar bestimmt werden können. Small oder Sizable oder Klein. Eine User Story muss innerhalb eines Sprints umgesetzt werden können, ansonsten sollte es als Epic definiert werden. Testable oder testbar. Die User Story muss getestet werden können.

Die Definition of Ready einer User Story definiert die Qualitätskriterien zur Beschreibung der User Story bevor diese im Sprint umgesetzt werden kann. Die Qualitätskriterien zur Beschreibung der User ist branchenabhängig und Scrum-Team abhängig. Das INVEST Akronyme kann herangezogen werden um Definition of Ready Qualitätskriterien zu definieren. Eine User Story ist unabhängig von anderen User Stories, Scrum-Teams oder weiteren Faktoren. Die User Story muss verhandelbar zwischen Entwicklungsteam oder Product Owner sein. Die Bewältigung der User Story muss einen Mehrwert erzeugen. Der Aufwand zur Umsetzung der User Story ist einschätzbar. Die User Story muss für Umsetzung in einen Sprint eine geeigneten Umfang und Größe haben. Die User Story muss testbar sein sodass die Definition of Done erfüllt werden kann.

Wenn die User Story zu komplex erscheint, können User Stories unterteilt werden. Die komplexe User Story ist dann die Epic welche den User Stories zugeordnet wird. Eine Epic kann eine Verallgemeinerung von User Stories sein, welches sich auf einzelne Nutzer bspw. von Betriebssystemen beziehen. Die Epic wird als User Story beschrieben welche einen generellen Nutzer beschreibt. Jede User Story muss der Definition of Done genügen.

Eine User Story kann eine User Story über Create Issue erzeugt werden. Es ist zudem möglich nicht nur eine Story sondern auch eine Task oder ein Bug zu erstellen.

Nach der Erstellung der User Story kann Sie einen Sprint zugeordnet werden.

Sodann kan der Sprint gestartet werden und die Sprintdauer als auch das Sprintziel definiert werden.