28. Mai 2020
Unser Umgang mit User Stories

Posted at 10:07h in Insights by bhein

In der aktuellen Situation stellen wir die Werkzeuge, mit denen wir tagtäglich arbeiten auf den Prüfstand und bewerten ihre Alltagstauglichkeit im Homeoffice. Ein zentrales Element im Scrum sind User Stories. Im Folgenden möchten wir zeigen, was eine User Story für uns bei XITASO zu einer guten User Story macht und worauf es insbesondere in der aktuellen Situation ankommt.

Was sind User Stories und wie werden sie aufgebaut?

User Stories sind Nutzergeschichten. Der Product Owner beschreibt in einer User Story die Anforderungen aus Nutzersicht: Wie wünschen sich Anwender eine Software oder Kunden einen Liefergegenstand, um ihre Geschäftsziele zu erreichen.

User Stories bestehen aus wenigen, leicht verständlichen Sätzen. Sie sind kurz, aus Kundensicht jedoch spezifisch und detailliert. User Stories transportieren nicht nur Erwartungen an zukünftige IT-Systeme, sondern auch Anforderungen an Liefergegenstände, die agile Projekte realisieren. User Stories bewegen sich im Anforderungsraum, ohne in den Lösungsraum zu wechseln. Sie geben keine technischen Lösungen vor, die die Entwickler zum sturen Realisieren zwingen und unterscheiden sich somit von einer Spezifikation. ¹ ²

Eine User Story sollte einfach und leicht verständlich sein.

„Als [Nutzer] möchte ich [Funktion] um [Wert].“

Das heißt, eine User Story beantwortet die Fragen WER möchte WAS und WARUM:

[Nutzer] – Wer?
Der Platzhalter [Nutzer] wird mit Rollen bzw. Personas gefüllt. Eine Persona ist ein typischer Vertreter einer Zielgruppe. Die Rolle des Nutzers kann auch durch den jeweiligen Kontext definiert sein. So kann die gleiche Rolle z.B. für unterschiedliche Personas gelten und das Verhältnis zum Produkt beschreiben.

[Wert] – Warum?
Der Platzhalter [Wert] beantwortet die Frage nach dem WARUM. Auch wenn der Satzbau dazu verleitet diesen Nebensatz wegzulassen, ist eine User Story ohne diesen Zusatz nicht komplett.

[Funktion] – Was?
Der Platzhalter [Funktion] wird mit der Erwartung, den Zielen und Wünschen des [Nutzers] gefüllt. Damit beantwortet die Funktion die Frage, WAS der Kunde braucht und erwartet. Wenn das Produkt bereits am Markt angeboten wird, kommen sicher viele gewünschte Funktionen direkt vom Nutzer. In früheren Phasen eines Projektes können basierend auf der Erfahrung des Kunden bzw. des Product Owners und des Teams Annahmen formuliert werden, welche [Funktion] der [Nutzer] erwartet.

Das heißt, erst mit dem [Wert] wird zum Ausdruck gebracht, warum die Erreichung der [Funktion] für den [Nutzer] überhaupt wichtig ist und welchen Mehrwert die Erfüllung der User Story schafft. Spätestens an dieser Stelle bietet die User Story eine ehrliche Reflexion, wie gut man sich bereits mit den Anforderungen der Kunden auseinandergesetzt hat. Anforderungen aufzunehmen ist einfach (z.B. weil der Kunde nach einer Funktion schreit). Zu verstehen warum es für ihn wichtig ist, gibt dem Team aber erst den notwendigen Kontext. ³

So schreiben wir User Stories bei XITASO

Durch ihre leichte Verständlichkeit und den Fokus auf den Nutzer sind User Stories eine beliebte und vielfach eingesetzte Technik, um Einträge im Product-Backlos eines Scrum-Teams zu beschreiben. So verwenden auch wir bei XITASO in all unseren Scrum-Teams User Stories. Wie diese jedoch entstehen, wie sie aufgebaut sind und wie die Ausführung der skizzierten „Ideallösung“ tatsächlich aussieht, unterscheidet sich im täglichen Doing zwischen den einzelnen Teams und auch innerhalb eines Teams von Fall zu Fall.

