User Stories sind eine agile Technik zur Definition von Produktfunktionalität und Anforderungen. Sie konzentrieren sich darauf, eine Geschichte für eine Aktion zu erzählen, die ein Benutzer ausführen wird, und welche Erwartungen bei Erfolg bestehen. Das Konzept der Benutzergeschichten ist weit verbreitet, aber das Erzählen guter Geschichten kann ziemlich schwierig sein.

User Stories sind in den letzten Jahren allerdings etwas in Verruf geraten, da sie zu stark vereinfachen und es ihnen an Empathie für den Benutzer mangelt.

Gute Nachrichten – es gibt einen besseren Weg! Man nennt sie Gurken, aber im Gegensatz zu den Essiggurken sind sie nicht dazu da, dein Leben zu versauern. (Es sei denn, Sie sind ein Gurkenliebhaber, nehme ich an!) 🥒

TL;DR

Wenn Sie es etwas eilig haben, hier die Kurzfassung (obwohl ich Sie ermutigen möchte, weiterzulesen, um auf die Vorlagen zuzugreifen!)

• User Stories konzentrieren sich auf den Benutzer, nicht auf das Produkt.
• Skizzieren Sie Ihre Personas, um Kontext hinzuzufügen.
• Fügen Sie Ihren Geschichten Empathie hinzu, um Handlungen und Motivationen zu verstehen.
• Gewürzgurken: eine bessere Art, Geschichten zu schreiben.
• Verwenden Sie Gurken, um sich auf die Ergebnisse zu konzentrieren, nicht nur auf den Output.

Was sind User Stories?

User Stories sind kurze, einfache Beschreibungen einer Lösung, die Ihr Team entwickelt hat, und zwar aus der Perspektive der Person, die die Interaktion durchführt. Sie sind Teil eines größeren Epos, in dem das eigentliche Problem beschrieben wird, das gelöst werden soll, und warum man es löst.

Das entscheidende Wort ist hier Benutzer, d. h. eine Benutzergeschichte stellt den Benutzer in den Mittelpunkt, nicht das Produkt.

Eine User Story konzentriert sich in der Regel auf drei Bereiche:

• Als(wer)
• Ich möchte(was)
• So dass(warum)

Darauf folgen in der Regel Akzeptanzkriterien, die festlegen, wie Sie wissen, ob die Interaktion erfolgreich war.

Wer: Verwendung von Personas zur Skizzierung von User Stories

Wenn Sie Ihre Benutzer noch nicht definiert oder verstanden haben, dann sollten Sie auch keine User Stories schreiben. Beginnen Sie zunächst mit einer Erkundung, zeichnen Sie eine Customer Journey auf und erstellen Sie relevante User Personas, die Ihnen helfen, diese Geschichten weiter zu definieren.

Eine Persona kann Ihnen helfen, das „Wer“ der Benutzergeschichte zu verstehen und in einen Kontext zu stellen – mit anderen Worten, wer diese Interaktion durchführt.

Dies ist wichtig, da Sie unweigerlich verschiedene Kundensegmente, Rollen und Berechtigungen haben werden, so dass es wichtig ist, diese Interaktionen so zu definieren, dass sie den verschiedenen Arten von Benutzern gerecht werden.

Was: Interaktionen zwischen Benutzergeschichten

Das „Was“ in einer User Story konzentriert sich auf die Interaktion selbst. Das Schwierige dabei ist, sicherzustellen, dass sich das „Was“ auf das konzentriert, was der Benutzer tun muss, und nicht auf das, was der Benutzer tun möchte, und das ist der Punkt, an dem die typische Story-Vorlage ein wenig auseinanderfällt.

Um der Geschichte selbst ein wenig Empathie zu verleihen, ist es wichtig, hervorzuheben, wie sich der Nutzer bei einer bestimmten Aktion fühlen könnte.

Niemand möchte zum Beispiel ein kompliziertes Passwort mit Großbuchstaben, Sonderzeichen und einer Mindestlänge eingeben – aber er weiß, dass er es tun sollte. In diesem Fall ist es etwas, das der Benutzer tun muss.

Warum: Der Grund für die Aktion der User Story

Der dritte Teil der User-Story-Vorlage ist das „Warum“, d. h. warum der Benutzer eine bestimmte Aktion durchführen möchte (oder muss).

Wir kehren zu unserem vorherigen Beispiel der Eingabe von Kennwörtern zurück:

Als Administrator muss ich ein kompliziertes Passwort erstellen, damit mein Konto sicher ist.

Wir verstehen jetzt das Wer, Was und Warum der Geschichte – aber es gibt da ein Problem. Hier fehlt es noch an Einfühlungsvermögen und Kontext, denn seien wir ehrlich: Niemand will, dass komplizierte Passwörter vorgeschrieben werden, aber wir alle wollen sichere Konten.

Beim Testen würde das QA-Team lediglich prüfen, ob das Passwort sicher ist, und nicht, ob der Prozess für den Benutzer frustrierend ist.

Geben Sie die Gherkin-Benutzergeschichtenvorlage ein

Gherkins sind eine Möglichkeit, User Stories zu ergänzen und ein vollständiges Szenario zu erstellen, das Entwicklern und Testern hilft, sowohl das Ergebnis als auch den Output einer bestimmten Benutzerinteraktion zu verstehen.

1. Scenario – das Verhalten, das Sie beschreiben werden
2. Given – den Anfangszustand des Szenarios
3. When – eine bestimmte Handlung, die der Nutzer vornimmt
4. Then – ein überprüfbares Ergebnis, das in der Regel durch die Handlung in When
5. And – damit wird einer der drei anderen Vorgänge bei Bedarf fortgesetzt

Nehmen wir das zuvor beschriebene Passwort-Szenario:

1. Beim Festlegen eines Passworts (Scenario),
2. Given dass ich ein Kontoverwalter bin,
3. WhenIch gebe ein Passwort in das Passwortfeld ein,
4. ThenIch sollte vor den Passwortanforderungen gewarnt werden,
5. And Ich sollte die Möglichkeit haben, sofort Korrekturen vorzunehmen,
6. Then dass ich ein sicheres Konto erstellen kann.

Wir haben jetzt ein vollständiges Bild davon, wer die spezifische Maßnahme durchführt und welche Anforderungen an die Akzeptanzkriterien gestellt werden. Das Team weiß, welche potenziellen Frustrationen auftreten könnten, so dass es den Prozess reibungsloser gestalten kann.

In der Regel ist der Produktmanager oder Product Owner für das Schreiben der Gherkin-Storys verantwortlich, wodurch eine bessere Kommunikation zwischen den übrigen Teammitgliedern entsteht und sichergestellt wird, dass sich alle auf die Ergebnisse und nicht nur auf den Output konzentrieren.

Was sind Ihre Lieblingsmethoden, um Geschichten zu skizzieren? Sagen Sie mir Bescheid! ✌️