User Stories – Universelle Sprache in agilen Teams

User Stories (dt. Nutzer- oder Anwendererzählung) haben ihren Ursprung in der agilen Softwareentwicklung. Im Gegensatz zu einer klassischen Spezifikation beschreibt die User Story ausschließlich die Erwartungen des Nutzers an die Funktionalität einer Software und nicht etwa WIE die Anforderung umzusetzen ist.

Heute sind User Stories auch über die Softwareentwicklung hinaus eines der zentralen Werkzeuge, um Anforderungen zu formulieren und zu diskutieren. Dabei bilden mehrere User Stories gemeinsam einen Use Case. Aufeinander folgende User Stories ergeben eine User Story oder Customer Journey Map.

Eine User Story ist wie folgt aufgebaut:

Als [Nutzer] möchte ich [Funktion], damit / um / weil [Wert].

Das heißt, eine User Story beantwortet die Fragen WER möchte WAS und WARUM. Lass uns auf die drei Bestandteile im Einzelnen schauen.

Den Platzhalter [Nutzer] füllst Du mit Rollen bzw. deinen Personas. Eine Persona ist ein typischer Vertreter deiner 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 zu deinem Produkt beschreiben.

Beispiel: Du bist aktuell in der Rolle “Leser dieses Artikels”. Das sagt jedoch noch nichts über deinen Hintergrund und deine Persona aus. Du kannst Projektmanager, Coach, Product Owner oder Digital-Chef in deinem Unternehmen sein. Aus deiner Persona resultieren unterschiedliche Erwartungen an diesen Artikel. Dagegen ist es für den Download am Ende des Artikels völlig ausreichend die User Story aus der Perspektive “Leser” zu formulieren.

Wie detailliert Du den Platzhalter [Nutzer] füllst, ist von der User Story selbst, aber auch von der Reife deines Vorhabens abhängig. Für den passenden Detaillierungsgrad gibt es kein richtig oder falsch. Das Wichtigste ist, dass für Dich und dein Team mit dem gewählten [Nutzer] eine für Dich aussagekräftige User Story entsteht.

Den Platzhalter [Funktion] ersetzt Du mit der Erwartung, den Zielen und Wünschen des [Nutzers]. Damit beantwortest Du die Frage, WAS der Kunde braucht und erwartet. Wenn du bereits ein Produkt am Markt anbietest, erhältst Du sicher viele gewünschte Funktionen direkt vom Nutzer. In früheren Phasen deines Projektes kannst Du basierend auf deiner Erfahrung Annahmen formulieren, welche [Funktion] der [Nutzer] erwartet.

Beispiel: Auch wenn Du und ich nicht direkt gesprochen haben, habe ich durch meine tägliche Arbeit und die Ausbildung von agilen Coaches ein gutes Verständnis, welche Fragen Du im Zusammenhang mit der Erstellung einer User Story mitbringst. Die [Funktion] dieses Artikels ist “User Stories verstehen”. Das heißt, daraus resultiert folgende User Story:

Als [Leser dieses Artikels] möchtest Du [User Stories verstehen]

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

Das heißt, erst mit dem [Wert] bringst Du zum Ausdruck, 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 Dir die User Story eine ehrliche Reflektion, wie gut Du Dich bereits mit den Anforderungen deiner Kunden auseinander gesetzt hast. Anforderungen aufzunehmen ist einfach (z.B. weil der Kunde nach einer Funktion schreit). Zu verstehen warum es für ihn wichtig ist, gibt Dir und deinem Team aber erst den notwendigen Kontext.

Beispiel: Dein erwarteter Mehrwert aus dem Lesen dieses Artikel kann sein, dass Du eine Wissenslücke schließen oder User Stories ab morgen anwenden möchtest. Ich behaupte, dass wenn Du sie anwenden kannst, hast Du sie auch verstanden, deswegen gilt für diesen Artikel die folgende User Story:

Als [Leser dieses Artikels] möchte ich [User Stories verstehen], damit [ich User Stories ab morgen anwenden kann].

Sofern Du mit User Stories als Format der Anforderungsformulierung in einem Scrum Team arbeitest (dazu weiter unten mehr), ergänzt Du deine User Story um Akzeptanzkriterien. Diese Akzeptanzkriterien beschreiben die fachlichen Anforderungen, die eine User Story zum Zeitpunkt der Abnahme erfüllen muss. Man könnte sie auch verstehen als notwendige Voraussetzungen, damit eine User Story auch Wert schafft. 