So wird bei uns gerne in Abweichung zum klassischen Ansatz ein besonderer Fokus auf das „Warum“ der Anforderung in der User Story gelegt, indem das „Warum“ im Aufbau der User Story zuerst erläutert wird. Da das Team für das Kundenbedürfnis eine Lösung entwickeln soll, ist es von entscheidender Bedeutung, die Beweggründe oder die Problemstellung des Kunden genau zu kennen, um gegebenenfalls auch alternative Lösungsansätze, die wirkungsvoller oder günstiger sein können, anbieten zu können. Außerdem beginnt man durch das Voranstellen des „Warums“ bereits zu Beginn der User Story damit, sich in den Kunden hineinzuversetzen und sich somit die Anwenderbrille aufzusetzen.

Wir arbeiten bei XITASO nicht nur an neuen Softwareprodukten sondern auch an der Verbesserung bestehender Produkte. In diesem Fall beziehen sich die User Stories oft auf bereits vorhandene Funktionalitäten. So könnte eine User Story für einen bestehenden Onlineshop beispielsweise lauten: „Um die Bezahlung meiner Bestellung schnell und bequem abwickeln zu können, möchte ich als Kunde meine Kreditkarteninformationen mit meinem Account verknüpfen.“ Nun sind die Fragen beantwortet, wer, was, warum möchte. Allerdings bleibt offen, wie das aktuelle Verhalten ist. Kann der Kunde bisher gar nicht mit Kreditkarte zahlen oder ist das bereits möglich und der Kunde muss die Kreditkarteninformationen bei jeder Bestellung erneut eingeben? Je nach Ausgangslage verändert sich die Erwartungshaltung und die Dringlichkeit der Änderungen für den Kunden. Um nun ein besseres, gemeinsames Verständnis zu erreichen, was mit dieser User Story erreicht werden soll, hat es sich für uns als sinnvoll herausgestellt, solche Stories um einen „wohingegen aktuell“-Nebensatz zu erweitern, welcher das aktuelle, verbesserungswürdige Verhalten beschreibt: „Um die Bezahlung meiner Bestellung schnell und bequem abwickeln zu können, möchte ich als Kunde meine Kreditkarteninformationen mit meinem Account verknüpfen, wohingegen ich aktuell meine Kreditkarteninformationen bei jedem Einkauf erneut eingeben muss.“

Intensiv haben wir uns auch mit der Frage befasst, ob und in welchem Umfang Akzeptanzkriterien bei der Erstellung der User Story (vor-)formuliert werden sollten. Fest steht, dass die Akzeptanzkriterien im Dialog zwischen Entwickler und Product Owner festgelegt werden sollen. Aber werden die Akzeptanzkriterien aller anstehenden Stories tatsächlich während des Backlog Refinements formuliert? Oder kann es sinnvoll sein, dass der Product Owner bereits bei der Erstellung der Story gewisse Akzeptanzkriterien festhält, die dann während des Backlog Refinements diskutiert und verändert werden können? Unsere Erfahrung hat einerseits gezeigt, dass es von Vorteil sein kann, Akzeptanzkriterien bereits im Vorfeld zu formulieren, um die gewünschten Änderungen an ein größeres Team zu kommunizieren. Somit ist ein Rahmen für die Diskussion und Festlegung der Kriterien gegeben und während des Backlog Refinements kann Zeit gespart werden. Gegen dieses Vorgehen spricht allerdings, dass schriftlich formulierte Akzeptanzkriterien bereits eine Denkrichtung vorgeben und somit unter Umständen kreative Lösungen unterbinden. Es gilt also, die Zeitersparnis und die kreative Lösungsfindung gegeneinander abzuwägen. Ein Kompromiss könnte sein, dass der Product Owner sich bereits im Vorfeld die Akzeptanzkriterien überlegt hat, diese aber noch nicht an der User Story fixiert hat. So kann er im Laufe des Gesprächs mit seinen Notizen abgleichen und bei Bedarf seine Akzeptanzkriterien einfließen lassen.

