So schreiben Sie eine gute User Story: Eine Schritt-für-Schritt-Anleitung

Das Schreiben guter User Stories ist für eine effektive agile Entwicklung unerlässlich. Eine gut ausgearbeitete User Story hilft Teams zu verstehen, was erstellt werden muss, warum es wichtig ist und wie sichergestellt werden kann, dass es die Benutzeranforderungen erfüllt. Dieser Leitfaden führt Sie durch das Schreiben klarer, umsetzbarer User Stories, die eine erfolgreiche Produktentwicklung vorantreiben.

Was ist eine User Story?

Eine User Story ist eine einfache, prägnante Aussage, die eine Funktion aus der Sicht des Endbenutzers beschreibt. Sie folgt normalerweise diesem Format:

Als [Benutzerrolle] möchte ich [Ziel], damit [Grund].

Zum Beispiel:

Als Kunde, der morgens kalt gebrühten Kaffee bevorzugt, möchte ich mein Getränk über die App vorbestellen, damit ich nicht anstehen muss und es auf dem Weg zur Arbeit abholen kann.

User Stories konzentrieren sich auf das Wer, Was und Warum , während das Wie erst bei der Implementierung festgelegt wird. Sie dienen als Bausteine für die Erstellung benutzerzentrierter Produkte und Dienste und stellen sicher, dass die Entwicklungsteams auf die Kundenbedürfnisse ausgerichtet sind.

Die 3Cs einer User Story: Karte, Konversation, Bestätigung

Das 3C-Framework stellt sicher, dass User Stories nicht nur niedergeschrieben, sondern auch durch Diskussion und Validierung verfeinert werden.

1. Karte : Die User Story wird als kurze Aussage gemäß dem Standardformat auf eine Karte (physisch oder digital) geschrieben.

2. Gespräch : Die Story wird zwischen Teammitgliedern und Stakeholdern besprochen, um Details und Erwartungen zu klären.

3. Bestätigung : Das Team einigt sich auf Abnahmekriterien, die definieren, wann die Story als abgeschlossen gilt.

Durch die Verwendung des 3C-Modells wird sichergestellt, dass User Stories über ihre schriftliche Form hinaus verstanden und kontinuierlich weiterentwickelt werden.

Warum sind User Stories wichtig?

• Richten Sie Ihre Teams an den Benutzeranforderungen aus – Stories sorgen dafür, dass die Entwicklungsarbeit benutzerorientiert ist.

• Fördern Sie die Zusammenarbeit – Sie sorgen für ein gemeinsames Verständnis in Teams.

• Priorisierung verbessern – Helfen Sie Produktbesitzern, sich auf die Wertschöpfung zu konzentrieren.

• Erhöhen Sie die Flexibilität – Sie ermöglichen Teams, je nach Bedarf zu iterieren und zu verfeinern.

• Reduzieren Sie Mehrdeutigkeiten – Verhindern Sie Fehlinterpretationen durch eine klare Definition der Ziele.

• Ermöglicht bessere Schätzungen – Hilft Teams, die Arbeit in überschaubare Abschnitte zu unterteilen.

So schreiben Sie eine gute User Story

Befolgen Sie diese Schritte, um klare und wertvolle User Stories zu verfassen:

1. Identifizieren Sie den Benutzer

Bestimmen Sie, wer von dieser Funktionalität profitiert. Der Benutzer kann ein Endkunde, ein Administrator oder ein anderes System sein.

Beispiel:

Als Barista möchte ich eine priorisierte Liste mobiler Vorbestellungen sehen, damit ich während der Stoßzeiten die Getränke in der richtigen Reihenfolge zubereiten kann.

2. Definieren Sie das Ziel

Was möchte der Benutzer erreichen? Das Ziel sollte klar und umsetzbar sein.

Beispiel:

Als Kunde, der Hafermilch-Latte bestellt , möchte ich meine Anpassungen in der App speichern , damit ich sie nicht bei jeder Bestellung erneut eingeben muss.

3. Erklären Sie den Nutzen

Warum ist diese Funktionalität wichtig? Wenn Sie den Wert verstehen, können Sie die richtigen Prioritäten setzen.

Beispiel:

