Während die meisten neuen Funktionen aus der Perspektive des Nutzers definiert werden sollten, übersehen wir in der Praxis oft das „Warum“ aus der Sicht des Nutzers, wenn wir die Anforderungen definieren, die Entwicklungsteams benötigen, um etwas zu bauen. Der Fokus einer Benutzerstory liegt auf der Erfahrung – was die Person, die das Produkt nutzt, erreichen möchte. Traditionelle Anforderungen konzentrieren sich auf Funktionalität – was das Produkt tun soll. Die verbleibenden Unterschiede liegen in den subtilen, aber entscheidenden Listen zu „Wer“, „Wie“ und „Wann“.

Benutzerstories sollten in einer oder zwei Sätzen verfasst werden, die erfassen, wer der Nutzer ist, was er möchte und warum. Eine einfache Struktur zur Definition von Funktionen oder Benutzerstories lautet wie folgt:
Als ______ möchte ich ______, damit ich ______ kann.
Beispiel:
Als Nutzer möchte ich mein Passwort zurücksetzen, damit ich im Falle eines Vergessens wieder Zugriff auf das System erhalte.
Trotz unterschiedlicher Ziele zielen sowohl Benutzerstories als auch Anforderungen letztendlich darauf ab, ein Produkt zu schaffen, das die Kunden lieben.
Was ist eine Benutzerstory?
Benutzerstoriessind Anforderungen, die aus der Perspektive des Endnutzers formuliert werden. Benutzerstories können auch als Epics, Themen oder Funktionen bezeichnet werden, aber sie folgen alle dem gleichen Format.
Grundsätzlich ist eine Benutzerstory eine klar formulierte Anforderung. Aus mehreren Gründen ist das Format der Benutzerstory zur beliebtesten Methode geworden, Anforderungen im Agile-Entwicklungsprozess auszudrücken:
- Sie konzentriert sich auf die Perspektive der Person, die die Lösung nutzt oder davon betroffen ist.
- Sie definiert Anforderungen in einer Sprache, die für diese Rolle bedeutungsvoll ist.
- Sie hilft, den eigentlichen Zweck hinter der Anforderung zu klären.
- Sie hilft, hochwertige Anforderungen zu definieren, ohne zu früh in detaillierte, niedrigstufige Details einzusteigen.
Identifizieren Sie die Nutzerziele und berücksichtigen Sie sofort den geschäftlichen Wert jeder Anforderung innerhalb der Benutzerstory.
Benutzerstories gelten typischerweise als bestehend aus drei Elementen – dem3C:

- CARD – Sollte auf einer Karte oder einem Post-it-Notizblock geschrieben werden.
- CGespräch – Holen Sie detaillierte Informationen vom Produktverantwortlichen (Produktverantwortlicher).
- CBestätigung – Stellen Sie sicher, dass sie korrekt implementiert wurde. Muss die Kriterien für die Benutzerakzeptanz erfüllen.
Format der Benutzerstory
Das Format einer Benutzerstory lautet wie folgt:
Als <Rolle>, Ich möchte <Ziel>, damit <Nutzen>
Diese beiden Beispiele zeigen Benutzerstories auf verschiedenen Ebenen, jedoch mit dem gleichen Format:
Auf Projekt-Ebene:
Als <Marketingleiter>, Ich möchte <die Kundenbetreuung zu verbessern>, damit <wir unsere Kunden behalten>.
- SMART-Ziele und INVEST für Benutzerstories erstellen
- Thema vs. Epic vs. Benutzerstory vs. Aufgabe
- Was bedeutet DEEP im Produkt-Backlog?
- Wie erstellt man eine Produktvision für ein Scrum-Projekt?
- Wie verwendet man ein Scrum-Board für agile Entwicklung?
- Wer erstellt Produkt-Backlog-Elemente oder Benutzerstories in Scrum?
- Was ist agile Schätzung?
- Was ist ein Story Point in Agile? Wie schätzt man eine Benutzerstory?
- Aufteilung von Benutzerstories – Vertikaler Slice vs. Horizontaler Slice