In diesem Tutorial erfahren Sie etwas über einen wichtigen Bestandteil des agilen Ansatzes in der Softwareentwicklung: User Stories.

Ich werde Ihnen erklären, was User Stories sind, häufige Fallstricke, die ich beim Erstellen von User Stories beobachtet habe, und die Rahmenbedingungen, die existieren, um zu validieren, ob Ihre User Story „gut“ ist.

Hier ist, was wir behandeln werden:

Die Anfänge von Agile

Die Chancen stehen gut, dass Sie von Agile Development und User Stories gehört haben. Wenn nicht, lassen Sie uns eine kurze Geschichtsstunde einlegen:

User Stories sind Teil eines größeren Konzepts namens Agile-Methoden.

Agile-Methoden gibt es seit 2001, als sich 17 angesehene Software-Ingenieure in einem Skigebiet in Utah trafen und das mittlerweile berüchtigte Agile Manifest schufen.

Wenn Namen wie Robert Martin, Martin Fowler und Kent Beck Ihnen nichts sagen, suchen Sie sie nach dem Lesen dieses Artikels auf. Sie verfügen über ein enormes Wissen und haben der Software-Welt eine flüssigere Art der Projektabwicklung gegeben, genannt Agile.

Was ist Agile?

Agile ist eher eine Denkweise als eine vorgeschriebene Methode. Es gibt vorgeschriebene Methoden wie Scrum und Kanban, aber Agile ist ein Konzept.

Agile fördert Zusammenarbeit, schnelles Feedback und häufige Wertlieferung an den Benutzer.

Die agile Denkweise fördert Flexibilität in der Projektplanung, was einen starken Kontrast zu ihrem damaligen Konkurrenten, der Wasserfall-Projektplanung, darstellt, die sehr starr war, was geliefert wurde und wann.

Agile-Methoden fördern es, zu Beginn „gerade genug“ Recherche zu betreiben, um das Projekt zu starten, und dann zu lernen, zu iterieren und das Design sowie das Ergebnis nach Bedarf während des Projekts zu ändern, bis der endgültige Code geliefert wird. Dieser Ansatz „Ändern und Lernen, während man voranschreitet“ wird als „adaptive Planung“ bezeichnet.

Agile fördert die schnelle und häufige Lieferung von etwas Wertvollem, normalerweise in Form der Bereitstellung von Code in der Produktion am Ende jedes zweiwöchentlichen „Sprints“. Dies ist wiederum sehr unterschiedlich von der traditionellen Wasserfallplanung, die oft Monate an Entwicklung erfordert, bevor eine für den Benutzer sichtbare Änderung in die Produktion geliefert werden kann.

Ein weiterer wichtiger Teil von Agile ist der Fokus auf die enge und häufige Zusammenarbeit der Stakeholder. Produkt, QA, Engineering und Vertrieb haben alle einen großen Einfluss und ständiges Feedback während des gesamten Projektlebenszyklus.

Jetzt, da Sie ein wenig mehr darüber wissen, wie Agile funktioniert, lassen Sie uns tiefer eintauchen, wie wir den Wert für den Benutzer validieren.

Hier kommt die User Story ins Spiel.

Was ist eine User Story?

Eine User Story ist eine einfache Möglichkeit, um den Ingenieur mit dem Endziel der Software zu verbinden.

Sie ist so gestaltet, dass ein Nicht-Techniker sie lesen und verstehen kann, was geliefert wird, und dass ein Ingenieur sie betrachten und den Wert sowie die Validierung dieses Wertes erkennen kann.

Struktur einer User Story

Als [Benutzertyp], wenn ich [Aktion ausführe], [erwartetes Ergebnis]

Im einfachsten Fall ist das alles.

Du legst den Schwerpunkt auf den Endbenutzer und den „Wert“, den du liefern wirst.