Hier findest Du Beispiele für User Stories aus meinem persönlichen Alltag. Wenn Du das Schreiben von User Stories erst einmal verinnerlicht hast, besteht die ganze Welt auf einmal aus User Stories.

Als...

• ... Webshop Kunde möchte ich einen Login, um meine bisherigen Bestellungen zu sehen, zu kontrollieren und Rechnungen auszudrucken.
• ... Geschäftsreisender der DB möchte ich meine Reservierungen in der DB App mehrfach täglich ändern, um flexibler umbuchen zu können.
• ... AirBnB User, der einen “Business Trip” macht, möchte ich eine Rechnung, die meine Firmendaten enthält und wenigstens in Ansätzen einer formal korrekten Rechnung gleichkommt.
• ... audible Abonnent möchte ich bestellte Hörbücher einfach zurückgeben können, um mein Guthaben für relevante Titel auszugeben.
• ... Atlassian Kunde möchte ich die Subdomain meiner Confluence Instanz ändern, um in der Namenswahl flexibler zu sein.

Ich möchte die folgende User Story nutzen, um Dir zu zeigen, wie wichtig die genaue und konkrete Auseinandersetzung mit der User Story, vor allem aber der letzte Zusatz [Wert] ist.

Als Unternehmer möchte ich einen Abgleich meiner Bankdaten mit meiner Buchhaltung, ...

Stell Dir vor, du bist der verantwortliche Product Owner für die von mir genutzte Buchhaltungssoftware und müsstest nun mit dieser noch unfertigen Anforderung arbeiten. Du hättest folgende Lösungswege:

1. Upload meiner Bankdaten in die Buchhaltungssoftware, als Nutzer gleiche ich die Ein- und Auszahlungen manuell mit meinen Buchungen ab.
2. Automatischer Import meiner Bankdaten und automatischer Abgleich.

Wenn mein Nutzen wäre “eine lückenlose Buchhaltung zu haben”, dann wäre ich unter Umständen mit der ersten Umsetzung zufrieden. Wäre dagegen mein Nutzen ist, dass ich “Zeit in der Abwicklung meiner Buchhaltung spare”, dann bringt mich die erste Umsetzung nur einen kleinen Schritt weiter.

Wenn Du diese User Story aber zu Ende denkst, könntest Du auch auf die Idee kommen die Zahlungen und meine Buchungen automatisch abzugleichen. Wie Du siehst, gibt erst der Zusatz [Wert] Dir den nötigen Kontext um überhaupt Entscheidungen für dein Produkt zu treffen. Wie sehr mich die jeweiligen Features begeistern, erfährst Du übrigens mit dem Kano-Modell.

Abschließend noch ein Beispiel für eine User Story inkl. Akzeptanzkriterien. Es geht um die Frage, wie Du als Mitarbeiter in deinem Unternehmen Urlaub einreichen kannst.

Als Mitarbeiter möchte ich innerhalb von 24 Stunden ein verbindliches Feedback zu meinem Urlaubsantrag, um spontan und flexibel Urlaub nehmen und buchen zu können.

Akzeptanzkriterien:

• Anträge werden online (Web oder App) gestellt 
• Startdatum und Enddatum sind frei wählbar
• Anzahl der Urlaubstage wird manuell eingegeben oder auf Basis des Start-/Enddatums berechnet
• “Warning” bei Überschreiten des Resturlaubs
• Benachrichtigung des Mitarbeiters über Änderung des Antragsstatus

Die Liste der Akzeptanzkriterien würdest Du ggf noch mit weiteren Abläufen und Schritten ergänzen, je nachdem wie dein Unternehmen die Beantragung von Urlaub handelt und in welchen Systemen die Daten verwaltet sind.

User Stories schaffen eine gemeinsame Sprache in deinem Team, mit Stakeholdern aber vor allem zwischen Dir und deinen Nutzern. Deshalb sind User Stories immer dann ein sinnvolles Werkzeug, wenn Du Dich mit den Erwartungen von Nutzern an ein Produkt, Service, eine Software oder ein Projekt auseinandersetzt.