Je nachdem in welchem Rollengefüge zwischen Auftraggeber/Kunden und seinem Team der Product Owner sich befindet, werden ihm die Erstellung der Produktvision und damit der kreative Part an der Erstellung der User-Stories komplett überlassen. Im Falle eines starken Visionärs auf Seite des Auftraggebers oder Kunden übernimmt der Product Owner eher die Aufgabe eines Requirement Engineers, der die Anforderungen in eine Form gießt, die zur agilen Software-Entwicklung passt und gegenüber seinem Dev-Team stellvertretend die Kundensicht und deren Produktvision vertritt. In letzterem Fall fehlt dem Product Owner in der Praxis häufig die Entscheidungskompetenz, um alle Rückfragen zu beantworten oder gar alternativen Lösungsvorschlägen seitens seines Teams ad hoc zuzustimmen. Es empfiehlt sich daher, die User Stories frühzeitig zu erstellen und im Teamgespräch vorzustellen. So bleibt vor Beginn der Realisierung genügend Zeit, um notwendige Klärungen mit Auftraggeber bzw. Kunden herbeizuführen.

Welche besonderen Anforderungen ergeben sich an die User Stories aus der Remote-Situation heraus?

Aktuell stellt die Corona-Krise auch unseren Berufsalltag vor neue Situationen und besondere Herausforderungen. Unter dem Gesichtspunkt wollen wir auch überprüfen, ob die User Story in einem Team, das nun komplett remote miteinander arbeitet, weiterhin geeignet ist bzw. angepasst werden sollte. Zu diesem Zweck treten wir einen Schritt zurück und stellen uns nochmal die Frage, welchen Zweck die User Story erfüllen soll. Die User Story soll dem Entwicklungsteam in wenigen Sätzen aus der Perspektive des Nutzers dessen Anforderungen an ein System vermitteln. Das erfüllt die User Story natürlich auch in der Remote-Situation. Der Product Owner nutzt die User Story zu Beginn des Plannings und zu Beginn des Refinements, um dem Team die Problemstellung zu erklären. Außerdem werden die User Stories im laufenden Entwicklungsprozess zu Rate gezogen, um sich nochmal Zusammenhänge einzelner Tasks ins Gedächtnis zu rufen bzw. beim Abschließen der Realisierung nochmal zu überprüfen, ob die Anforderung in allen Einzelheiten im Sinne des Nutzers erfüllt wurden. Insbesondere hier ist es von Vorteil, wenn die User Story etwas detailliert beschrieben wurde, da in der Remote-Situation nicht eben mal der Nachbar oder der in der Nähe sitzende Product Owner gefragt werden kann, ob man alles richtig verstanden hat.

Das richtige und vollständige Verstehen der User Story ist natürlich auch in den regelmäßigen Plannings und Refinements notwendig. Neben dem zusätzlichen Augenmerk auf eine höhere Detaillierung können weitere Tipps helfen, in diesen Meetings auch in der Remote-Situation optimale Ergebnisse zu erzielen. So sollte der Product Owner verstärkt auf die Mimik seiner Zuhörer achten. Ein Stirnrunzeln oder das Abschweifen des Blickes sind meist Hinweise darauf, dass der Zuhörer noch in Gedanken oder bereits abgehängt ist. Mit gezielten Nachfragen kann der Product Owner überprüfen, ob Verständnisfragen offen sind und deren Antworten in der User Story schriftlich festhalten.

Aus den Erfahrungen, die wir in Remote-Teams und insbesondere aus den letzten Wochen gesammelt haben, haben wir viele weitere Hinweise und Tipps abgeleitet, die wir in unserem Video-Podcast, Blog-Artikeln und der Webinar-Reihe Agile Wednesday gesammelt haben. Wir würden uns freuen, wenn wir euer Interesse geweckt haben und ihr demnächst mal wieder hier reinschaut.

Hier noch ein paar Tipps für gute User Stories

Card, Conversation und Confirmation

Ron Jeffries nennt drei kritische Aspekte, die beim Erstellen von User Stories beachtet werden sollten: Card, Conversation und Confirmation.

