Product Backlog Items müssen nicht in User Stories formuliert werden, aber User Stories entsprechen einer Syntax, die hilft schnell und unkompliziert das Backlog Item zu formulieren.
Der Aufbau einer User Story hilft dem Product Owner klar verständliche Backlog Items zu formulieren und das Development Team versteht schneller, um was es hauptsächlich geht.
Als [ROLLE] möchte ich [ZIEL DER AKTION/HANDLUNG], um [GEWÜNSCHTER NUTZEN]
Als Neu-Kunde möchte ich mich Scrum Master Online Kurs registrieren, um mich auf die Scrum Master Prüfung vorzubereiten.
Der Product Owner formuliert die Wünsche der Nutzer in User Stories. Die User Stories beschreiben den Nutzen aus der Sicht des Nutzers und fokussiert sich auf die Zielerreichung (Zielsetzung für die Nutzung) und nennt die Handlung für die Zielerreichung.
In Scrum geht es darum, dass mit jedem Product Backlog den Nutzen zu erhöhen, und damit auch den Wert des Product Increments. Deshalb passt das Formulieren von Backlog Items als User Story so gut.
Viele Backlog Items werden in User Stories formuliert, da damit die Anforderungen der Kunden an der Lösung beschrieben präzise beschrieben werden können.
Die Entwickler erfahren durch den Aufbau der User Story, was der Auftraggeber oder die Nutzer möchten und warum dieses benötigt wird.
Der Product Owner erfasst Anforderungen an das Produkt aus der Nutzersicht. Dabei ist diese bewusst kurz gehalten und ist in der Regel nur 1-2 Sätze lang.
In der Regel ist der Kunde der Autor. In der Praxis ist der Product Owner vertritt der Product Owner sehr oft die Kundenseite. Es gibt Projekte, welche von externen Partner mit eigenem Product Owner umgesetzt werden. Hier ist es ein Mix, und die User Stories des Kunden, werden oft übernommen. Diese sind in diesen Situationen in der Regel aber eher als epische Anforderungen formuliert. Wenn dies der Fall ist, bricht der umsetzende Product Owner die User Story in kleinere Backlog Items auf (Dekomposition). Dabei kann, muss aber nicht, jedes Backlog Item, welches durch das Aufbrechen entstanden ist, ebenfalls eine User Story sein.
User Stories sind nicht offiziell ein Scrum Werkzeug. Der Scrum Guide sieht nur das Erstellen von Backlog Items vor. Wie diese aussehen ist dem Scrum Team überlassen. Lediglich die Mindestanforderung an das Backlog Item ist im Scrum Guide beschrieben (Beschreibung, Reihenfolge und Größe).
User Stories geben keine technische Lösung oder Umsetzung vor. Das bestimmen die Entwickler. Sondern beschreiben eine Anforderung an die Lösung.
Die Lösung wird in Epics gruppiert. Die Epics werden in User Stories aufgeteilt. Diese beiden beschreiben die Anforderungen. Diese werden durch den Product Owner verantwortet.
Epic, können auch Use Cases sein, die im Gegensatz zur User Story mehrere Szenarien enthalten können. Epics werden im Scrum Guide nicht gefordert. Product Backlogs die noch nicht verfeinert sind, und vom Aufwand sehr hoch und umfangreich erscheinen, werden oft Epics genannt.
Die Tasks für die Umsetzung der Story vermitteln die notwendigen Arbeitsschritte des Development Teams. Diese werden durch das Development Team erstellt und verwaltet.
Dieses System ist nicht starr. Eine Lösung kann auch eine Mischung von Epics und Stories enthalten. Der Epic und die Story entsprechen einem Backlog Item in Scrum. Backlog Items, die ein Epic darstellen sind in der Regel nicht klein genug, um in einem Sprint umgesetzt werden zu können.
Durch die Refinement Meetings werden die großen (epischen) Backlog Items immer feiner aufgebrochen. Die Formulierung der Epics kann als Wort, Satz oder auch wieder als User Story gemacht werden. Da gibt es keine festen Regel.
Tasks selbst, können auch wiederum in Sub-Tasks aufgeteilt werden, wenn dies das Development Team für nötig erachtet.
Nutzen Sie die INVEST Kriterien, um zu erkennen, ob die Qualität einer User Story ausreicht. Je besser die User Story, desto weniger Zeit wird benötigt, um das gewünschte Ergebnis im Team zu besprechen und zu planen.
Das hier geschriebene gilt auch für Product Backlog Items im Allgemeinen.
Die User Story sollte möglichst unabhängig von anderen User Stories sein. Die Umsetzung der User Story sollte nicht, das gleichzeitige umsetzen einer anderen User Story zwingend vorsehen. Sollten viele User Stories abhängig von einander sein, dann deutet dies darauf hin, dass hier horizontal verfasst wird, wie im Wasserfall.
Oft kann man nicht alle User Stories wirklich unabhängig halten, aber die Mehrheit der User Stories sollten dies sein.
Die User Stories enthalten keine Anforderungen an die Umsetzung. Auch der Umfang sollte nicht festgelegt werden. Damit erhalten Product Owner Spielräume für Release-Termine und das Development Team kann die Umsetzung besser auf das aktuelle Product Increment einpassen.
Hier ist klar die Verhandelbarkeit im Team über Umfang und Umsetzung gemeint.
Die Backlog Items sollten immer einen Mehrwert für das Produkt, und damit auch für den Kunden generieren. Ist dieser Nutzen klar ersichtlich? Ist der Nutzen für den Nutzer auch sinnvoll? Der Product Owner kann diesen Nutzen auch für die Priorisierung der Backlog Items nutzen.
Die Arbeit für das Product Backlog Item wird durch das Development Team geschätzt. Ist das Development Team in der Lage anhand der User Story den Aufwand zu schätzen?
In Refinement Meetings kann hier eventuell darüber verhandelt werden, was genau umgesetzt werden sollte (Negotiable), um den Aufwand im sinnvollen Rahmen zu halten.
Je weiter oben im Product Backlog ein Backlog Item steht, desto kleiner wird es in der Regel sein. Denn es muss in einem Sprint umsetzbar sein. Hier hilft dem Product Owner die Schätzung des Development Teams weiter. Unter Umständen, wird dieses Backlog Item erneut aufgeteilt oder dahingehend verfeinert, dass es passt.
Für das Umsetzen werden Kriterien benötigt, die klar vorgeben, ob das Backlog Item fertig umgesetzt wurde. Diese Kriterien können aus der Definition of Done stammen und bedürfen dann keine eigene Erwähnung. Doch versteht man aus der Formulierung der User Story auch, wie der Tester oder Nutzer das Ergebnis testen könnte?
Es ist möglich weitere Akzeptanzkriterien an das Backlog Item zu hängen. Diese werden zusätzlich zur User Story angegeben. Diese Akzeptanzkriterien können ebenfalls in User Story Form verfasst werden. Es gibt auch andere Syntax-Formen für Akzeptanzkriterien, wie Gherkin Syntax.
Die Story Card enthält die vollständige User Story mit weiteren Anforderungskriterien (wenn nötig und sinnvoll), sowie die Akzeptanzkriterien. Das könnte man als die geforderte Beschreibung aus dem Scrum Guide ansehen.
Zusätzlich gehört auch auf die Story Card die Reihenfolge (Priorisierung) und die Größe. Die Story Card kann man als Backlog Item verstehen.
Sie dient also der Kommunikation zwischen Umsetzern und Anforderung. Man kann diese als Notizzettel erstellen oder mit komplexen Software-Tools bauen. Dies ist jedem Scrum Team selbst überlassen und richtet sich oft an die gelebten Gepflogenheiten des Unternehmens.
Gerade die Akzeptanzkriterien geben Aufschluss darüber, wie die fertige Story getestet werden wird. Und dies kann die Umsetzung entsprechend leiten. Hier erfolgt in direkter Kommunikation zwischen Development Team und Product Owner eine Klärung der Ziele – typischerweise in Refinement-Meetings.
Eine User Story ist eine gute Methode, um Product Backlog Items zu erstellen. Sie bietet viele Vorteile für die Kommunikation zwischen dem Development Team und dem Product Owner. Dazu fördert sie das Verständnis warum dieses Backlog Item benötigt wird und lenkt damit einfacher die Umsetzung in die erwartete Richtung.
Die Syntax ist schnell erlernt und hilft dem Product Owner Backlog Items unabhängiger von anderen Backlog Items zu verfassen. Alle bekommen einen besseren Eindruck, wie die angestrebte Lösung genutzt wird.
(PDF 1.612KB)
Sie erhalten eine E-Mail mit dem Download für ein PDF mit 100 prüfungsnahen Fragen für die Scrum Master Prüfung.