Als Manager eines Cafés möchte ich die täglichen Verkaufstrends verfolgen , damit ich den Lagerbestand entsprechend der Nachfrage anpassen kann.

4. Befolgen Sie die INVEST-Kriterien

Eine gute User Story sollte dem INVEST- Prinzip entsprechen, also effektiv strukturiert sein und sowohl Benutzern als auch Entwicklungsteams klare Vorteile bieten. Im Folgenden erfahren Sie, was jedes Kriterium im Einzelnen bedeutet:

• Unabhängig – Eine User Story sollte für sich stehen und nicht von anderen Stories abhängig sein, um wertvoll zu sein. So können Teams sie unabhängig voneinander entwickeln, testen und veröffentlichen. Wenn eine Story zu sehr mit anderen verwoben ist, sollten Sie sie weiter aufschlüsseln.

  Beispiel: Statt „Als Kunde möchte ich meine gespeicherten Kaffeebestellungen anzeigen und löschen, damit ich sie einfach verwalten kann“, teilen Sie es in zwei separate Storys auf: „Als Kunde möchte ich meine gespeicherten Kaffeebestellungen anzeigen“ und „Als Kunde möchte ich eine gespeicherte Kaffeebestellung löschen.“

• Verhandelbar – User Stories sollten keine starren Anforderungen sein, sondern offen für Diskussionen und Verfeinerungen sein. Die Details können sich in Gesprächen zwischen dem Produktbesitzer, den Entwicklern und den Stakeholdern entwickeln.

  Beispiel: Ein Barista könnte zunächst anfordern: „Als Barista möchte ich, dass Vorbestellungen nach Zeit sortiert werden“, aber nach der Diskussion mit den Entwicklern wird ihnen klar, dass die Sortierung nach Bestelltyp (heiße oder kalte Getränke) effektiver ist.

• Wertvoll – Eine Story sollte dem Benutzer einen klaren Mehrwert bieten. Wenn eine Story keinen sinnvollen Nutzen bietet, sollten Sie noch einmal darüber nachdenken, ob sie notwendig ist.

  Beispiel: „Als Café-Manager möchte ich einen Bericht über den täglichen Kaffeeverkauf herunterladen, damit ich die Geschäftsentwicklung verfolgen kann.“ Dies bietet einen direkten Mehrwert, da es dem Manager hilft, fundierte Entscheidungen zu treffen.

• Schätzbar – Eine Story sollte klar genug sein, damit das Entwicklungsteam abschätzen kann, wie viel Aufwand es erfordert, sie fertigzustellen. Wenn eine Story zu vage oder zu komplex ist, muss sie möglicherweise weiter geklärt oder aufgeteilt werden.

  Beispiel: „Als Kunde möchte ich ein verbessertes Bestellerlebnis“ ist zu allgemein. Geben Sie stattdessen an: „Als Kunde möchte ich meine bevorzugten Kaffeebestellungen speichern, um schnell nachbestellen zu können.“

• Klein – Eine Story sollte klein genug sein, um innerhalb eines Sprints, idealerweise innerhalb weniger Tage, abgeschlossen zu werden. Große Stories sollten mithilfe von Techniken wie dem SPIDR-Framework zerlegt werden.

  Beispiel: Statt „Als Kunde möchte ich meine Kontoeinstellungen verwalten“ sollten Sie es in kleinere Abschnitte aufteilen, etwa „Als Kunde möchte ich meine E-Mail-Adresse aktualisieren“ und „Als Kunde möchte ich mein Passwort ändern“.

• Testbar – Eine Story muss klare Akzeptanzkriterien haben, damit das Team weiß, wann sie vollständig ist und wie erwartet funktioniert.

  Beispiel: „Als Kunde möchte ich nach der Bestellung eine Bestätigungs-E-Mail erhalten.“ Akzeptanzkriterien könnten sein: „Die E-Mail muss unmittelbar nach der Bestellung versendet werden.“ und „Die E-Mail sollte Bestelldetails enthalten.“

5. Formulieren Sie klare Akzeptanzkriterien

Akzeptanzkriterien definieren, wann eine Story abgeschlossen ist. Sie legen Erwartungen fest und verhindern Missverständnisse.

