User Story – Definition, Aufbau und Beispiele

User Stories sind aus der Softwareentwicklung nicht mehr wegzudenken. Hier erfahren Sie…

• …was eine User Story ist
• …wie sie richtig formuliert wird
• …auf was man bei der Arbeit mit User Stories achten muss

Los geht’s!

Was ist eine User Story?

Das agile Projektmanagement nutzt User Stories, um eine Brücke zwischen Kunden und Entwicklern zu schlagen. In 1 bis 2 Sätzen werden Anforderungen an eine Software definiert, die auch ohne technische Kenntnisse nachvollziehbar sind.

Definition

Beispiel:

Als Autor möchte ich automatisches Speichern in meinem Textverarbeitungsprogramm, damit kein neu geschriebener Text verloren geht.

Aufbau

Der Inhalt einer User Story besteht aus 3 Teilen:

• Rolle (Wer) = späterer Nutzer der zu entwickelnden Lösung
• Funktion (Was) = Erwartung des späteren Nutzers an die Software
• Nutzen (Warum) = späterer Mehrwert der zu entwickelnden Lösung

User Stories richtig formulieren

Template

Um die WER-, WAS- und WARUM-Fragen von User Stories zu beantworten, ist es sinnvoll, sich an einer Vorlage zu orientieren. Besonders, wenn Sie mehrere Anwendererzählungen erstellen wollen, ist der Aufbau dadurch einheitlich.

Für das Schreiben einer User Story wird daher in der Regel eine Satzschablone verwendet. Zum Beispiel:

Als (Rolle) möchte ich (Funktion), damit (Nutzen).

Beispiele

• Als EC-Karten-Nutzer möchte ich kontaktlos bezahlen, damit ich beim Einkaufen Zeit spare.
• Als Vertriebsmitarbeiter möchte ich auf meiner CRM-Startseite eine Liste aller nicht-kontaktierten Leads sehen, damit ich diese schnellstmöglich anrufen kann.
• Als Projektmanager möchte ich Projektzeiten zentral erfassen, damit die Stunden abgerechnet werden können.

Bewertungsmethoden

Es gibt 3 wichtige Bewertungen für eine User Story:

1. Aufwand
2. Nutzen
3. Priorität

Die Bewertung wird in der Regel vom Entwicklerteam vorgenommen.

Die Aufwandsschätzung

Um den Aufwand einer User Story anzugeben gibt es unterschiedliche Methoden. Gängig sind die Verwendung von Story Points oder Personentagen.

In agilen Projekten nutzt man Story Points, die einfachen Zahlen entsprechen. Je größer die Zahl, desto größer der Aufwand der User Story. Dadurch ergeben sich relative Werte, die anzeigen, welche Anwendererzählungen schneller umgesetzt werden können als andere.

Damit sich das Team innerhalb eines Sprints (Umsetzungsphase) nicht zu viel vornimmt, ist es sinnvoll vorher festzulegen, wie viele Story Points zur Verfügung stehen.

Wer eher klassisch arbeitet und sein Projekt z.B. auf Stundenbasis abrechnen muss, ist mit der Schätzung in Personentagen besser bedient.

Der Nutzen

Hier geht es nicht mehr nur um den Mehrwert für den User, sondern auch darum, welchen Nutzen, die neue Funktion für den Hersteller hat.

Geht es hier um ein begehrtes Feature, das in Zukunft von besonders vielen Nutzern gebraucht wird? Wenn ja, würde dadurch für den Hersteller der Gesamtwert der Software steigen.

Handelt es sich um ein Feature, das nur einem einzelnen Nutzer Mehrwert liefert, lohnt sich die Entwicklung im Zweifelsfall nicht.

Die Priorisierung

Die Priorität einer User Story setzt sich aus dem Nutzen und dem Aufwand zusammen.

hoher Nutzen + geringer Aufwand = hohe Priorität

geringer Nutzen + hoher Aufwand = niedrige Priorität

Die Eigenschaften einer guten User Story

User Stories sollten 6 Kerneigenschaften erfüllen. Diese sind im INVEST-Prinzip festgehalten.

Akzeptanzkriterien – dann gilt eine User Story als erfüllt

Um zu überprüfen, ob eine Anwendererzählung vollständig umgesetzt wurde, werden vor der Entwicklung Akzeptanzkriterien festgelegt. Sind die Kriterien erfüllt, ist auch die User Story abgeschlossen.

Akzeptanzkriterien repräsentieren wesentliche Ereignisse/Ergebnisse, die mit der User Story erreicht werden sollen. So wird gemessen, ob die Story passend zum Verwendungszweck umgesetzt wurde.

Um diese Kriterien zu erarbeiten, nutzt man W-Fragen (Wer? Was? Warum? Wann? Wo? etc.) und orientiert sich an Schlüsselbegriffen der ursprünglich formulierten Anwendererzählung.

Außerdem kann man die späteren User fragen, wie sie die Umsetzung der Story testen würden.

User Stories richtig dokumentieren – Die Story Card

Klassischer Weise wird eine User Story auf einer Karteikarte oder einem Klebezettel festgehalten – der Story Card.

Dort sollte der Platz ausreichen, um die Beschreibung der Story, die Story Points und die Akzeptanzkriterien unterzubringen. Zusätzlich können Sie einen Titel vergeben und die Priorisierung ergänzen.

Reicht der Platz nicht, ist das ein Hinweis darauf, dass die User Story zu umfangreich ist. Sie muss entweder präziser formuliert oder in mehrere Stories aufgeteilt werden.

Fazit

User Stories sind die wohl beste Möglichkeit, Softwareanforderungen kurz und einfach zu halten, aber dennoch präzise zu formulieren. Außerdem wird sichergestellt, dass tatsächlich die späteren Nutzer im Fokus sind.

Mit dem Mehrwert der neu entwickelten Funktionen entsteht ein Win-Win für User und Hersteller.

Weitere interessante Artikel