Allgemein, Tutorials
Veröffentlicht am 23. September 2021
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.
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:
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 Storys | Aufgaben |
| Eine User Story = das WAS | Die 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.
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.
Akzeptanzkriterien helfen dabei,
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:
Vor diesem Hintergrund sollten die Teams sicherstellen, dass ihre Akzeptanzkriterien folgende Kriterien erfüllen:
Die Akzeptanzkriterien sollten Folgendes NICHT umfassen:
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:
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.