Beispiel:

User Story: Als Kunde, der regelmäßig einen Vanille-Latte bestellt , möchte ich mein vorheriges Getränk mit einem Fingertipp nachbestellen , um bei meiner morgendlichen Bestellung Zeit zu sparen.

Annahmekriterien: Benutzer können ihre letzten fünf Bestellungen auf der Homepage der App ansehen. Benutzer können auf eine Bestellung tippen, um sie direkt in den Einkaufswagen zu legen. Benutzer sehen eine Bestätigungsnachricht, wenn ihre Bestellung aufgegeben wird.

6. Fassen Sie sich kurz

User Stories sollten kurz und fokussiert sein. Vermeiden Sie das Hinzufügen von Implementierungsdetails.

7. Verwenden Sie das SPIDR-Framework, um große User Stories aufzuteilen

Das SPIDR -Framework ist eine nützliche Technik, um große User Stories in kleinere, überschaubarere Teile zu zerlegen. Große Stories, auch Epics genannt, können zu komplex sein, um sie in einem einzigen Sprint abzuschließen. Durch die Zerlegung wird sichergestellt, dass Teams inkrementellen Wert liefern und gleichzeitig die Übersichtlichkeit bei der Implementierung wahren können. Hier erfahren Sie, wofür SPIDR steht und wie es bei der Zerlegung großer User Stories hilft:

• S : Spike – Wenn eine User Story zu vage ist oder Unsicherheiten hinsichtlich ihrer Umsetzbarkeit bestehen, kann ein Spike erstellt werden. Spikes sind zeitlich begrenzte Forschungsaufgaben, die dem Team helfen, Unbekanntes zu erforschen, Annahmen zu testen oder technische Ansätze zu bewerten, ohne die Entwicklung zu verzögern. Das Zeitlimit stellt sicher, dass das Team gerade genug Informationen sammelt, um ohne Zeitverschwendung fortzufahren. Ein Spike ist eine Forschungsaufgabe, die dem Team hilft, Wissen zu erlangen und fundierte Entscheidungen zu treffen.

  Beispiel: Statt „Als Kunde möchte ich personalisierte Kaffeeempfehlungen“ erstellen Sie einen Spike, um zunächst die Empfehlungsalgorithmen zu erkunden.

• P : Pfad – Wenn es mehrere Möglichkeiten gibt, das Benutzerziel zu erreichen, sollten Sie die Story in verschiedene Pfade aufteilen, die die Benutzer einschlagen könnten.

  Beispiel: Statt „Als Kunde möchte ich Kaffeeoptionen durchsuchen“ teilen Sie es in „Als Kunde möchte ich Kaffeeoptionen nach Kategorie durchsuchen“ und „Als Kunde möchte ich Kaffeeoptionen nach Geschmacksprofil durchsuchen“ auf.

• I : Schnittstelle – Wenn eine Funktion auf mehreren Plattformen funktionieren muss (z. B. Web, Mobilgerät, POS-Systeme), teilen Sie sie nach Schnittstelle auf.

  Beispiel: Statt „Als Kunde möchte ich eine Kaffeebestellung aufgeben“ unterteilen Sie es in „Als Kunde möchte ich eine Bestellung über die mobile App aufgeben“ und „Als Kunde möchte ich eine Bestellung über die Website aufgeben“.

• D : Daten – Wenn eine Funktion mehrere Arten der Datenverarbeitung erfordert, sollten Sie eine Aufschlüsselung basierend auf den unterschiedlichen Datenanforderungen in Betracht ziehen.

  Beispiel: Anstelle von „Als Café-Manager möchte ich einen Umsatzbericht“ erstellen Sie separate Storys für „Als Café-Manager möchte ich eine tägliche Umsatzübersicht“ und „Als Café-Manager möchte ich eine monatliche Umsatzaufschlüsselung“.

• R : Regeln – Wenn eine Story mehrere Geschäftsregeln hat, trennen Sie sie in einzelne Stories.

  Beispiel: Statt „Als Kunde möchte ich für jeden Einkauf Treuepunkte“ teilen Sie es in „Als Kunde möchte ich 10 Punkte pro ausgegebenem Dollar verdienen“ und „Als Kunde möchte ich, dass meine Punkte nach 12 Monaten verfallen“ auf.

