175 lines
16 KiB
Markdown
175 lines
16 KiB
Markdown
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](https://digitaleneuordnung.de/blog/customer-journey-mapping/).
|
||
|
||
## **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](https://digitaleneuordnung.de/blog/personas-erstellen/). 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](https://digitaleneuordnung.de/blog/chief-digital-officer-cdo/) 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ä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](https://digitaleneuordnung.de/blog/agile-coach-ausbildung/) 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].**
|
||
|
||
### Akzeptanzkriterien einer User Story
|
||
|
||
Sofern Du mit User Stories als Format der Anforderungsformulierung in einem Scrum Team arbeitest (dazu [weiter unten](https://digitaleneuordnung.de/blog/user-stories/#user-stories-in-scrum-teams) 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.
|
||
|
||
## **Beispiele User Stories**
|
||
|
||
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.
|
||
|
||
### 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](https://digitaleneuordnung.de/blog/kano-modell/).
|
||
|
||
### Beispiel User Story + Akzeptanzkriterien
|
||
|
||
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.
|
||
|
||
## **Allgemeine Einsatzgebiete in der Arbeit mit User Stories**
|
||
|
||
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 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](https://digitaleneuordnung.de/blog/personas-erstellen/).
|
||
|
||
### 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](https://digitaleneuordnung.de/blog/hackathon/)
|
||
|
||
oder [Customer Journey Mappings](https://digitaleneuordnung.de/blog/customer-journey-mapping/) 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 zur Anforderungsformulierung in Scrum Teams**
|
||
|
||
User Stories sind der defacto Standard für die Formulierung von Anforderungen in [Scrum-Teams](https://digitaleneuordnung.de/blog/scrum-methode/) 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](https://digitaleneuordnung.de/blog/kanban-methode/) optimal kombinierst.
|
||
|
||
### Backlog Organisation - User Stories und User Stories
|
||
|
||
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.
|
||
|
||
|
||
|
||
User Stories als spezielle Hierarchie in deinem Backlog | Quelle: Andreas Diehl
|
||
|
||
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.
|
||
|
||
## **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](https://digitaleneuordnung.de/blog/user-stories/#comment).
|
||
|
||
Viel Erfolg bei der Arbeit mit User Stories.
|
||
|
||
|
||
---
|
||
|
||
# Gemini Zusammenfassung
|
||
### **Was sind User Stories?**
|
||
|
||
User Stories sind eine einfache, aber wirkungsvolle Methode, um die Anforderungen eines Nutzers an ein Produkt oder eine Dienstleistung zu beschreiben. Sie helfen uns zu verstehen, was der Nutzer wirklich braucht und warum.
|
||
|
||
**Stell dir vor, du möchtest eine neue App für deine Lieblingsmusik.** Eine User Story könnte so aussehen:
|
||
|
||
_Als Musikfan möchte ich meine Lieblingslieder in einer Playlist speichern, damit ich sie schnell wiederfinden kann._
|
||
|
||
**Die drei wichtigsten Bestandteile einer User Story sind:**
|
||
|
||
- **Wer:** Wer ist der Nutzer? (z.B. Musikfan)
|
||
- **Was:** Was möchte der Nutzer tun? (eine Playlist erstellen)
|
||
- **Warum:** Warum ist das wichtig für den Nutzer? (um schnell auf seine Lieblingslieder zugreifen zu können)
|
||
|
||
### **Warum sind User Stories so nützlich?**
|
||
|
||
- **Klare Kommunikation:** User Stories sorgen dafür, dass alle Beteiligten (Entwickler, Designer, Produktmanager usw.) ein gemeinsames Verständnis von den Anforderungen haben.
|
||
- **Kundenfokus:** Sie helfen uns, uns in die Lage des Nutzers zu versetzen und seine Bedürfnisse in den Mittelpunkt zu stellen.
|
||
- **Flexibilität:** User Stories sind anpassungsfähig und können sich im Laufe eines Projekts ändern.
|
||
- **Priorisierung:** Sie helfen dabei, die wichtigsten Funktionen zu identifizieren und zu priorisieren.
|
||
|
||
### **Wie werden User Stories verwendet?**
|
||
|
||
- **Anforderungsmanagement:** User Stories werden in der agilen Softwareentwicklung verwendet, um Anforderungen zu sammeln, zu priorisieren und zu verwalten.
|
||
- **Produktentwicklung:** Sie helfen dabei, ein Produkt zu entwickeln, das den Bedürfnissen der Nutzer entspricht.
|
||
- **Kundenfeedback:** User Stories können verwendet werden, um Feedback von Kunden einzuholen und die Anforderungen anzupassen.
|
||
|
||
**Zusammengefasst:** User Stories sind ein wertvolles Werkzeug, um sicherzustellen, dass Produkte und Dienstleistungen den Bedürfnissen der Nutzer entsprechen. Sie fördern die Zusammenarbeit, verbessern die Kommunikation und tragen zu einem erfolgreichen Projekt bei.
|
||
|
||
**Möchtest du mehr über ein bestimmtes Thema erfahren, wie zum Beispiel:**
|
||
|
||
- **Akzeptanzkriterien:** Was sind das und warum sind sie wichtig?
|
||
- **User Stories in Scrum:** Wie werden User Stories in einem agilen Projekt eingesetzt?
|
||
- **Beispiele für User Stories in verschiedenen Branchen:** Wie sehen User Stories in der Praxis aus? |