Ungefähre Lesedauer: 3,5 Minuten

Es gibt zwei Möglichkeiten, User Stories detaillierter zu gestalten

Es gibt zwei Möglichkeiten, User Stories detaillierter zu gestalten

User Stories beschreiben aus Sicht des Nutzers den Grund, weshalb ein zu erstellendes Produkt genutzt werden soll. Zu Beginn der agilen Arbeit werden diese von den Entwicklerteams bewusst unspezifisch formuliert. Im späteren Verlauf werden die unkonkreten User Stories weiter spezifiziert. Hierfür gibt es zwei Methoden: du kannst deine User Story splitten oder weitere Akzeptanzkriterien hinzufügen. Welche Variante besser geeignet ist, kannst du hier nachlesen!

Methode 1: Splitte deine User Stories auf!

In der Regel sollte eine User Story so kurz und prägnant gehalten sein, dass sie in einer Iteration fertiggestellt werden kann. Statt einer bereits ausführlichen Story weitere Details hinzuzufügen, kannst du die User Story in „Sub-Stories“ splitten. Dadurch wird sichergestellt, dass sie übersichtlich bleibt und in der vorgegebenen Zeit erfolgreich abgeschlossen werden kann.

Folgendes Beispiel veranschaulicht einen solchen Fall:

Deine Story lautet:

Als Nutzer kann ich mich mit meinem Social Media Account einloggen.

Diese User Story ist relativ vage und soll nun konkretisiert werden. Damit nicht jede Variante einfach aufgezählt wird, erstellst du Sub-Stories, die deine Story weiter erläutern:

  • Als Nutzer kann ich mich mit meinem Facebook Account einloggen.
  • Als Nutzer kann ich mich mit meinem LinkedIn Account einloggen.
  • Als Nutzer kann ich mich mit meinem Twitter Account einloggen.

Wann ist diese Methode sinnvoll?

  1. Die User Story ist bereits umfangreich – Ist deine User Story zwar vage umschrieben, aber dennoch umfangreich, dann ist die Aufsplittung deiner Details in Sub-Stories empfehlenswert. Erst recht, wenn mehrere Details hinzukommen.
  2. Der Product Owner möchte die Unterpunkte priorisieren – Möchte der PO zum Beispiel das Einloggen mit LinkedIn höher priorisieren als mit Twitter, dann eignen sich die Sub-Stories. Diese kann der PO ganz normal priorisieren. Das Team liefert entsprechend der priorisierten Sub-Stories Ergebnisse in einer bestimmten Zeit.

Methode 2: Füge Akzeptanzkriterien hinzu!

Eine User Story besteht aus der eigentlichen Anwendererzählung, in der der Nutzer, sein Wunsch und der Nutzen des Produkts umrissen wird. Außerdem kann eine User Story Akzeptanzkriterien beinhalten, die das Produkt erfüllen muss, damit die Bedürfnisse des Nutzers erfüllt werden. Diese Akzeptanzkriterien kannst du z.B. auf die Rückseite deiner physischen Karteikarte auflisten oder in die Software eingeben, die du für dein Backlog benutzt. Es ist eine Art Checkliste, die deine User Story näher umschreibt.

Wie können Akzeptanzkriterien definiert werden?

Beim Schreiben einer User Story ist nicht sofort ersichtlich, ob und welche Akzeptanzkriterien benötigt werden. Hier hilft das Gespräch mit allen Beteiligten, um zwischen den Zeilen der User Story zu lesen. Dieses Gespräch wird häufig als Product Backlog Refinement (aktueller Begriff) oder Grooming (veralteter Begriff) bezeichnet. Erst durch die Kommunikation mit den Stakeholdern bzw. dem Autor der User Story und dem Entwicklerteam kommen Fragen auf, die durch die Akzeptanzkriterien beantwortet werden.

Die klassischen W-Fragen helfen dabei, die Story von allen Seiten zu beleuchten.

Die wichtigsten W-Fragen (wer, was, warum) werden bereits in der User Story beantwortet. Mit weiteren W-Fragen wie zum Beispiel wie oft, wann, welche Folgen etc. kommst du deinen Kriterien näher. Dabei kannst du sinnvolle Schlüsselwörter kombinieren, die zu deinem Produkt und deinem Nutzer passen. Es werden nur für die Fragen Akzeptanzkriterien formuliert, die sinnvoll beantwortet werden können.

Das Hinzufügen der Akzeptanzkriterien kannst du so formulieren:

Als Nutzer kann ich mich mit meinem Social Media Account einloggen.

Beispiel Akzeptanzkriterien:

  • Einloggen mit Facebook möglich.
  • Einloggen mit LinkedIn möglich.
  • Einloggen mit Twitter möglich.

Wann ist diese Methode sinnvoll?

  1. Die User Story kann trotz weiterer Akzeptanzkriterien in einer Iteration abgeschlossen werden – die weiteren Details sollten nur dann aufgenommen werden, wenn die User Story dadurch nicht zu groß wird. Hier ist die Einschätzung des Entwicklungsteam relevant.
  2. Alle aufgeführten Akzeptanzkriterien haben eine ähnliche Priorität – Akzeptanzkriterien können nicht priorisiert werden. Daher sollten die weiteren Details nur als solche in die User Story fließen, wenn sie gleichwertig in ihrer Wertung sind. Das ist dann der Fall, wenn die weiteren Spezifizierungen nicht wesentlich mehr Aufwand bedeuten, weil sie relativ ähnlich erstellt und getestet werden können.

Zum Beispiel ist das für diese User Story sinnvoll: Als Nutzer sollte ich ein starkes Passwort eingeben müssen, wenn ich ein Konto erstelle.

Akzeptanzkriterien:

  • Mind. 8 Zeichen, aber nicht mehr als 20
  • Mind. eine Ziffer
  • Mind. ein Großbuchstabe
  • Mind. ein Kleinbuchstabe
  • Mind. ein Sonderzeichen

 Sie wollen mehr erfahren? Besuchen Sie unsere Trainings  Zu den Trainings
Fazit: Nutze beide Methoden und entscheide von Fall zu Fall!

Beide Varianten sind sinnvolle Methoden, um deine User Story erfolgreich umzusetzen. Daher solltest du zusammen mit deinem Team für jede Story neu entscheiden, welche Methode für euch geeignet ist. Wichtig ist, dass deine User Story nicht zu groß wird und dass eventuell formulierte Akzeptanzkriterien nicht priorisiert werden müssen.

In der Scrum Academy lernst du, was du beim Schreiben von User Stories beachten musst und wie du Akzeptanzkriterien für Anforderungen formulierst. Dafür stehen dir unsere Trainer zur Seite, die dir persönlich Fragen rund um Scrum beantworten und dich zum Certified Product Owner schulen. Wann die Schulungen stattfinden? Hier findest du alle Informationen zu unseren Product Owner Trainings!