Lass uns die Eingaben genauer betrachten:

  • Art des Benutzers: Es gibt nicht den einen „Benutzer“ für alle. Du hast „Admin-Benutzer“, du hast „angemeldete Benutzer“, du hast „Benutzer mit Berechtigung X“ oder „Benutzer mit Rolle Y“. Hier wird spezifiziert, wer die Aktion ausführt

  • Aktion ausführen: Was macht der Benutzer? Den „Anmelden“-Button klicken? Einen Datensatz löschen? Ein Formular absenden?

  • Erwartetes Ergebnis: Was soll geschehen, nachdem dein Benutzer die Aktion ausgeführt hat? Wenn sie mit der richtigen E-Mail-Adresse und dem richtigen Passwort auf „Anmelden“ geklickt haben, wohin sollten sie geleitet werden? Wenn sie mit einer falschen E-Mail-Adresse und einem falschen Passwort auf „Anmelden“ geklickt haben, was soll geschehen?

Beispiel für Benutzerstories:

Lass uns Beispiele für Benutzerstories für eine Anmeldeseite ansehen.

Es gibt nichts Besseres als Beispiele.

Lass uns die Szene setzen. Du hast eine Anmeldeseite mit einem Eingabefeld für eine E-Mail-Adresse und einem Eingabefeld für ein Passwort. Du hast einen Absenden-Button. Das ist alles.

Was sind die verschiedenen Permutationen, die aus der Perspektive des Benutzers auf dieser Seite passieren können?

Als eingeloggter Benutzer, wenn die Seite lädt, werde ich zur Startseite für eingeloggte Benutzer umgeleitet.

Wenn ich bereits eingeloggt bin, möchte ich meine Daten nicht erneut eingeben, leite mich einfach zur Startseite für eingeloggte Benutzer um.

Als nicht eingeloggter Benutzer, wenn ich die richtige E-Mail-Adresse, aber das falsche Passwort eingebe und auf Anmelden klicke, erscheint eine Fehlermeldung.

Ich bin ein Benutzer, der nicht bereits eingeloggt ist, und ich habe falsche Daten eingegeben. Ich sollte nicht eingeloggt sein.

Als nicht eingeloggter Benutzer, wenn ich eine falsche E-Mail-Adresse und ein falsches Passwort eingebe und auf Anmelden klicke, erscheint eine Fehlermeldung.

Noch einmal. Ich bin kein eingeloggter Benutzer. Ich habe falsche Daten eingegeben, ich sollte nicht eingeloggt sein.

Als nicht eingeloggter Benutzer, wenn ich die richtige E-Mail-Adresse und das richtige Passwort eingebe und auf Anmelden klicke, werde ich zur Startseite für eingeloggte Benutzer umgeleitet.

Diesmal bin ich nicht bereits eingeloggt, ich gebe die richtigen Daten ein und klicke auf Anmelden. Ich bin im System eingeloggt.

Kannst du sehen, wie sich all dies auf den Benutzer konzentriert?

Du magst bemerken, dass einige des „erwarteten Verhaltens“ oben nicht vollständig definiert sind. Wir werden das später in den Akzeptanzkriterien ansprechen.

Wie man gute User Stories erstellt

Es gibt ein gutes Modell namens INVEST-Modell, das ganz einfach zeigt, wie man erkennt, ob deine User Stories gut sind.

INVEST-Modell:

  • Independent: Kann separat entwickelt werden.

  • Negotiable: Offen für Diskussion und Änderungen.

  • Valuable: Liefert Wert für den Nutzer.

  • Estimable: Kann in Bezug auf den Aufwand geschätzt werden.

  • Small: Passt in einen Sprint.

  • Testable: Hat klare Akzeptanzkriterien.

Wenden wir dieses INVEST-Modell auf eines der oben genannten Beispiele für User Stories an:

Als nicht angemeldeter Nutzer, wenn ich die richtige E-Mail-Adresse und das Passwort eingebe und auf Login klicke, werde ich zur Startseite für angemeldete Nutzer weitergeleitet.

