User Stories – Universelle Sprache in agilen Teams6 Minuten

User Stories – Universelle Sprache in agilen Teams6 Minuten 600 315 Andreas Diehl (#DNO)

User Stories beschreiben die Anforderungen an ein Produkt oder Service aus Sicht des Nutzers. Als Format ist die User Story ein zentrales Werkzeug in der Zusammenarbeit agiler Teams. Ihr Einsatzgebiet reicht von der Validierung von Kundenbedürfnissen bis zur Anforderungsformulierung in Scrum Teams.

In diesem Beitrag zeige ich Dir, wie eine User Story aufgebaut ist und wie Du mit dem Format erfolgreich arbeitest.

User Story Definition

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.

Struktur einer User Story

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.

[Nutzer] – Wer?

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.

[Funktion] – Was?

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älst 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], ….

[Wert] – Warum?

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].

Beispiele User Stories

Hier findest Du Beispiele für User Stories aus meinen persönliche 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.
  • ISD Trainer möchte alles, was ich in der Ausbildung gelernt habe zum Wohl anderer einsetzen, um damit ihre Lebens- und Arbeitswelt und damit auch die Welt als Ganzes ein Stückchen besser zu machen.

User Story Decomposing

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.

Mit User Stories arbeiten

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.

Anforderungen reflektieren und Feedback einsammeln

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.

Anforderungen bewerten und validieren

Wenn Du deine Ideen oder Annahmen in User Stories verpackst 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.

Co-Creation Workshops

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.

Anforderungsformulierung in agilen Teams

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.

Fazit – Wenn Du Kunden verstehen willst sind User Stories unverzichtbar

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.

Artikel zum Download:

Weiterführende Artikel:

Hast Du Fragen, Ergänzungen oder Kommentare?

%d Bloggern gefällt das: