So schreiben Sie User Stories: Eine vollständige Anleitung

User Stories sind ein wesentlicher Bestandteil der richtigen agilen Softwareentwicklung: Schauen wir uns ihre Rolle an und lernen, wie man User Stories schreibt.

Agile Frameworks sind eine beliebte und effektive Methode, um die Softwareentwicklung zu strukturieren und Aufgaben zu delegieren. Das Schreiben von User Stories (nicht zu verwechseln mit dem Schreiben eines Testimonials) ist ein Werkzeug in der agilen Entwicklung, das es Entwicklern ermöglicht zu verstehen, was getan werden muss und wie eine Anforderung erfüllt werden kann. Das macht sie zu einem sehr wichtigen Ausgangspunkt – aber es bedeutet auch, dass sie sorgfältig gebaut werden müssen. Folgendes sollten Sie wissen.

Was ist eine User-Story?

Es ist ein Begriff, der in der Softwareentwicklung innerhalb eines agilen Rahmens verwendet wird. Die User Story gilt typischerweise als kleinste Einheit im agilen Projekt oder als erster Schritt zur Erfüllung einer Anforderung. Sie werden erstellt, wenn ein Projekt vollständig geplant ist.

Also, was genau bedeutet das? Jedes Softwarefeature hat (oder sollte) einen bestimmten Zweck, wenn es zu einem Projekt hinzugefügt wird. Dieser Zweck sollte seine gesamte Entwicklung und seine Einbettung in den Gesamtrahmen beeinflussen. Entwickler können bei Bedarf auf diesen Zweck verweisen, um Entscheidungen zu treffen, insbesondere darüber, wie Ziele aufgeschlüsselt und welche Prioritäten gesetzt werden sollen. Die „User Story“ ist einfach eine Möglichkeit, den Zweck einer Funktion zu beschreiben.

User Stories werden aus der Perspektive eines Benutzers geschrieben, normalerweise in nur ein oder zwei Sätzen. Sie erfassen den Standpunkt des Benutzers und was dieser Benutzer tun möchte. Nach Abschluss sind gute User Stories eine einfache Möglichkeit, über strategische Ziele zu sprechen, welche Funktionen sicher verworfen werden können oder hinzugefügt werden sollten und vieles mehr.

So schreiben Sie eine User Story

Schritt 1. Eingabe erhalten

Holen Sie sich Input von Eigentümern, potenziellen Benutzern und Projektmanagern. Eine starke User Story braucht viel Input, um akkurat zu sein. Holen Sie sich klare Erklärungen von diesen Gruppen darüber, was sie tun möchten. Denken Sie daran, dass dies nicht direkt in die User Story übersetzt werden sollte, sondern die notwendigen Informationen liefern wird. Ein Eigentümer könnte sagen: „Ich brauche Leute, die mit PayPal in meiner App bezahlen können“, was sehr nützlich ist, aber nicht die User Story selbst.

Schritt 2. Entscheiden Sie, wie User Storys erstellt werden

Dies hängt von Ihrem Arbeitsablauf ab. In der Anfangsphase werden User Stories auf Karteikarten oder Post-its festgehalten, während das Gesamtgerüst geplant wird. Später fließen sie in eine Projektmanagement-Software ein. Einige Teammitglieder überspringen die Post-it-Zettel-Phase, während andere sich darauf verlassen – je nachdem, was für Sie funktioniert.

Schritt 3. Definieren, definieren, definieren

Benutzer definieren: Mit Eingabe können Sie nun den Benutzer definieren. Denken Sie daran, dass dies nicht immer der Endbenutzer von Produktfunktionen ist; Sie kann je nach Benutzertyp variieren. Erstellen Sie bei Bedarf Benutzerpersönlichkeiten. Definieren Sie die Aktion, die der Benutzer ausführt, und definieren Sie das Ziel des Benutzers bei der Durchführung dieser Aktion. Fügen Sie diese Schlüsselinformationen hinzu, wenn Sie Ihre User Story erstellen, um Ihre Zielgruppe anzusprechen.

Schritt 4. Schreiben Sie die Geschichte

Beginnen Sie mit dem Schreiben Ihrer User Story, sie sollte nur ein oder zwei Sätze lang sein, um die Aufmerksamkeit des Lesers zu fesseln. Es ist verlockend, hier präzise und technisch zu sein, aber eine breite Sprache, wie Leitbilder, kann hilfreich sein. Machen Sie die Geschichte klar und stellen Sie sicher, dass sie gelöst oder abgeschlossen werden kann, damit Sie zurückblicken und bestätigen können: „Ja, Benutzer können das jetzt tun!“.

Schritt 5. Teilen Sie sich in weitere Schritte auf

User Stories benötigen möglicherweise mehrere Schritte, um das Endziel zu erreichen, was je nach verwendetem agilen Framework eine gewisse Umstrukturierung erfordern kann. Denken Sie daran, dass die User Story immer die kleinste Einheit im Framework ist. Auf dieser granularen Ebene sollte die Implementierung von User Stories mehrere Tage dauern.

Wenn es so aussieht, als würden sie deutlich länger dauern, ist dies ein Zeichen dafür, dass Sie noch einmal nachsehen und prüfen sollten, ob die Benutzererfahrung weiter aufgeschlüsselt und neu strukturiert werden muss. Wenn neue Anforderungen hinzugefügt werden, müssen diese ebenfalls in User Stories heruntergebrochen werden. Während diese wenigen Sätze den Kern effektiver User Stories bilden, können sie im Laufe der Entwicklung auch erweitert werden. Schauen wir uns das genauer an.

