Dr. Matthias Stephan · Zuletzt aktualisiert: 2. Mai 2023
Möchtest du großartige User Stories erstellen, um den Entwicklungsprozess deines Unternehmens zu optimieren? Suche nicht weiter: In diesem Artikel zeigen wir dir die Funktion, den Aufbau und den Lebenszyklus einer User Story sowie die wichtigsten Best Practices. Darüber hinaus betrachten wir die Unterschiede zwischen User Stories und Epics und wie man effektive User Stories für eine effiziente Projektabwicklung schreibt. Mach dich bereit, die „Definition of Done“ zu verstehen und steigere den Erfolg deiner Projekte!
User Stories sind ein wesentlicher Bestandteil von Scrum und sind für das Verständnis von Benutzererfahrungen in der Softwareentwicklung unerlässlich. Sie sind in der Regel eine kurze, einfache Beschreibungen des gewünschten Benutzerverhaltens. Hierbei ist es wichtig, dass die Inhalte sowohl für Entwickler als auch für Benutzer verständlich sind. In Scrum ist User Story ein Begriff, der verwendet wird, um die agile Methode zur Erstellung der Anforderungen zu beschreiben, die dabei hilft, Produktanforderungen effektiver zu steuern.
Was ist die Funktion der User Story?
Durch das Lesen einer User Story sollte der Leser in der Lage sein, die Funktionalität, die Vorteile und den Zweck zu verstehen, die sie bietet. Eine User Story ist ein Mittel, um den Nutzen einer vorgeschlagenen Software oder Lösung zu verstehen, indem erstens die spezifischen Bedürfnisse und Erwartungen der Benutzer erfüllt werden und zweitens das Bewusstsein für das Produkt oder die Dienstleistung gesteigert wird. Insgesamt fördern User Stories den Erfolg, da sie zu einem besseren Verständnis eines Systems führen.
Wer schreibt eine User Story?
Der Product Owner ist derjenige, der in erster Linie für das Delegieren von Aufgaben und das Schreiben der User Stories verantwortlich ist. User Stories beschreiben im Allgemeinen die Perspektive des Benutzers auf die Funktionen, die er sehen möchte, und bieten Entwicklern nützliche Richtlinien. Der Product Owner übernimmt das Backlog und priorisiert es entsprechend. Im Backlog können Benutzer User Stories gemäß Scrum Best Practices eingeben und der Product Owner übernimmt sie von dort. Der Product Owner entscheidet dann, welche Geschichten kodiert werden.
Struktur einer User Story
Als [Persona] möchte ich [irgendein Ziel], damit [irgendein Grund]
Eine User Story ist eine Aussage der Form: „Als [Persona] möchte ich [irgendein Ziel], damit [irgendein Grund]“. Die User-Story-Vorlage ist obligatorisch und sollte verwendet werden, um User-Stories zu formulieren. Es hilft dem Team und anderen Beteiligten, die Produktanforderung zu verstehen. Die Rolle definiert, wer der typische Repräsentant der Persona ist. Es ist ein Teil, der in jeder Geschichte enthalten sein muss. Dies trägt dazu bei, dass alle wichtigen Faktoren in der Geschichte enthalten sind und das Ziel leicht erreicht wird.
Wer?
Personas und Rollen sind wichtige Elemente einer User Story bei der Entwicklung von Software. Diese kann je nach Zielgruppe, Kontext und Erwartungen definiert werden. Personas spiegeln wider, welchen Nutzertyp die Story anspricht, während Rollen die Beziehung des Nutzers zum Produkt beschreiben. Beispielsweise könnte die Rolle „Leser dieses Artikels“ sein, während die Persona Manager, Coach, Product Owner oder Digital Boss sein könnte. Es ist wichtig, je nach Reife des Projekts den richtigen Detaillierungsgrad in User Stories zu wählen, um sicherzustellen, dass die Stories aussagekräftig und relevant sind.
Was?
Um User Stories zu erstellen, ist ein Verständnis dafür notwendig, worum es geht und wie dies am besten in der täglichen Arbeit eingesetzt werden kann. Es wird empfohlen, bei der Erstellung von User Stories die Erwartungen, Ziele und Wünsche des Kunden zu berücksichtigen. Auch Erfahrungsannahmen können berücksichtigt werden. Indem der Platzhalter durch die Erwartung, Ziele und Wünsche des Benutzers ersetzt wird, ist es möglich, dessen Bedürfnisse zu verstehen.
Warum?
User Stories sollten einen „WHY“-Satz enthalten, einen Nebensatz, der erklärt, warum die Story wichtig ist. Dies gibt dem Team den notwendigen Kontext, um die Bedürfnisse und Erwartungen des Kunden besser zu verstehen. Beispielsweise kann beim Lesen dieses Artikels die Erwartung bestehen, eine Wissenslücke zu schließen und User Stories ab dem nächsten Tag zu nutzen. Insgesamt verleiht die „WHY“-Klausel der User Story einen umfassenden und aussagekräftigen Wert und trägt zu einem besseren Verständnis der Kundenbedürfnisse bei.
Beispiele
Hier sind ein paar Beispiele für User Stories:
- Als Online-Shopper möchte ich die Möglichkeit haben, meine Bestellungen einfach mit einem Klick stornieren zu können, damit ich meine Meinung ändern kann, ohne mich an den Kundenservice wenden zu müssen.
- Als Nutzer eines Fitness-Trackers möchte ich eine Erinnerung bekommen, wenn ich mein Tagesziel für Schritte noch nicht erreicht habe, damit ich mich daran erinnere, mich mehr zu bewegen.
- Als Reisender möchte ich in der Lage sein, Flüge und Hotels in einer einzigen Buchung zu kombinieren, damit ich Zeit und Geld sparen kann.
- Als Elternteil möchte ich die Möglichkeit haben, das Nutzungsverhalten meines Kindes von bestimmten Apps und Websites zu beschränken, damit ich die Online-Aktivitäten meines Kindes kontrollieren kann.
- Als Student möchte ich die Möglichkeit haben, Notizen während Vorlesungen zu machen und sie später zu bearbeiten, damit ich besser lernen und mich auf Prüfungen vorbereiten kann.
Akzeptanzkriterien
User Storys ermöglichen es einem Softwareentwicklungsteam, Themen schnell in überschaubare Aufgaben zu unterteilen und Schlüsselwörter zu verwenden, um Parameter für eine User Story bereitzustellen. Mit Akzeptanzkriterientests können Entwickler sicherstellen, dass die Anforderungen des Lesers als auch die Anforderungen der User Story erfüllt sind. Indem die Kriterien nachweislich zum Schreiben und Aufschlüsseln von User Stories verwendet werden, können Teams Verwirrung vermeiden und schnell grundlegende und einfache User Stories mit Schlüsselwörtern erstellen, die routinemäßig verwendet werden, um die beabsichtigte Botschaft zu vermitteln. Durch die Nutzung von User-Story-Parametern und Akzeptanzkriterientests können Teams schneller vorankommen und während des gesamten Entwicklungszyklus qualitativ hochwertige Ergebnisse sicherstellen.
Lebenszyklus
Der Lebenszyklus einer User Story umfasst typischerweise die folgenden Schritte:
- Ideenfindung: Der Prozess der Identifikation von Bedarfen und Anforderungen aus Sicht des Benutzers.
- Priorisierung: Die Zuordnung von Prioritäten zu den identifizierten Anforderungen, um zu bestimmen, welche Stories als Erstes umgesetzt werden sollten.
- Formulierung: Die Übersetzung der Anforderungen in klar formulierte User Stories, die das INVEST-Prinzip erfüllen.
- Schätzung: Die Einschätzung der benötigten Zeit und Ressourcen für die Umsetzung der User Story.
- Planung: Die Zuordnung der User Story zu einer Iteration (einem festgelegten Zeitraum) und der Zuweisung von Entwicklern.
- Entwicklung: Die Umsetzung der User Story durch die Entwickler.
- Überprüfung: Die Überprüfung der User Story durch den Product Owner (verantwortliche Person für die Anforderungen) und das Entwicklungsteam, um sicherzustellen, dass sie den Anforderungen entspricht.
- Acceptance (Akzeptanz): Die Zustimmung des Product Owners, dass die User Story erfolgreich umgesetzt wurde und den Anforderungen entspricht.
Maximaler Nutzen für den Benutzer
Die User Story ist das Ergebnis einer Teamarbeit und sollte entsprechend geplant werden. Zunächst sollten die notwendigen Kriterien – wie Komplexität, Modell und Struktur – festgelegt werden; Anschließend können die Story Points und die Sprintlänge bestimmt werden. Danach sollten die Aufgaben ordnungsgemäß unter den Teammitgliedern verteilt und mit der Ausführung begonnen werden. Obwohl die Strukturierung der Story dem Team überlassen bleibt, sollte eine detaillierte Analyse der Aufgaben erfolgen, um die bestmögliche Qualität der User Story sicherzustellen. Das Ziel sollte immer der Nutzen des Nutzers sein, nicht der Service, das Produkt oder die Lösung. Mit der richtigen Planung kann die User Story erfolgreich abgeschlossen werden und die besten Ergebnisse für alle Beteiligten liefern.
User Story vs. Epic
User Stories und Epic Stories sind zwei Schlüsselkategorien in der agilen Softwareentwicklung. Eine Epic Story, definiert als große User Story, kann in kleinere User Storys unterteilt werden. Der grundlegende Unterschied zwischen ihnen besteht darin, dass User Stories immer sichtbar, konkret und umsetzbar sind, während Epic Stories abstrakter, länger und weniger konkret sind. Eine User Story hat immer eine Epic Story als übergeordnetes Element, aber das Gegenteil ist nicht unbedingt der Fall. Eine Epic ist wie eine allgemeine Idee, die, wenn sie ausgeführt wird, weitergehen kann.
Epics sollten in kleinere Aufgaben aufgeteilt werden, damit Teams ein Gefühl der Vollständigkeit haben und neue Funktionen effizienter implementieren können. Durch die Aufteilung einer Epic in mehrere Sprints erledigen Teams jedes Mal neue Aufgaben und somit werden neue Features schnell auf den Markt gebracht. Dies beschleunigt den Prozess und fördert schnelleres Arbeiten.
Um ein Epic in User Stories zu zerlegen, kann man folgende Schritte ausführen:
- Verstehen: Zunächst sollte man sich einen Überblick über das Epic verschaffen und verstehen, was es beinhaltet und warum es wichtig ist. Dazu kann man Fragen stellen und sich mit den Stakeholdern beraten.
- Zerlegen: Sobald man das Epic versteht, kann man es in kleinere, überschaubare Anforderungen zerlegen. Dazu kann man die Funktionalitäten des Epics aufteilen oder die Nutzerperspektive einbeziehen und User Stories aus der Perspektive der Nutzer schreiben.
- Priorisieren: Nachdem man das Epic in kleinere Anforderungen zerlegt hat, sollte man diese Anforderungen priorisieren, indem man entscheidet, welche Anforderungen zuerst umgesetzt werden sollen.
- Detaillieren: Sobald man die Anforderungen priorisiert hat, kann man sie detaillierter beschreiben und Acceptance Criteria festlegen, um sicherzustellen, dass sie klar und verständlich sind.
„Fertig“ verstehen: Effektive User Stories für die Projektentwicklung schreiben
Zusätzlich zu den bereits genannten Merkmalen und Vorteilen einer User Story, bietet diese die Möglichkeit auch das angestrebte Endstadium einer Entwickung zu definieren. Dies ist wichtig, um einen Prozess abzuschließen und als „Fertig“ zu markieren. Die Definition of Done ist ein Kriterienkatalog, der beschreibt, welche Anforderungen ein Softwareentwicklungsprojekt erfüllen muss, damit es als „fertig“ betrachtet werden kann. Diese Kriterien können technischer Natur sein, zum Beispiel dass alle Code-Reviews abgeschlossen sind und alle Tests erfolgreich abgeschlossen wurden.
Das INVEST-Prinzip
Das INVEST-Prinzip ist ein Leitfaden für die Gestaltung von User Stories in agilen Softwareentwicklungsprozessen. Das Akronym INVEST steht für:
- I – Independent (Unabhängig): Eine User Story sollte sich unabhängig von anderen Stories realisieren lassen.
- N – Negotiable (Verhandelbar): User Stories sind Verhandlungsgegenstände und nicht feste Anforderungen. Sie können während der Entwicklung angepasst werden, um die Bedürfnisse des Benutzers besser zu erfüllen.
- V – Valuable (Wertvoll): Eine User Story muss einen klaren Nutzen für den Benutzer bieten.
- E – Estimable (Schätzbar): Eine User Story muss so formuliert sein, dass sie von einem Entwickler geschätzt werden kann, um eine realistische Einschätzung der benötigten Zeit und Ressourcen zu ermöglichen.
- S – Small (Klein): Eine User Story sollte klein genug sein, um innerhalb einer Iteration (eines festgelegten Zeitraums) abgeschlossen werden zu können.
- T – Testable (Testbar): Eine User Story muss so formuliert sein, dass sie getestet werden kann, um sicherzustellen, dass sie erfolgreich umgesetzt wurde und den Anforderungen entspricht.
Das INVEST-Prinzip hilft dabei, User Stories zu schreiben, die für die Entwicklung von Software von hoher Qualität und Nutzen für den Benutzer sind.
User Storys mit Story Map organisieren
User Stories bieten eine einfache und effektive Möglichkeit, Feedback zu Projektplänen zu geben. Indem sie Benutzern ein schnelles Brainstorming ermöglichen, können User Story Maps diese Ideen in einem einfach zu verwaltenden Backlog organisieren. Geschichten sind aus vielen Gründen unglaublich nützlich.
Sie holen Feedback von Benutzern in einem frühen Stadium des Prozesses ein, sodass Product Backlogs die Ansichten der Benutzer von Anfang an berücksichtigen können. Neben dem Sammeln wichtiger Informationen darüber, was Benutzer brauchen und wollen, dienen User Stories auch als großartige Möglichkeit, Projektpläne unter Kontrolle zu halten. Sie helfen, das Chaos zu organisieren und ein Projekt überschaubarer zu machen.
Darüber hinaus können User Stories verwendet werden, um einen iterativen Entwicklungsansatz zu fördern. Da Stories die erforderliche Software oft in benutzerfreundlicher und zugänglicher Weise beschreiben, sind sie nützlich, um andere zu ermutigen, sich dem Entwicklungsprozess anzuschließen, bevor ein Großteil des technischen Aufbaus abgeschlossen ist.
Letztendlich erweisen sich User Stories als äußerst nützlich, um potentielles Chaos zu vermeiden und Projektpläne überschaubar zu machen. Indem Benutzern ein schnelles Brainstorming ermöglicht wird, können User Story Maps Ideen in einem einfach zu verwaltenden Backlog organisieren. Dies fördert einen iterativen Entwicklungsansatz und macht Geschichten zu einer kritischen Komponente für den Projekterfolg.
Fazit
User Stories sind unerlässlich, wenn Sie Kunden verstehen wollen. Die Arbeit mit User Stories hilft, ein kundenzentriertes Verständnis der Anforderungen zu entwickeln. Es ist eine großartige Möglichkeit, sich das „große Bild“ dessen vorzustellen, was Kunden brauchen und was zu priorisieren ist. User Stories werden von Stakeholdern in einer natürlichen Sprache beschrieben und dann vom Team fachmännisch in eine funktionierende Software übersetzt. Um effektive User Stories zu erstellen, müssen Sie den Kunden, seine Reise und die Ziele verstehen, wie der Kunde mit der vorhandenen Software interagieren möchte. Einige verwenden möglicherweise den Begriff „Epics“, um sich auf User Stories zu beziehen. Das Formulieren von User Stories hilft sicherzustellen, dass alle auf derselben Seite sind und dass die Produktkommunikation konsistent bleibt.
Verweise
- User Stories – Definition, Struktur und Beispiele – Andreas Diehl (#DNO)
- What is User Story? – Visual Paradigm
- Was ist eine User Story? Definition, Vorlage & Beispiele – Appvizer
- User Story Examples in Product Development | Definition and Template
- Books Stack Book Store (Bild-Quelle)
- Notepad Glasses Travel Planning (Bild-Quelle)
- Thumb Hand Arm Accompany Guide (Bild-Quelle)
- Coins Banknotes Money Currency (Bild-Quelle)