Card
Geschichten werden traditionell auf Karten geschrieben. Deshalb sollten sich Product Owner kurz fassen und nicht mehr Platz verbrauchen als es die Karte zulässt.

Conversation
Anforderungen sollten dem Entwicklerteam nicht „über den Zaun“ geworfen werden. Product Owner und Entwickler sollten miteinander über die Karten sprechen, um so das Verständnis aller Beteiligten zu schärfen. Denn der Teufel steckt im Detail. Erst im Gespräch zeigt sich, ob den Entwicklern wirklich klar ist, was sie bauen sollen. Entwickler und Product Owner sollen die Akzeptanzkriterien gemeinsam in einem Dialog festlegen. Wenn die Formulierung einer User Story vorliegt, werden die Entwickler den Product Owner in der Regel mit den Fragen konfrontieren, deren Antworten zu den Akzeptanzkriterien führen.

Confirmation
Eine User Story ist dann abgeschlossen, wenn die Akzeptanzkriterien erfüllt sind. Sie beschreiben, was von der Story erwartet wird, um sie als „fertig“ zu melden. Akzeptanzkriterien sind flexibel und werden bei Bedarf angepasst, bis das Team mit der Realisierung der User Story startet. Scrum Master und Entwicklerteam klären in Gesprächen, ob ein gemeinsames Verständnis besteht. So werden Missverständnisse vermieden, die im Nachgang zeitfressend ausgeräumt werden müssten. ¹

INVEST-Prinzip

Im besten Fall sollte jede fertige User Story nach dem INVEST-Prinzip geschrieben sein:

I (Independent): Sie ist nicht von einer anderen User Story abhängig.
N (Negotiable): Sie dient als Gesprächsgrundlage und kann gemeinsam weiterentwickelt werden.
V (Valuable): Sie stellt immer einen Vorteil für den User, Kunden oder Auftraggeber dar.
E (Estimatable): Sie hat so viel konkrete Details, dass ein erfahrenes Team deren Umfang schätzen kann.
S (Small): Sie hat die richtige Größe.
T (Testable): Sie beinhaltet genügend Informationen, um getestet werden zu können. ⁴

Weitere Tipps

Neben der INVEST-Eselsbrücke gibt es noch weitere Tipps zur Erstellung einer guten User Story:

Der Nutzer soll stets im Fokus stehen.
User Stories werden nicht von einer Person alleine erstellt – Teamarbeit ist gefragt und Kommunikation besonders wichtig.
Akzeptanzkriterien erleichtern die Arbeit.
Weniger ist manchmal mehr – User Stories sollten kurz und präzise formuliert werden.
Stories sollen sichtbar sein, sodass jeder sie einsehen kann und präsent hat.
User Stories sind kein Allheilmittel – nicht immer macht es Sinn eine User Story zu schreiben, fühlt euch nicht verpflichtet dazu. ⁴

Umgang mit zu großen User Stories

Sind User Stories zu umfangreich, kann das Team den Aufwand kaum verlässlich abschätzen. Deshalb spaltet der Product Owner die Anforderungen in kleinere Einheiten. Wie geht er dabei am besten vor, ohne wertvolle Informationen zu verlieren?

User Story vertikal formulieren
Das heißt: Unterschiedliche Bereiche eines technischen Systems, wie zum Beispiel Frontend und Backend, adressieren. Am Ende eines Sprints sollte dem Kunden eine Funktionalität zur Verfügung stehen, die vollständig nutzbar ist.

Sich auf den größten Nutzen konzentrieren
Besitzt die Anforderung einen simplen Kern? Verspricht dieser den größten Nutzen für den Geschäftsablauf? Nach Geschäftsfällen ordnen und sich auf die mit dem größten Nutzen fokussieren.

Komplexität verringern
Optionen und Komplexität sollten verringert werden. Wenn der Anwender zum Beispiel keine komplexe Oberfläche benötigt, ist es vielleicht möglich, mit einem schlichten und einfachen Design zu starten.

User Story aufsplitten
Umfangreiche User Stories sollten nach Funktionen, Aktionen oder Operationen aufgesplittet werden, die der Benutzer separat ausführen kann. ¹