Allgemein, Tutorials

Veröffentlicht am 23. September 2021

Wie man gute User Storys in der agilen Softwareentwicklung schreibt

Veröffentlicht 8.10.2019 von Teagan Harbridge, Product Manager bei Easy Agile

Für viele Softwareentwicklungsteams, die sich um Agilität bemühen, kann die Idee, User Storys zu schreiben, wie ein weiteres agiles „Ding“ erscheinen, das über ihre bereits ausgelasteten Workloads hinausgeht.

Wenn du diesen Blogbeitrag liest, hast du auf jeden Fall etwas Zeit, um User Storys zu schreiben. Und gute dazu!

Schauen wir uns zunächst an, was eine User Story ist.

Mithilfe einer User Story können agile Softwareentwicklungsteams vereinfachte Beschreibungen der Anforderungen eines:einer Benutzer:in auf hoher Ebene erfassen, die aus der Sicht des:der Endbenutzer:in erstellt wurden.

Wie schreibt man User Storys?

Eine User Story folgt häufig der folgenden „Gleichung“:

Als X möchte ich Y um Z.

Lass uns dies noch einen Schritt weiter aufschlüsseln:

Als – das ist das WER. Für wen bauen wir das? Wer ist der:die Benutzer:in?

möchte ich – das ist das WAS. Was bauen wir? Was ist die Absicht?

um – das ist das WARUM. Warum bauen wir es? Was ist der Wert für den:die Kund:in?

Schauen wir uns einige einfache Beispiele an:

Als Internetbanking-Kund:in

möchte ich einen rollierenden Saldo für meine täglichen Konten sehen,

um meine Ausgaben nach jeder Transaktion verfolgen zu können.

ODER

Als Administrator:in

möchte ich in der Lage sein, andere Administrator:innen für bestimmte Projekte zu erstellen,

um meine Aufgaben effizienter delegieren zu können.

Wenn diese Gleichung befolgt wurde, sollten die Teams sicherstellen, dass ihre User Storys alle der folgenden Kriterien erfüllen:

  • Fasse dich kurz.
  • Drücke dich einfach & verständlich aus.
  • Schreibe aus der Sichtweise des:der Benutzer:in.
  • Mache den Vorteil / Wert der User Story klar – was ist der Grund für die User Story.
  • Beschreibe EINE Funktionalität. Im Zweifel teile das Geschriebene in zwei User Storys auf.
  • Schreibe User Storys als Team.
  • Benutze Akzeptanzkriterien

„Warum können wir nicht stattdessen einfach Features oder Aufgaben schreiben?“

Das ist eine gute Frage. Obwohl die meisten Teams diese Frage stellen, verstehen sie normalerweise nicht, welchen Wert das Schreiben von User Storys hat und dass sie ganz anderen Zwecken dienen als Funktionen.

User StorysAufgaben
Eine User Story = das WASDie Aufgabe = das WIE
User Storys beschreiben eine Funktion aus der Sicht des:der Benutzer:in.
Aufgeteilte Features
à in Geschäftsprozesse unterteilte Funktionen
 „Was sind die Aktivitäten, die wir durchführen müssen, um Resultate (User Storys) zu liefern?“
 
à Aufgaben sind individuelle Arbeitsanteile.

Tatsache ist, dass es leicht ist, in einem kontextlosen Zyklus zur Entwicklung von Funktionen begraben zu werden. Das Ziel besteht mehr darin, den Weg freizumachen, um Lösungen zu entwickeln, die deinen Kund:innen einen Mehrwert bieten. User Storys bringen diesen Kontext und diese Perspektive in den Entwicklungszyklus.

Akzeptanzkriterien

Mithilfe von User Storys können Teams die Bedürfnisse, Wünsche und Werte ihrer Kund:innen sowie die Aktivitäten, die sie zur Bereitstellung dieses Wertes ausführen müssen, berücksichtigen.

Die Sache, die diese beiden Dinge miteinander verbindet, ist ein Akzeptanzkriterium.

Akzeptanzkriterien bieten einen detaillierten Überblick über die Anforderungen eines:einer Benutzer:in. Sie helfen dem Team, den Wert der User Story zu verstehen.

Ziele von Akzeptanzkriterien

Akzeptanzkriterien helfen dabei,

  • zu klären, was das Team aufbauen soll, bevor es mit der Arbeit beginnt.
  • sicherzustellen, dass jeder ein gemeinsames Verständnis für das Problem / die Bedürfnisse des:der Kund:in hat.
  • dass die Teammitglieder abschätzen können, wann die User Story fertig ist.
  • die User Story durch automatisierte Tests zu überprüfen.

Schauen wir uns ein Beispiel einer fertigen User Story mit Akzeptanzkriterien an.

Als potenzielle:r Konferenzteilnehmer:in möchte ich mich online für die Konferenz registrieren können, damit die Registrierung einfach und papierlos ist.

Akzeptanzkriterien:

  • Konferenzteilnahmeformular
  • Ein:e Benutzer:in kann kein Formular senden, ohne alle Pflichtfelder (Vorname, Nachname, Firmenname, E-Mail-Adresse, Positionstitel, Rechnungsinformationen) ausgefüllt zu haben.
  • Informationen aus dem Formular werden in der Registrierungsdatenbank gespeichert.
  • Der Schutz vor Spam funktioniert.
  • Die Zahlung kann per PayPal, Debit oder Kreditkarte erfolgen.
  • Nach dem Absenden des Formulars wird eine Bestätigungs-E-Mail an den:die Teilnehmer:in gesendet.

Vor diesem Hintergrund sollten die Teams sicherstellen, dass ihre Akzeptanzkriterien folgende Kriterien erfüllen:

  • negative Szenarien der Funktion
  • funktionale und nicht-funktionale Anwendungsfälle
  • Leistungsbedenken und Richtlinien
  • Was ist das Ziel des Systems / Features?
  • Konsequenzen einer User Story auf andere Features
  • UX-Kriterien

Die Akzeptanzkriterien sollten Folgendes NICHT umfassen:

  • Codeüberprüfung durchgeführt
  • Leistungstests durchgeführt
  • Abnahme und Funktionsprüfung durchgeführt

Warum nicht?

Deine Akzeptanzkriterien sollten keines der oben genannten Kriterien enthalten, da dein Team bereits ein klares Verständnis dafür haben sollte, was ihre „Definition of Done“ (DoD) beinhaltet, zum Beispiel:

  • Unit / integrated Test
  • bereit für den Abnahmetest
  • auf dem Demo-Server bereitgestellt
  • bereit zur Veröffentlichung

Du möchtest dein Team dazu bringen, User Storys zu schreiben, bist dir aber nicht sicher, wie du anfangen sollst?

Dann lade das „Writing Good User Stories Training [PDF]“ herunter.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.