Was sind die 3 Cs in User Stories?

Card : Die Card-Phase bezieht sich auf das Schreiben von User Stories für das Entwicklungsteam in ein oder zwei Sätzen. Es wird Karte genannt, weil User Stories ursprünglich auf Karteikarten geschrieben wurden und viele Teams es immer noch vorziehen, dies so zu tun. Die Karte ist der Kern ihrer spezifischen Softwareanforderungen und der Ausgangspunkt für alle Diskussionen. Auch lässt sich leicht überprüfen, ob Ihre User Story zu lang ist – wenn sie nicht auf eine für alle lesbare Karteikarte passt, muss sie gekürzt werden.

Konversation : Nachdem die Kartensätze erstellt wurden, ist es an der Zeit, die Details auszuarbeiten. Dies beginnt normalerweise mit einer Reihe von Fragen zwischen Entwicklern, z. B. „Wie lange wird die Implementierung dauern?“. oder "Wie können wir diese Aktion integrieren?" oder „Ist diese User Story hier essenziell?“ Usw.

Diese genaue Untersuchung der User Story wird wahrscheinlich zusätzliche Fragen ergeben, die Projektmanagern und Product Ownern gestellt werden können, die bei Bedarf in das Gespräch einbezogen werden sollten. Während die Konversation fortgesetzt wird, können User Stories geändert, verfeinert, zusammengeführt oder entfernt werden, bis alle auf derselben Seite sind. Wenn User Stories fertiggestellt sind, werden sie zur Implementierung verschoben, ein Zeichen dafür, dass die Konversation im Wesentlichen beendet ist.

Bestätigung : Bei der Bestätigung dreht sich alles um Abnahmetests, auch bekannt als Abnahmekriterien. Sobald die Änderung implementiert ist und die Entwickler berichten, dass sie bereit ist – dass die User Story erfüllt wurde – ist es Zeit, sie zu testen.

Akzeptanztests sollten mit dem Input des Product Owners erstellt werden und direkt an die User Story anknüpfen. Im besten Fall ist es ein Benutzer, der einfach versucht, das zu tun, was die User Story anzeigt, und zu sehen, ob er es kann. Akzeptanztests können jedoch variieren und werden nicht immer so durchgeführt, dass User Stories berücksichtigt werden, wie sie sein sollten. Wenn dies ein Problem verursacht, ist es an der Zeit, zum Konversationsschritt zurückzukehren, bis Akzeptanztests und User Stories richtig aufeinander abgestimmt sind. Sind alle Akzeptanztests abgeschlossen, freut sich die User Story. Jetzt ist es an der Zeit, entweder zum nächsten Schritt in der Produktentwicklung überzugehen oder die Funktion freizugeben.

Ein 4. C? : Interessanterweise argumentieren einige, dass es ein wesentliches viertes C: Kontext gibt. In diesem Fall wird die User Story neben den anderen User Storys im größeren Rahmen des Projekts betrachtet. Hier fragen Entwickler, ob die User Story andere User Storys nahtlos ergänzt oder ob es Lücken gibt – Dinge, die der Benutzer tun oder verstehen muss, die zwischen den User Stories übersehen wurden.

Idealerweise wird dies während der Gesprächsphase erkannt, aber das passiert nicht immer. Einige Entwicklungsteams möchten möglicherweise eine abschließende Überprüfung, wie sich die fertige User Story in das größere Ganze einfügt und ob weitere Arbeiten erforderlich sind.

Was ist ein gutes Format für eine User Story?

Lassen Sie uns zwei Formatierungstechniken durchgehen, die beim Erstellen von User-Story-Sätzen sehr hilfreich sind. Die erste ist sehr einfach: „Wer, was und warum?“ In einer Satzvorlage lässt sich das so beschreiben:

Als [wer der Benutzer ist] möchte ich [was der Benutzer will] (damit [warum der Benutzer es will]).

Diese Vorlage kann auch wie folgt formuliert werden: „Als [Rolle] möchte ich [handeln], (damit [Nutzen])“, um die Terminologie zu vereinfachen. Die Befolgung dieses grundlegenden Formats reicht aus, um die meisten User Stories zu erstellen. Es ist in der Regel alles, was Sie brauchen, und kann viel Zeit sparen, wenn es für jede User Story verwendet wird.

Manchmal sind User Storys in komplexeren Projekten jedoch schwieriger zu definieren. In diesem Fall kann eine zweite User-Story-Template-Technik sinnvoll sein. Es heißt INVEST, ein Akronym, das für Folgendes steht:

• Unabhängig : Geschichten sollten völlig unabhängig voneinander sein, und Geschichten sollten daher in der Lage sein, außerhalb der Reihenfolge zu arbeiten.
• Verhandelbar : Geschichten sollten so gestaltet sein, dass sie während des Gesprächsteils des Prozesses geändert werden können.
• Wertvoll : Die User Story sollte einen klaren Wert für das Projekt aufzeigen. Wenn dies nicht möglich ist, kann es eine Verschwendung von Ressourcen sein.
• Schätzbar : Eine User Story muss nach Wert und Priorisierung gemessen werden, um zu entscheiden, woran in der Reihenfolge ihrer Wichtigkeit gearbeitet werden soll.
• Klein : User Stories müssen die kleinste Funktionseinheit sein und sollten ansonsten weiter aufgeschlüsselt werden.
• Testbar : Die User Story muss während des Bestätigungsprozesses testbar formuliert werden.

FAQs zum Schreiben von User Stories

Vielleicht interessiert Sie auch unser Leitfaden zum Schreiben einer Spielbewertung.