(Ich werde hier einige Annahmen treffen, da dies eine theoretische Codebasis und ein theoretisches Projekt ist)

Ist diese Geschichte unabhängig? Ich würde sagen, ja. Es ist eine kleine Geschichte, die nur wenige Komponenten umfasst, die wahrscheinlich bereits existieren. Wenn die Datenbank jedoch für das Projekt noch nicht erstellt wurde, hätten wir eine Abhängigkeit. Dann wäre sie nicht mehr unabhängig.

Ist sie verhandelbar? Nun, ja. Diese Geschichte könnte leicht geändert werden, um auf die Profilseite des Benutzers anstelle seiner Startseite umzuleiten.

Diese Geschichte ist definitiv wertvoll. Sobald sie implementiert ist, kann der Benutzer sich einloggen. Wenn die Geschichte wäre:

Als nicht angemeldeter Benutzer, wenn ich die richtige E-Mail-Adresse und das Passwort eingebe und auf „Login“ klicke, passiert nichts

Wäre dies nicht wertvoll. Der Benutzer würde nichts daraus gewinnen.

Ist die Geschichte schätzbar? Wieder müssen wir einige Annahmen in diesem fiktiven Szenario treffen, aber ich hoffe, dass dies leicht geschätzt werden kann. Es ist eine prägnante Geschichte, die wenige Komponenten umfasst, in einem Bereich, mit dem jeder vertraut ist und klare Akzeptanzkriterien hat.

Die Geschichte ist sicherlich klein. Es gibt wenig Unklarheit darüber, was getan werden muss, es gibt nur einen Benutzerpfad und klare Ergebnisse. Lassen Sie uns eine Geschichte betrachten, die zu groß wäre:

Als nicht angemeldeter Benutzer sollte die Anmeldeseite wie erwartet funktionieren.

Wie weiter oben in diesem Artikel diskutiert, gibt es viele Möglichkeiten, wie die Anmeldeseite funktionieren kann und sollte. „Sollte wie erwartet funktionieren“ scheint all diese Permutationen abzudecken. Dies wäre zu groß, um effektiv als Geschichte zu dimensionieren, und wahrscheinlich zu groß, um in einem Sprint abgeschlossen zu werden.

Die Geschichte ist definitiv Testbar. Es gibt klare Benutzeraktionen, die ein klares Ergebnis haben. Diese Benutzerstory kann durch Unit-Tests, Integrationstests und manuelle Tests abgedeckt werden.

Es sieht so aus, als hätten wir eine gute Benutzerstory erstellt!

Wenn Sie die oben definierte Struktur verwenden und die Geschichte die Kriterien des INVEST-Modells erfüllt, ist es wahrscheinlich eine gute Geschichte.

Häufige Fallstricke bei der Erstellung von Benutzerstories

Ich habe in der Vergangenheit gesehen, dass Benutzerstories schiefgehen, wenn Menschen einige entscheidende Aspekte der Benutzerstory übersehen:

Fokus auf technische Aspekte

Wie meine Beispiele oben zeigen, ist die Benutzerstory nicht technisch.

Es sollte keine Bezugnahme auf einen Servicenamen, einen Datenbanknamen oder eine Validierung basierend auf etwas geben, das der Benutzer nicht sehen kann.

Sobald Ihre Geschichte vom Endbenutzer nicht mehr verstanden werden kann, haben Sie einen Fehler gemacht.

Konzentrieren Sie sich darauf, was der Benutzer tun wird und was der Benutzer sehen wird.

Schauen wir uns ein Beispiel für eine technisch fokussierte Geschichte an:

Als nicht angemeldeter Benutzer, wenn ich auf den Link „Passwort vergessen“ mit einer korrekten E-Mail-Adresse klicke, wird ein Datensatz in einer Datenbanktabelle protokolliert, der besagt, dass der Link zum Zurücksetzen des Passworts gesendet wurde.