Durch die Anwendung des SPIDR -Frameworks können Teams sicherstellen, dass große, komplexe User Stories in kleine, unabhängige Aufgaben zerlegt werden, die innerhalb eines Sprints abgeschlossen werden können.

Beispielsweise die User Story:

Als Kunde, der häufig Kaffee bestellt, möchte ich in der App eine Liste meiner vergangenen Einkäufe sehen, um meine Lieblingsgetränke schnell nachbestellen zu können, ohne sie manuell suchen zu müssen.

Könnte aufgeteilt werden in:

• Bestellverlauf anzeigen

• Filtern vergangener Bestellungen nach Datum

• Herunterladen früherer Rechnungen

• Exportieren von Bestellübersichten für Steuerzwecke

• Sortierung nach Einkaufskategorien

Durch den Einsatz von SPIDR wird sichergestellt, dass große Stories überschaubar bleiben und innerhalb eines Sprints abgeschlossen werden können.

8. Zusammenarbeiten und iterieren

• Besprechen Sie User Stories mit Ihrem Team.

• Auf Grundlage des Feedbacks verfeinern.

• Aktualisieren Sie nach Bedarf während des gesamten Entwicklungsprozesses.

• Beziehen Sie Stakeholder in regelmäßige Überprüfungen ein.

Häufige Fehler, die Sie vermeiden sollten

• Zu vage: „Als Benutzer möchte ich ein besseres Erlebnis.“ (Es fehlt an Spezifität.)

• Zu technisch: „Als Entwickler möchte ich React-Komponenten verwenden.“ (Nicht benutzerorientiert.)

• Zu groß: „Als Kunde möchte ich meinen gesamten Bestellverlauf verwalten.“ (Teilen Sie ihn in kleinere Geschichten auf.)

• Mangelnde Zusammenarbeit: Wenn keine Diskussionen mit dem Team stattfinden, führt dies zu unklaren Erwartungen.

• Akzeptanzkriterien ignorieren: Ohne sie fehlen den Stories klare Kriterien für den Abschluss.

Abschließende Gedanken

Während User Stories eine beliebte Methode sind, um Anforderungen in Agile-Teams zu erfassen, gibt es auch andere Ansätze, die es wert sind, untersucht zu werden. Eine Alternative ist das Jobs-to-be-Done (JTBD) -Framework. JTBD konzentriert sich darauf, die zugrunde liegenden Motivationen hinter den Bedürfnissen eines Benutzers zu verstehen, anstatt nur die Funktionalität zu beschreiben. Anstatt User Stories im typischen Format zu schreiben, verwendet JTBD einen strukturierten Ansatz wie:

Wenn [Situation], möchte ich [Motivation], damit ich [erwartetes Ergebnis] kann.

Zum Beispiel:

Wenn ich morgens in Eile bin, möchte ich meinen gewohnten Cold Brew vorbestellen, um ihn schnell abholen zu können, ohne in der Schlange zu stehen.

Durch die Berücksichtigung von Ansätzen wie JTBD können Teams die tieferen Gründe hinter den Benutzeranforderungen besser verstehen, was zu innovativeren Lösungen führen kann.

Gute User Stories machen die Entwicklung reibungsloser, indem sie Teams auf einer Linie halten und sich auf die Wertschöpfung konzentrieren. Indem Sie diese Richtlinien befolgen, den 3C-Ansatz verwenden und das SPIDR-Framework nutzen, um große Stories aufzuteilen, können Sie sicherstellen, dass Ihre Stories klar, umsetzbar und aussagekräftig sind.

Darüber hinaus kann die Qualität von User-Storys erheblich verbessert werden, wenn man Zeit in Sitzungen zur Verfeinerung von User-Storys investiert, bevor diese in die Entwicklung gelangen. Denken Sie daran, dass eine gute User-Story nicht nur einen Bedarf erfasst, sondern auch zur Zusammenarbeit und Kreativität anregt.

Sind Sie bereit, Ihre nächste großartige User Story zu schreiben? Dann legen wir los!