Wenn Du Ideen für neue Features hast oder glaubst verstanden zu haben, was deine Nutzer wollen, dann sind User Stories der erste Belastungstest. Ich behaupte, dass wenn Du deine Idee oder eine vermeintliche Anforderung nicht in einer User Story formulieren kannst, dann ist die Anforderung noch nicht klar genug. Dabei kannst Du User Stories sogar als Format einsetzen, um Feedback von Anwendern einzusammeln. Lade deine Nutzer einfach ein, ihren Wunsch in der Struktur einer User Story zu formulieren und schau Ihnen dabei über die Schulter.

Wenn Du deine Ideen oder Annahmen in User Stories verpackt hast, kannst Du auch einen Schritt weiter gehen und diese ausformulierten User Stories deinen Nutzern schicken. Deine Zielgruppe kann mit einer einfachen Abstimmung “stimme ich zu“ vs. “stimme ich nicht zu” Feedback geben. Wenn Du diese Abfrage etwas ausgefeilter gestalten willst, lässt Du deine Nutzer auf einer Skala von 1-5 zu jeder User Story abstimmen. Du erhältst auf diesem Weg eine erste Priorisierung aber auch ein Feedback, welche User Stories vielleicht noch nicht so gut getroffen sind. Unter Umständen bietet Dir dieses Feedback auch erste Datenpunkte für die Erstellung deiner Personas.

Gemeinsame Workshops mit anderen Abteilungen, Kooperationspartnern oder sogar deinen Kunden bieten den idealen Raum, um neue Ideen zu entwickeln. Dabei sind User Stories ein gutes Format, um Hackathons

oder Customer Journey Mappings zu ergänzen. Dazu sammelst Du einfach die resultierenden User Stories im Laufe der Workshops ein, bzw. räumst ausreichend Zeit ein, User Stories zu formulieren. Wenn Kunden anwesend sind, dann kannst Du sie unmittelbar in die Formulierung der User Stories einbeziehen. So erfährst Du auf eine sehr einfache und spielerische Art, was den Kunden antreibt und wie gut Du ihn verstanden hast.

User Stories sind der defacto Standard für die Formulierung von Anforderungen in Scrum-Teams und der Pflege deines Backlogs. Damit User Stories zur Formulierung von Anforderungen Sinn machen, ergänzt der Product Owner sie um Akzeptanzkriterien. Während die User Story die Anforderungen aus Sicht des Anwenders beschreibt, definieren die Akzeptanzkriterien die fachlichen Anforderungen, die das Produkt zum Zeitpunkt der Abnahme erfüllen darf. In diesem Artikel erfährst Du, wie Du Scrum, Kanban und User Stories optimal kombinierst.

In der Organisation von Backlogs darfst Du es sprachlich etwas genauer nehmen, was genau mit einer User Story gemeint ist. Einerseits bleiben User Stories, wie in diesem Artikel ausgeführt, ein Format, um Anforderungen zu beschreiben. Andererseits können User Stories im Rahmen deiner Backlog Organisation auch ein spezieller Hierarchietyp sein

• Epics: Sehr weit gefasst Funktionsbereiche eines Produktes, deren genauer Scope oft noch unklar ist.
• Features: Konkrete Leistungsmerkmale innerhalb eines Epics.
• Stories: Technische Stories und User Stories innerhalb des Features.

Dabei kannst Du User Stories als Format auch nutzen, um Epics oder Features zu beschreiben. Dagegen sind User Stories als spezieller Hierarchietyp deines Backlog innerhalb eines Sprints umsetzbar und schaffen einen konkreten Nutzen für den User. Technische Stories erfüllen nicht unmittelbar ein Bedürfnis des Kunden, sondern sind technische Notwendigkeiten zur Entwicklung deiner Leistung.

Eine User Story ist ein sehr einfaches aber wirkungsvolles Format, um Bedürfnisse deiner Nutzer zu diskutieren, zu validieren und mit einem gemeinsamen Verständnis an deren Umsetzung zu arbeiten. Dabei ist der Aufwand eine User Story zu formulieren so gering, dass sich eine Diskussion fast nicht lohnt, ob ihr Einsatz überhaupt Sinn macht.

Dabei bietet Dir die User Story eine universelle Sprache, die alle deine Stakeholder, deine Teammitglieder aber vor allem auch deine Kunden sprechen. Du kannst von der Arbeit mit diesem Format nur profitieren. Von daher hoffe ich, dass alle deine Fragen beantwortet sind, damit ich die User Story zu diesem Artikel erfüllen konnte. Und wenn doch nicht, dann hinterlass mir gerne deine Frage als Kommentar.

Viel Erfolg bei der Arbeit mit User Stories.