Diese Geschichte kann von einem Benutzer nicht überprüft werden, und nicht-technische Benutzer verstehen möglicherweise nicht, was sie bedeutet.

Lassen Sie uns das beheben:

Als nicht angemeldeter Benutzer, wenn ich auf den Link „Passwort vergessen“ mit einer korrekten E-Mail-Adresse klicke, wird eine E-Mail an die angegebene E-Mail-Adresse mit einem Link zum Zurücksetzen des Passworts gesendet.

Nicht technische Benutzer können dies verstehen und es stellt den Fokus auf den Benutzer, nicht das Produkt.

Stakeholder-Zusammenarbeit

Agil ist kollaborativ.

Benutzergeschichten benötigen Input von Produkt, BA, QA, Ingenieuren und vor allem Benutzern.

So stellen Sie sicher, dass Sie liefern, was der Benutzer möchte. Viele Hände machen der Arbeit ein Ende.

Wenn zum Beispiel nur ein Entwicklungsteam Benutzergeschichten erstellt hätte, könnten sie so aussehen:

Als eingeloggter Benutzer werde ich auf die eingeloggte Startseite umgeleitet, wenn die Seite geladen wird.

Als nicht eingeloggter Benutzer wird bei Eingabe der korrekten E-Mail-Adresse, aber falschen Passworts und Klick auf Anmelden eine Fehlermeldung angezeigt.

Als nicht eingeloggter Benutzer wird bei Eingabe einer falschen E-Mail-Adresse und eines Passworts und Klick auf Anmelden eine Fehlermeldung angezeigt.

Und das ist großartig. Aber lassen Sie uns nun QA einbeziehen, die aus einer anderen Perspektive kommen, da sie unterschiedliche Erfahrungen mit Software haben:

Als nicht eingeloggter Benutzer werde ich auf die Startseite umgeleitet, wenn ich eine korrekte E-Mail-Adresse auf Hebräisch und ein korrektes Passwort eingebe.

Als nicht eingeloggter Benutzer werde ich bei Eingabe einer korrekten E-Mail-Adresse und eines Passworts und wiederholtem Klicken auf Anmelden auf die Startseite umgeleitet.

Super. Wir erhalten jetzt eine vielfältigere Sammlung von Benutzergeschichten, die mehr Situationen abdecken. Aber was passiert, wenn wir das Produkt involvieren?

Als nicht eingeloggter Benutzer sollte mein Passwort-Manager meine Benutzername und Passwort vorab laden, wenn die Seite geladen wird, und bei Klick auf Anmelden werde ich auf die Startseite umgeleitet.

Das Produktteam kennt die Benutzer. Sie wissen, dass Leute tatsächlich Passwort-Manager verwenden. Wir sollten sicherstellen, dass der Login immer noch korrekt funktioniert, auch wenn der Benutzer tatsächlich nichts eingibt (da der Text vom Passwort-Manager geladen wird).

Unklare Benutzerstories

Die Idee hinter einer guten Benutzerstory ist, dass sie von jedem, unabhängig von der Expertise, verstanden werden kann.

Wenn du eine Benutzerstory geschrieben hast, die von 10 verschiedenen Personen auf 10 verschiedene Arten interpretiert werden kann, bist du ein wenig falsch abgebogen.

Ich habe oben erwähnt, dass ich auf Akzeptanzkriterien eingehen würde, und jetzt ist der richtige Zeitpunkt dafür.

Lassen Sie uns die folgende Benutzerstory erneut untersuchen:

Als nicht eingeloggter Benutzer, wenn ich eine falsche E-Mail-Adresse und ein falsches Passwort eingebe und auf Anmelden klicke, erscheint eine Fehlermeldung.

Es gibt Unklarheiten darin.

