So schreiben Sie User Stories: Eine vollständige Anleitung

User Stories sind ein wesentlicher Bestandteil einer ordnungsgemäßen agilen Softwareentwicklung: Schauen wir uns ihre Rolle an und lernen, wie man User Stories schreibt.

Agile Frameworks sind eine beliebte und effektive Möglichkeit, 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 – bedeutet aber auch, dass sie sorgfältig konstruiert werden müssen. Folgendes sollten Sie wissen:

Was ist eine User Story?

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

Was genau bedeutet das also? Jede Softwarefunktion hat (oder sollte) einen bestimmten Zweck, wenn sie einem Projekt hinzugefügt wird. Dieser Zweck sollte die gesamte Entwicklung und die Art und Weise beeinflussen, wie er in das Gesamtgerüst integriert wird. Entwickler können sich bei Bedarf jederzeit auf diesen Zweck beziehen, 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 seine Absichten. Wenn sie fertig sind, sind gute User Stories eine einfache Möglichkeit, über strategische Ziele zu sprechen, welche Funktionen getrost verworfen werden können oder hinzugefügt werden sollten und vieles mehr. Sie fragen sich vielleicht: Warum eine User Story schreiben?

So schreiben Sie eine User Story

Schritt 1. Holen Sie sich Input

Erhalten Sie Input von Eigentümern, potenziellen Benutzern und Projektmanagern. Eine starke User Story erfordert viel Input, um korrekt zu sein. Erhalten Sie von diesen Gruppen klare Erklärungen 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 möchte, dass die Leute in meiner App mit PayPal bezahlen können“, was sehr nützlich ist, aber nicht die User Story selbst.

Schritt 2. Entscheiden Sie, wie User Stories erstellt werden

Dies hängt von Ihrem Arbeitsablauf ab. In der Anfangsphase werden bei der Planung des Gesamtrahmens User Stories auf Karteikarten oder Post-its festgehalten. Später werden sie in Projektmanagementsoftware integriert. Einige Teammitglieder überspringen die Post-it-Notizphase, während andere sich darauf verlassen – je nachdem, was für Sie funktioniert. Vielleicht fragen Sie sich auch, wie man ein Vorwort schreibt.

Schritt 3. Definieren, definieren, definieren

Definieren Sie den Benutzer: Mit der Eingabe können Sie nun den Benutzer definieren. Bedenken Sie, dass dies nicht immer der Endbenutzer der Produktfunktionen ist. sie kann je nach Benutzertyp variieren. Erstellen Sie bei Bedarf Benutzer-Personas. Definieren Sie die Aktion, die der Benutzer ausführt, und definieren Sie das Ziel des Benutzers, diese Aktion auszuführen. Beziehen Sie diese Schlüsselinformationen in die Erstellung Ihrer User Story ein, 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 etwa 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. In weitere Schritte unterteilen

User Stories benötigen möglicherweise mehrere Schritte, um das Endziel zu erreichen, was je nach dem von Ihnen verwendeten 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 das ein Zeichen dafür, noch einmal darüber nachzudenken, ob die Benutzererfahrung weiter aufgeschlüsselt und neu strukturiert werden muss. Wenn neue Anforderungen hinzukommen, müssen diese auch in User Stories zerlegt 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. Vielleicht möchten Sie auch lernen, was UX-Schreiben ist.

Was sind die 3 Cs in User Stories?

Karte : In der Kartenphase geht es darum, User Stories für das Entwicklungsteam in ein oder zwei Sätzen zu schreiben. Man nennt es Karte, weil User Stories ursprünglich auf Karteikarten geschrieben wurden und viele Teams es immer noch bevorzugen, dies auf diese Weise zu tun. Die Karte ist der Kern ihrer spezifischen Softwareanforderung und Ausgangspunkt aller Diskussionen. Sie können auch leicht überprüfen, ob Ihre User Story zu lang ist – wenn sie nicht auf eine Karteikarte passt, die jeder lesen kann, muss sie gekürzt werden.

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

Diese genaue Untersuchung der User Story wird wahrscheinlich zusätzliche Fragen an Projektmanager und Produktbesitzer ergeben, die bei Bedarf in das Gespräch einbezogen werden sollten. Im weiteren Verlauf der Konversation können User Stories geändert, verfeinert, zusammengeführt oder entfernt werden, bis alle auf derselben Seite sind. Sobald die User Stories fertiggestellt sind, werden sie in die Implementierung überführt, ein Zeichen dafür, dass die Konversation im Wesentlichen beendet ist.

Bestätigung : Bei der Bestätigung geht es um Akzeptanztests, auch Akzeptanzkriterien genannt. Sobald die Änderung implementiert wurde und die Entwickler melden, dass sie fertig ist – dass die User Story erfüllt wurde – ist es Zeit, sie zu testen.

Akzeptanztests sollten mit den Eingaben des Product Owners erstellt werden und direkt mit der User Story verknüpft sein. Im besten Fall handelt es sich um einen Benutzer, der einfach versucht, das zu tun, was in der User Story angegeben ist, und zu prüfen, ob er es kann. Aber Akzeptanztests können variieren und werden nicht immer unter Berücksichtigung von User Stories durchgeführt, wie es sein sollte. Wenn dadurch ein Problem entsteht, ist es an der Zeit, zum Schritt „Konversation“ zurückzukehren, bis Akzeptanztests und User Stories richtig aufeinander abgestimmt sind. Sind alle Abnahmetests abgeschlossen, ist die User Story begeistert. Jetzt ist es an der Zeit, entweder mit dem nächsten Schritt in der Produktentwicklung fortzufahren oder die Funktion zu veröffentlichen.

Ein 4. Jh.? : Interessanterweise argumentieren einige, dass es einen wesentlichen 4. C: -Kontext gibt. In diesem Fall wird die User Story zusammen mit den anderen User Stories im größeren Rahmen des Projekts betrachtet. Hier fragen Entwickler, ob die User Story sich reibungslos mit anderen User Stories 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 bemerkt, aber das passiert nicht immer. Einige Entwicklungsteams möchten möglicherweise eine abschließende Überprüfung, wie die fertige User Story in das größere Ganze passt und ob weitere Arbeiten erforderlich sind.

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

Sehen wir uns zwei Formatierungstechniken an, die beim Erstellen von User Story-Sätzen sehr hilfreich sind. Die erste ist ganz 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] (also [Warum der Benutzer es will]).

Diese Vorlage kann zur Vereinfachung der Terminologie auch wie folgt formuliert werden: „Als [Rolle] möchte ich [handeln], (damit [ein Nutzen] entsteht).“ Die Befolgung dieses Grundformats reicht aus, um die meisten User Stories zu erstellen. Es ist normalerweise alles, was Sie brauchen, und kann bei der Verwendung für jede User Story viel Zeit sparen.

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

• Unabhängig : Geschichten sollten völlig unabhängig voneinander sein und daher sollte es möglich sein, Geschichten außerhalb der Reihenfolge zu bearbeiten.
• 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, handelt es sich möglicherweise um eine Verschwendung von Ressourcen.
• Schätzbar : Eine User Story muss anhand ihres Werts und ihrer 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 unterteilt werden.
• Testbar : Die User Story muss während des Bestätigungsprozesses auf testbare Weise angegeben werden.

FAQs zum Schreiben von User Stories

Vielleicht interessiert Sie auch unser Leitfaden zum Verfassen einer Spielrezension.