Max von der Nahmer

Wie schreibt man User Stories?

User Stories („Anwendererzählungen“) beschreiben einen Verbraucher und dessen Grund warum er den zu erstellenden Dienst nutzt. Diese User Stories sind absolut erforderlich zur Erstellung und Betreibung eines Dienstes, der die Bedürfnisse der Nutzer erfüllt. Es sollte sichergestellt werden, dass jedes Teammitglied User Stories schreibt und diese aus folgenden Gründen nutzt:

  • um nachvollziehen zu können was zu tun ist
  • um über ihre Arbeit aus der Sicht des Nutzers nachzudenken
  • um ihre Arbeit mit Kollegen zu besprechen
  • um ihre Arbeit zu priorisieren

Warum sind User Stories so wichtig?

Um den ersten Punkt (das Verstehen der Nutzerbedürfnisse) zu gewährleisten, ist es erforderlich zu zeigen, wie die Anwendererzählungen genutzt werden.

Um den vierten Punkt (das Verwenden agiler Methoden) zu gewährleisten, muss gezeigt werden, dass agile Werkzeuge und Techniken angewendet wurden, das beinhaltet das Arbeiten mit User Stories.

Um den fünften Punkt (häufige Wiederholung und Verbesserung) zu bestehen, ist es notwendig zu zeigen, wie die User Stories priorisiert werden und wie diese schnell und reibungslos von der Recherche zur Produktion gelangen.

Wie schreibt man eine User Story?

Was enthalten sein muss

Die User Stories sollten ausreichend Informationen enthalten, damit ein Produktmanager entscheiden kann, wie wichtig die Story ist. Folgende Punkte sollten immer einbezogen werden:

  • die Person, die den Dienst nutzt (Rolle)
  • wofür der Nutzer den Dienst braucht (Ziel/Wunsch)
  • warum der Nutzer den Dienst braucht (Nutzen)

Das richtige Format für User Stories

Gewöhnlich werden diese in dem Format "‚Als…möchte ich…, um…“ geschrieben."

Beispiel:

‚ Die User Story des Wählerverzeichnis-Dienstes lautet: ‚Als Einwohner des Vereinigten Königreichs möchte ich meine Informationen aus dem Wählerverzeichnis erhalten, um wählen zu können‘.
‚ Dieses Format muss nicht genutzt werden. Allerdings sollte das gewählte Format stets kurz Rolle, Ziel/Wunsch und Nutzen beschreiben.

Der Fokus liegt auf dem Nutzen

Der wichtigste Teil einer User Story ist der Nutzen. Dieser hilft dabei:

  • sicherzugehen, dass das richtige Problem gelöst wird
  • zu entscheiden, wann die Anwendung beendet ist und das Bedürfnis des Nutzers erfüllt ist

Tut man sich bei der Bestimmung des Nutzens schwer, sollte überdacht werden, ob die Funktion wirklich benötigt wird.

Akzeptanzkriterien

In jeder Story können außerdem Akzeptanzkriterien mitaufgenommen werden. Dabei handelt es sich um eine Liste aus Ergebnissen, die als Checkliste benutzt werden kann, um zu bestätigen, dass der Dienst korrekt umgesetzt wurde und die Nutzerbedürfnisse erfüllt sind. Oft werden diese als Liste verfasst und beginnen wie folgt: ‚Story ist erfüllt, wenn…‘

Beispiel:
Die Akzeptanzkriterien für das Wählerverzeichnis lauten:

  • ‘Story ist erfüllt, wenn der Nutzer weiß, wie man sich online registriert‘
  • ‘Story ist erfüllt, wenn der Nutzer weiß, wie man ein Formular herunterlädt um per Post zu wählen‘
  • ‘Story ist erfüllt, wenn der Nutzer weiß, wohin er das Formular senden muss‘

Die Akzeptanzkriterien können genutzt werden, um Nachweise (wie Tabellen und Diagramme) anzuknüpfen, die die Story unterstützen.

Epics

Große User Stories (die mehr als einige Wochen in Anspruch nehmen um entwickelt und getestet zu werden) werden in der Regel Epics genannt. Falls möglich, sollten Epics in kürzere Geschichten aufgeteilt werden, die innerhalb einer Iteration durchgeführt werden können.

Wie werden User Stories erfasst?

Jede User Story wird auf einer Story-Card dokumentiert und benannt. Als Karten dienen:

  • tatsächliche Karten, die an die Wand des Teams gepinnt werden
  • digitale Plattformen (z.B. Trello oder Pivotal)

Planung mit User Stories

Sollten viele User Stories existieren, ist es sinnvoll, diese in digitaler Form (Trello/Tabellen) zu dokumentieren und dann, als Teil der Planung, auf organische Karten zu übertragen. Alle User Stories sollten sich im Backlog befinden, wo der Produktmanager diese nach Priorität sortiert. Sie bleiben dort, bis das Team sich entscheidet, dass es bereit ist, an der Story zu arbeiten. Der Produktmanager und weitere relevante Teammitglieder werden dann eine ausführlichere Diskussion über die Story führen. Informationen, die aus dieser Unterhaltung hervorgehen, sollten in der User Story dokumentiert werden.

Ressourcen

Wikipedia In software development and product management, a user story is a description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function.

Wie hat Ihnen diese Seite gefallen?

Kontakt & Rückruf

Max von der Nahmer

Hinweise zur Verarbeitung Ihrer Daten finden Sie in unserer Datenschutzerklärung. Sie können der Verarbeitung jederzeit widersprechen.