Welche Meldung sollte erscheinen? Sollte das Benutzername-Textfeld nach einem ungültigen Login-Versuch zurückgesetzt werden oder mit dem zuvor eingegebenen Wert vorbelegt sein, wenn die Seite neu geladen wird? Was bedeutet „falsche E-Mail-Adresse“? Eine E-Mail-Adresse, die noch nie gesehen wurde, oder eine E-Mail-Adresse, die im Moment nicht gültig ist (kein Abonnement bezahlt, Abonnement gekündigt usw.)

Wie du siehst, sind Details wichtig.

Diese Benutzerstory ist ein ziemlich konstruiertes einfaches Beispiel, und ich habe viele Fragen dazu gefunden.

Lasst uns das Problem beheben:

Als nicht eingeloggter Benutzer, wenn ich eine E-Mail-Adresse eingebe, die nicht im System registriert ist und auf Anmelden klicke, erscheint eine Fehlermeldung.

Das hat die Fragen um die Benutzeraktion beseitigt, aber das Problem bezüglich der erwarteten Fehlermeldung nicht gelöst.

Geben Sie die Akzeptanzkriterien ein.

In der Benutzerstory müssen Sie eine Reihe von Akzeptanzkriterien haben, die festlegen, ob die Umsetzung der Benutzerstory wie erwartet ist.

Dinge wie:

  • Fehlermeldung: „Ungültige E-Mail-Adresse oder Passwort“

  • E-Mail-Adresse und Passwort-Textfeld werden beim Neuladen zurückgesetzt

  • Benutzer kann nicht auf Seiten zugreifen, für die eine Anmeldung erforderlich ist

  • Benutzer wird ein „Passwort vergessen“-Vorschlag angezeigt.

Die Akzeptanzkriterien legen fest, was von der Umsetzung erwartet wird.

Wie man mit Benutzerstories beginnt

Fange klein an.

Am Anfang wirst du nicht perfekt darin sein, Benutzerstories zu verfeinern und zu erstellen.

Das Erstellen von Benutzerstories ist ebenso sehr eine Kunst wie eine Wissenschaft. Übung macht den Meister.

Die Erstellung von Benutzerstories sollte in einer Gruppe erfolgen. Oft wird dies mit dem Ansatz der „3 Amigos“ durchgeführt, bei dem ein Ingenieur, eine Produkt-Person und ein QA zusammenkommen und verschiedene Varianten durchdenken, die unterstützt werden müssen.

Sobald Sie Ihr Projekt abgeschlossen haben, reflektieren Sie. Werfen Sie einen Blick zurück und sehen Sie, welche Lücken Sie in Ihren User Stories haben. Es wird Bugs geben, die von den Nutzern, von QA und UAT gefunden werden, und diese resultieren entweder aus Lücken in Ihren User Stories oder aus Lücken in Ihren Tests. So oder so sollten Sie aus ihnen für das nächste Mal lernen.

Fazit

Agil ist kollaborativ. Scrum ist kollaborativ. Die Erstellung von User Stories ist kollaborativ. Denken Sie daran.

Je mehr Menschen aus verschiedenen Fachbereichen Sie in die Brainstorming-Sitzungen zur Erstellung von User Stories einbeziehen, desto wahrscheinlicher ist es, dass Sie das vollständige Set an Workflows abdecken.

Der Nutzer steht im Fokus. Wenn Sie jemals Terminologie verwenden, die Ihr Nutzer nicht versteht, überdenken Sie die User Story.

Sie werden nicht von Anfang an perfekt darin sein, aber je mehr Sie es tun, desto schneller und effektiver werden Sie. Nehmen Sie das von jemandem an, der das seit über 10 Jahren macht. Der Unterschied in der Geschwindigkeit und Qualität meiner User Story-Erstellung heute im Vergleich zu vor 10 Jahren ist himmelweit entfernt.

Schauen Sie sich meine Blogbeiträge auf meiner Website Just Another Tech Lead an oder melden Sie sich für meinen wöchentlichen E-Mail-Newsletter hier an.