20 Beispiele für Anwenderberichte und bewährte Verfahren

Wie fangen Sie an, eine erfolgreiche App oder Website zu designen, die bei Ihren Benutzern ein Hit wird? User Stories sind in Kombination mit einem Wireframe-Tool Ihr bester Freund!

User Stories helfen uns dabei, unsere user personas in den Kontext des Produkts, das wir designen, einzupassen. Während die Biografie einer user persona ihr Leben und ihre Sorgen beschreibt, beschreibt die User Story, wie sie eine Funktion Ihres Produkts nutzen – in Laiensprache!

In einer agilen Umgebung neigen Product Owner und UX-Designer dazu, User Stories auf Karteikarten zu schreiben, die im Designteam herumgereicht werden und das Gespräch anregen. Vielleicht schreiben wir sie auch digital, mit Office oder Google Docs, um sie in das Scrum Backlog aufzunehmen.

Die Tatsache, dass sie in einfacher Sprache und ohne Fachjargon verfasst sind, bedeutet, dass sich das Design-Team weniger durch technische Details eingeschränkt fühlt. Sie haben mehr Möglichkeiten, ihre Ideen für das Design von Funktionen kreativ zu gestalten. Lesen Sie weiter, um einige großartige Beispiele für Benutzergeschichten zu sehen!

Eine User Story ist eine kurze Beschreibung dessen, was ein Produkt tun muss, für wen es bestimmt ist und warum es gebraucht wird. In der Regel wird sie in ein oder zwei Sätzen geschrieben und folgt einem einfachen Format, damit sie leicht zu verstehen und zu befolgen ist. Eine typische User Story sieht so aus: „Als ein ( user persona), ich möchte (eine Aktion), damit (ein Nutzen/ein Wert).“ Diese Struktur hilft den Teams zu verstehen, was der Benutzer braucht, ohne in technische Details zu verfallen.

Die Arbeit mit User Stories hat nachweislich mehrere Vorteile, weshalb viele agile Teams auf der ganzen Welt sie einsetzen. Hier sind einige der wichtigsten Gründe, warum agile Teams User Stories den Vorzug geben.

Einer der Hauptvorteile von User Stories besteht darin, dass sie ehrgeizige und umfangreiche Produktumfänge in kleinere, leichter zu realisierende Funktionsgruppen aufteilen. User Stories sind einfach eine kurze Beschreibung der Ziele des Benutzers in seinen eigenen Worten. Sie helfen Gruppen dabei, sich nicht in Details und Protokollen, technischen Details und Verfahren zu verlieren.

User Stories sind hervorragend geeignet, um Teams dabei zu helfen, Prioritäten zu setzen, welche Funktionen zuerst erstellt werden sollen. Wenn sie als Backlog-Elemente verwendet werden, erleichtern sie die Organisation und Aufteilung von Aufgaben oder Funktionsanforderungen in Sprints. Dies ist entscheidend für das effiziente Schreiben von User Stories und agile Praktiken.

User Stories geben agilen Teams konkrete Kriterien zum Testen an die Hand. Jede Story sollte ein klares, nachweisbares Ergebnis haben, das sicherstellt, dass die User Story das gewünschte Ergebnis erzielt. Dies hilft den Teams, die Leistung und die Ergebnisse während jedes Sprints effektiver zu messen.

User Stories helfen dabei, den Wert zu ermitteln, den bestimmte Funktionen den Benutzern bieten werden. Agile Teams können sich auf die wichtigsten und unmittelbar benötigten Funktionen konzentrieren, was zu einer effizienteren und profitableren Arbeit für Kunden und Stakeholder führt und auch den Nutzern zugute kommt.

Da in User Stories der Fachjargon fehlt, der in vielen anderen Dokumenten der Produktentwicklung zu finden ist, öffnen sie das Team für kreativere Spekulationen. Dies fördert einen kreativen und flexiblen Dialog zwischen Entwicklungs- und Designteams. Mit User Stories wird der Schwerpunkt von den Funktionen und technischen Details auf die Sichtweise des Benutzers und die potenziellen Einsatzmöglichkeiten des Produkts verlagert. Auch für nicht-technische Interessengruppen, die wissen möchten, an welchen Funktionen gearbeitet wird und in welche Richtung das Projekt geht, ist diese Methode sehr hilfreich.

User Stories können User Personas zum Leben erwecken, indem sie diese fiktiven, aber auf dem echten Leben basierenden Personas in das Projekt einbeziehen. Es ist, als ob Vertreter von Tausenden oder Millionen von Benutzern dem Entwicklungsteam sagen, was sie brauchen, anstatt dass das Team es sich nur vorstellt. User Stories können zu User Story Maps zusammengefasst werden, einer produktiven agilen Technik, bei der alle Stories organisiert werden, um einen Entwicklungszeitplan und eine Prioritätenliste zu erstellen.

Die Art und Weise, wie agile Teams User Stories schreiben, variiert oft zwischen verschiedenen Organisationen und Teams. Um erfolgreich User Stories zu schreiben, sollten Sie immer die folgenden Elemente berücksichtigen, damit Ihr Team ein umfassendes Bild davon erhält, was genau in jeder Phase der Produktentwicklung benötigt wird:

– Benutzer
– Aktion
– Nutzen

Mit diesen drei Elementen können Sie eine kurze User Story über die Funktion(Produktanforderung) schreiben, die Ihre Persona benötigt und warum sie diese benötigt. Normalerweise schreiben wir die User Story mit der folgenden Struktur:

Als ____ Benutzer möchte ich ____, damit ich ____ kann.

Nehmen wir an, Sie möchten eine soziale Fahr-App entwickeln, mit der Fahrer sehen können, wo ihre Freunde sind. Außerdem können sie mit Hilfe ihrer Stimme Updates über Verkehrsbehinderungen, Unfälle oder Wetterbedingungen posten. Sie könnten die obige Struktur wie folgt ausfüllen:

Dann können Sie die so genannten Akzeptanzkriterien einfügen (auf die wir weiter unten näher eingehen werden), die die technischen Spezifikationen auflisten, die erforderlich sind, um sicherzustellen, dass die Bedürfnisse des Benutzers erfüllt werden. Dazu könnten die folgenden Punkte gehören:

• Die App sollte den Sprachbefehl des Benutzers erkennen, um einen neuen Beitrag zu starten
• Die App sollte die Beiträge des Benutzers vorlesen
• Die App sollte den Benutzer auffordern zu bestätigen, dass er veröffentlichen möchte
• Benachrichtigungen sollten an Freunde im Netzwerk gesendet werden

Aber was ist, wenn Sie zum Beispiel mehr als eine User Story schreiben müssen? Schließlich wird Ihre App oder Website mehrere Funktionen haben und Ihre Anwenderberichte werden kurz sein. Wie können Sie diese in Unterfunktionen unterteilen? Die Antwort lautet: indem Sie epische Geschichten schreiben.

Epische Geschichten helfen Ihnen, ein umfassenderes Bild zu zeichnen, indem sie eine komplexe Aktion zusammenfassen, die aus kleineren Aktionen besteht. In diesem Sinne ist die epische User Story wie ein Überblick über eine Produktfunktion. Epic Stories werden genauso geschrieben wie User Stories, nur weniger spezifisch. Hier ist ein Beispiel:

Dieses epische User-Story-Beispiel kann dann in spezifischere User-Story-Beispiele für dieselbe Anwendung unterteilt werden, wie das folgende:

Oder:

Und schließlich sollten Sie Ihre User Stories immer aus der Sicht Ihrer user persona schreiben. Schreiben Sie z.B. keine Story, für die erst eine andere Funktion entwickelt oder designt werden müsste, um sie zu testen.

Wenn Sie das tun, begeben Sie sich auf ein gefährliches Terrain, das in der agilen Welt als „Deadlock“ bezeichnet wird. Das ist so ähnlich wie „Schachmatt“ beim Schach. Das ist der Punkt, an dem Sie nicht mehr weiterkommen. Mark Shead, der Autor von Starting Agile, hat in seinem Video Agile User Stories das folgende Beispiel für eine vage und schlecht geschriebene User Story gegeben:

In diesem Fall müsste die Datenbank bereits vorhanden sein, so dass das Ergebnis der User Story (das Speichern von Informationen) von der Datenbank abhängt.

Viele Teams, die sich bei den User Stories vertan haben, enden oft in dieser Sackgasse oder im Stillstand. Der Kunde bittet sie um ein Update, und sie antworten, dass sie erst die „Einrichtungsarbeiten“ abschließen müssen, um mit der Entwicklung der App beginnen zu können. Aber „Einrichtungsarbeiten“ sollte es idealerweise nie geben. Wenn User Stories nicht von Anfang an funktionieren, dann machen Sie es wahrscheinlich falsch.

Gute Benutzergeschichten können für sich alleine stehen und sich auch gut mit anderen zusammenfügen, um ein Gesamtbild des Produkts zu vermitteln. Manchmal ist eine Idee nicht schlecht, sondern wird nur schlecht präsentiert, wie in dem Beispiel der schlecht geschriebenen User Story oben.

Zuallererst und vor allem, bevor Sie mit dem Schreiben Ihrer User Stories beginnen, ist es wichtig, dass Sie eine entsprechende Nutzerforschung durchführen und Ihre user personas definieren. Und warum? Weil es genau diese user personas sind, auf denen Ihre User Stories basieren werden.

User personas sind der erste Schritt, wenn es darum geht, eine erfolgreiche User Story zu schreiben, denn wenn Sie nicht wissen, wer der Benutzer ist, wie ist es dann möglich, Ihre Story aus der Sicht des Benutzers zu schreiben?

Wenn es um die Technik des Schreibens von Benutzergeschichten geht, gibt es drei grundlegende Anforderungen, die Sie beachten sollten, bevor Sie beginnen. Oder wenn Sie versuchen, die Idee an andere Beteiligte zu verkaufen. Diese sind als die 3 Ks bekannt:

• Karte
• Konversation
• Konfirmation

Der Sinn von User Stories besteht darin, eine einfache Erklärung auf einer Karte zu liefern. Schnell und einfach. Das nächste „C“ ist Conversation – der Sinn von User Stories ist es, kreative Gespräche und die Zusammenarbeit zwischen agilen Teams anzuregen. Das letzte „C“ schließlich ist „Confirmation“ (Bestätigung). Es bezieht sich auf die Akzeptanzkriterien, die wir testen können, sobald wir die Funktion der User Story erstellt haben.

Die INVEST-Methode ist eine hervorragende Faustregel, die Sie beim Schreiben der bestmöglichen User Stories unterstützt. Die INVEST-Methode ist eine Eselsbrücke für die folgenden Best Practices:

Benutzergeschichten sind zwar oft in Epen enthalten, sollten aber auch als eigenständige Texte verständlich sein.

User Stories sollten ein hohes Maß an Flexibilität bieten. Aus diesem Grund sollten sie keine spezifischen technischen Details enthalten. Schließlich liegt Flexibilität in der Natur der Scrum-Umgebung.

Die User Story sollte sowohl für das Team als auch für Ihre user personas von Nutzen sein. Sie sollte Ihrem Team eine klare Vorstellung von den Zielen vermitteln, die eine Funktion erreichen soll, wenn sie designt und entwickelt wird. Und für den Benutzer bedeutet dies ein Produkt, das seine Bedürfnisse konsequent erfüllt.

Es sollte möglich sein, den Arbeitsaufwand für eine in einer User Story vorgeschlagene Funktion zu schätzen. So können Sie der Backlog-Aufgabe die entsprechenden Scrum-Punkte zuweisen und die Zeit effektiv verwalten.

Eine User Story sollte kurz und einprägsam sein. Nur zwei Zeilen darüber, was dieser Benutzer mit einer bestimmten Funktion Ihres Produkts erreichen möchte. Wenn es sich um eine allgemeine Beschreibung Ihrer Anwendung oder einer Kategorie von Funktionen handelt, dann schreiben Sie eine epische Geschichte und unterteilen Sie sie in Teilgeschichten.

Die User Story sollte idealerweise in eine Iteration passen. Außerdem sollten Sie in einer User Story keine Angaben zum UI-Design machen.

Wie bei den meisten Dingen im Entwicklungsprozess sollten Ihre Benutzergeschichten leicht testbar sein und klare ableitbare Metriken für wichtige Leistungsindikatoren enthalten. An dieser Stelle kommen in der Regel die Akzeptanzkriterien ins Spiel.

Der beste Rat, den wir Ihnen geben können, wenn es darum geht, regelmäßig gute User Stories zu schreiben, ist die Verwendung einer Vorlage. Damit stellen Sie sicher, dass Sie und jeder in Ihrem Team, der User Stories schreibt, immer das Wer, das Was und das Warum abdeckt. Dies sind die Details, die Sie benötigen, um sicherzustellen, dass Sie alle notwendigen Informationen in möglichst prägnanter Form erfassen.

Es gibt viele nützliche digitale Vorlagen, die Sie auch ausdrucken oder in Jira oder einem anderen Kanban-System verwenden können. Aber das Tolle ist, dass Vorlagen auch viele andere Felder enthalten können, die nützlich sein können, z.B. Scrum-Punkte und einen Bereich, in den Sie Ihre Akzeptanzkriterien schreiben können.

Die Verwendung einer Vorlage für Epen, die sich aus vielen Untergeschichten zusammensetzt, kann auch eine gute Möglichkeit sein, eine Reihe von Mikro-Features zu organisieren, die sich um ein größeres Makro-Feature drehen.

Candidate Stories sind ein optionaler Schritt, wenn es um das Schreiben von User User Stories geht. Dies sind die Geschichten, die Ihr Team als erstes schreibt, um den Prozess einzuleiten, wenn Sie versuchen herauszufinden, was der Benutzer auf der Grundlage seiner Personas möchte.

Dieser optionale Schritt eignet sich hervorragend für ein Brainstorming mit physischen Karteikarten in einer Besprechung. Candidate Stories müssen nicht einmal der typischen Struktur von echten User Stories folgen. Erfolgreiche Candidate Stories, die Ihr Team erstellt, können dann zu echten User Stories weiterentwickelt werden.

Akzeptanzkriterien sind für User Stories unerlässlich. Sie geben an, was getan werden muss, damit eine Story als vollständig gilt und das Produkt den Anforderungen der Benutzer entspricht.

Der Hauptzweck von Akzeptanzkriterien besteht darin, die Bedingungen zu umreißen, die erfüllt sein müssen, damit eine User Story akzeptiert wird. Sie tragen dazu bei, dass jeder, von den Benutzern bis zu den Entwicklern, versteht, was das fertige Produkt tun soll.

Es gibt einige Möglichkeiten, Akzeptanzkriterien zu schreiben. Eine beliebte Methode ist das Format Gegeben/Wenn/Dann:

• Gegeben eine bestimmte Situation,
• Wenn etwas passiert,
• Dann sollte ein bestimmtes Ergebnis folgen.

Eine weitere einfache Methode ist die Checkliste. Hier listen Sie alle Bedingungen, die erfüllt werden müssen, in Aufzählungspunkten auf. Dieser Ansatz ist klar und einfach zu handhaben.

Schreiben Sie die Annahmekriterien einfach und klar. Machen Sie Ihre Sprache verständlich. Stellen Sie sicher, dass die Anforderungen getestet werden können, um sie zu quantifizieren und zu validieren. Beziehen Sie alle Teammitglieder in den Prozess ein, um ihre Meinungen einzuholen.

Die Aufnahme gut definierter Akzeptanzkriterien in Ihre User Stories verbessert das Schreiben von User Stories. Sie bieten klare Richtlinien für die Entwicklung und das Testen und stellen sicher, dass das Endprodukt den Bedürfnissen der Benutzer entspricht. Dies ist ein wichtiger Teil der agilen User Story-Methode, der dazu beiträgt, dass Projekte auf Kurs bleiben und auf die Ziele der Benutzer ausgerichtet sind.

Eine Möglichkeit, um zu entscheiden, ob eine User Story testbar ist, besteht darin, für jede von Ihnen erstellte User Story Akzeptanzkriterien aufzustellen. Manchmal enthalten die Akzeptanzkriterien eine Liste mit mehreren Variablen, die nach der Entwicklung der Funktion erfüllt sein müssen. Ein Beispiel könnte sein:

Die Akzeptanzkriterien könnten etwa wie folgt lauten:

„Nach der Registrierung sollte dem Benutzer auf dem Anmeldebildschirm die Option angezeigt werden, sich mit seinem Google-Konto anzumelden.“

Manchmal ist es schon beim Lesen der Benutzergeschichte selbst offensichtlich, wie die Akzeptanzkriterien aussehen sollten. Aber egal, wie kurz oder lang sie ist, es ist immer eine gute Praxis, die Abnahmekriterien schriftlich festzuhalten. Dies verhindert, dass Ihr Team in faule Gewohnheiten verfällt und nie welche schreibt. Am besten denken Sie bereits an die Abnahmekriterien, wenn Sie Ihre User Story schreiben.

Wenn Ihnen keine Akzeptanzkriterien einfallen, bedeutet dies, dass die Funktion nicht getestet werden kann. Das bedeutet, dass Sie die betreffende Funktion vielleicht noch einmal überdenken sollten.

Wenn Sie hingegen feststellen, dass die Akzeptanzkriterien zu lang sind, um auf einer Karteikarte Platz zu finden, sollten Sie in Erwägung ziehen, sie in eine andere Benutzergeschichte aufzuteilen, oder vielleicht sollte es stattdessen eine epische Geschichte sein. Das sind alles Dinge, an die Sie denken können, wenn es um das Schreiben von Akzeptanzkriterien geht.

Benutzergeschichten sind wie das Herzstück eines Teamprojekts. Sie leiten das Team dazu an, sich auf das zu konzentrieren, was die Kunden wirklich wollen, indem sie große Ideen in kleine, machbare Schritte verwandeln.

Diese Anwenderberichte werden aus der Perspektive des Anwenders geschrieben. So wird sichergestellt, dass das Team versteht, was der Anwender braucht und warum. So kann sich jeder darauf konzentrieren, ein Produkt zu entwickeln, das seinen Benutzern wirklich dient.

User Stories sind wie Bausteine, die der allgemeinen Aufgabenliste des Teams hinzugefügt werden. Die Person, die das Team leitet, entscheidet dann, welche Geschichten für ihre Kunden am wichtigsten sind und welche zuerst in Angriff genommen werden sollten. Wenn das Team zusammenkommt, um zu planen, wählt es aus dieser Masterliste die Geschichten aus, auf die es sich als nächstes konzentrieren wird.

Jede Story hat eine Reihe von Bedingungen, wie eine Checkliste, die erfüllt sein müssen, bevor die Story als „fertig“ gilt. So wird sichergestellt, dass sich alle einig sind, wie die fertige Arbeit aussieht, und die Messlatte während des gesamten Projekts hoch gehalten.

User Stories bieten einige große Vorteile für agile Projekte. Sie unterteilen große Projekte in kleinere, leichter zu bewältigende Aufgaben und machen es dem Team leichter, organisiert und auf Kurs zu bleiben. Das bedeutet, dass mehr erledigt wird und die Dinge schneller vorangehen.

Sie erleichtern auch die Kommunikation, sowohl innerhalb des Teams als auch mit anderen Projektbeteiligten. Eine einfache Sprache stellt sicher, dass jeder die Projektziele und die zu erledigenden Aufgaben versteht, so dass alle Beteiligten auf dem gleichen Stand sind.

Darüber hinaus fördern User Stories die Zusammenarbeit zwischen den Teammitgliedern. Sie regen Diskussionen darüber an, wie die gewünschten Ergebnisse am effektivsten zu erreichen sind, und bringen innovative Ideen und Lösungen hervor. Dieser kollaborative Ansatz stellt sicher, dass sich das Produkt auf der Grundlage der tatsächlichen Bedürfnisse und des Feedbacks der Benutzer anpasst und weiterentwickelt.

Werfen wir einen Blick auf einige Beispiele für Benutzergeschichten in agilen Projekten und wie sie in der Praxis funktionieren:

• Für eine Website: „Als Besucher möchte ich mich ganz einfach für den Newsletter anmelden, damit ich Updates und Sonderangebote erhalte.“
• Für eine mobile App: „Wenn ich die App benutze und mein Passwort vergesse, möchte ich eine einfache Möglichkeit haben, es zurückzusetzen.“
• Für einen Online Shop: „Wenn ich online einkaufe, möchte ich die Artikel nach dem Preis filtern, damit ich leicht Dinge finden kann, die in mein Budget passen.“

Jedes dieser Beispiele konzentriert sich darauf, was der Benutzer will und welchen Nutzen er aus der Verwendung dieser speziellen Funktion zieht. Auf diese Weise entwickeln Teams Produkte, die die Menschen wirklich nützlich finden und immer wieder verwenden möchten.

Bei der Produktentwicklung ist es entscheidend, die Benutzer zu verstehen. Um diesen Einblick zu erhalten, werden eine Reihe von Tools verwendet. Hier ist wie sie sich unterscheiden und wann Sie sie verwenden sollten.

Benutzerbedürfnisse sind einfache Aussagen darüber, was Benutzer tun möchten oder welche Probleme sie lösen möchten. Diese Ziele bilden die Grundlage für die Entwicklung und Priorisierung von Funktionen.

Wann zu verwenden: Nutzen Sie die Bedürfnisse der Benutzer gleich zu Beginn der Produktentwicklung, um zu definieren, was das Produkt leisten soll.

Benutzertypen sind detaillierte Beschreibungen der verschiedenen Arten von Menschen, die Ihr Produkt verwenden könnten. Sie sind wie Charaktere, die auf Untersuchungen beruhen, und enthalten Informationen wie Alter, Gewohnheiten, Wünsche und Herausforderungen.

Wann zu verwenden: Erstellen Sie Benutzerprofile in einem frühen Stadium des Designprozesses, um Ihre Benutzer besser zu verstehen und das Produkt an ihre speziellen Bedürfnisse anzupassen.

User Stories sind schrittweise Erklärungen, wie ein Benutzertyp mit dem Produkt interagiert, um ein Ziel zu erreichen. Sie zeigen, wie das Produkt verwendet wird und können mögliche Probleme aufzeigen.

Wann zu verwenden: Verwenden Sie User Stories in der Design-Phase, um die Interaktion der Benutzer zu erfassen, Verbesserungsmöglichkeiten zu finden und das Produkt benutzerfreundlicher zu gestalten.

Visuelle Erzählungen sind visuelle Darstellungen von Benutzergeschichten, die oft Bilder und Worte kombinieren, um die Erfahrung des Benutzers deutlich zu machen.

Wann zu verwenden: Verwenden Sie Benutzerbilder bei Designbesprechungen und Präsentationen, um die Kommunikation zu erleichtern, Feedback zu erhalten und das Produkt auf der Grundlage dessen, was die Benutzer sehen und erleben, zu verbessern.

Bedürfnisse der Benutzer: Definieren Sie, was das Produkt leisten soll.

Benutzertypen: Repräsentieren Sie verschiedene Arten von Benutzern und informieren Sie sich über Design-Entscheidungen.

Anwenderberichte: Veranschaulichen Sie, wie Benutzer interagieren und das Produkt einfacher zu benutzen ist.

Benutzerbilder: Verbessern Sie die Kommunikation und visualisieren Sie die Erfahrung des Benutzers.

Wir haben ein paar Beispiele dafür zusammengestellt, wie User Stories im wirklichen Leben aussehen könnten, und zwar sowohl die traditionellen, auf Karteikarten oder Haftnotizen geschriebenen User Story-Beispiele als auch die digitalen User Story-Beispiele, die sich leicht auf einer Online-Plattform teilen lassen.

Einige sind sogar in Form von herunterladbaren Vorlagen wie Word- und Excel-Dateien erhältlich! Lassen Sie uns eintauchen:

Dieser Beispiel-Produktplan für eine Benutzergeschichte hat fünf wichtige Abschnitte. Der erste ist der Titel der Story. Hier können Sie den Namen der Funktion angeben, um die es in der Story geht, z. B. „Buchbesprechungen“.

Im Abschnitt Priorität können Sie eine Priorität von niedrig über mittel bis hoch zuweisen. Es ist wichtig, dass Sie Ihren Backlog-Elementen Prioritäten zuweisen, da einige Funktionen gemäß Ihrer Anforderungsnachvollziehbarkeitsmatrix besonders gefragt sein werden. Neben der Priorität befindet sich der Abschnitt Schätzung. Hier können Sie die Zeit angeben, die das Team Ihrer Meinung nach für die Bereitstellung dieser Funktion benötigen wird. Hier können Sie die entsprechende Anzahl von Scrum-Punkten zuweisen.

Als Nächstes folgt in diesem Beispiel der Abschnitt über die Benutzergeschichte selbst und schließlich die Akzeptanzkriterien. Die Akzeptanzkriterien stehen oft auf der Rückseite der Indexkopie. Da es sich hier jedoch um eine zweidimensionale digitale Kopie handelt, stehen die Akzeptanzkriterien deutlich darunter, sozusagen als Abschluss. Manche finden es besonders hilfreich, alles auf einer Seite zu haben.

Dieses bearbeitbare Word-Dokument ist einfach zu verwenden und enthält klare Anweisungen für jede Klausel und die Akzeptanzkriterien. Unserer Meinung nach sind die Anweisungen, die nach jeder Klausel in der User Story stehen, sowie die Anweisungen für die Akzeptanzkriterien ziemlich einfach zu befolgen.

Warum ist es wichtig, diese Anweisungen in Ihrer User Story-Vorlage zu haben? Wenn Ihr Team eine Weile keine User Stories geschrieben hat oder Sie an vielen Stories arbeiten müssen, ist es gut, diese Art von Anweisungen zu haben, die Ihnen als Anhaltspunkt dienen. Sie dienen als nützliche Erinnerung an die Qualität der Informationen, die in jedem Abschnitt enthalten sein sollten.

Was gibt es Besseres als Excel, um Informationen in Tabellen zu gruppieren? Diese Excel-Vorlage für eine Benutzergeschichte ist auch insofern etwas anders, als sie Ihnen zusätzlich zu den üblichen Feldern die Möglichkeit gibt, weitere wichtige Informationen einzutragen.

Zu den zusätzlichen Feldern, die Sie in diesem User Story-Beispiel finden, gehören der Geschäftswert des Benutzers, die Risikoberechnung, die Kosten der Verzögerung und die gewichtete kürzeste Aufgabe zuerst. Diese zusätzlichen Informationen können je nach Art der Produktfunktionen, an denen Sie arbeiten, oder je nach Art der Kunden oder des Unternehmens, für das Sie tätig sind, ebenfalls nützlich sein.

In diesem Excel-basierten, thematischen Story-Beispiel erhalten Sie eine Spalte für die Prioritätsschätzung, die Akzeptanzkriterien und auch eine Spalte „Freigabe“ für ein Freigabedatum.

Die Spalten in diesem Beispiel einer Benutzergeschichte sind gut geordnet, wobei die Themen vertikal und die Spaltentypen horizontal angeordnet sind. Dies wäre eine großartige Vorlage für eine epische Geschichte, die aus mehreren Untergeschichten besteht.

Apropos Beispiele für epische Benutzergeschichten: Werfen Sie einen Blick auf diese Vorlage für epische Benutzergeschichten. Sie bietet eine hervorragende Möglichkeit, Substories nach ihren epischen Geschichten zu gruppieren.

Jede Epic Story-Funktion wird vertikal aufgelistet, wobei die Spalten für den Benutzer, die Aktion oder den Wunsch und den Nutzen stehen. Die letzte Spalte besteht dann aus einer vertikalen Anordnung von User Stories in Unterzeilen, die in jede Zelle eingepackt sind.

Die Art und Weise, wie diese epische Benutzergeschichte aufgebaut ist, zeigt eine klare Hierarchie zwischen den epischen Geschichten und ihren zahlreichen, detaillierten Benutzergeschichten. Das macht das Scannen sehr einfach und verschafft einen schnellen Überblick über alle Funktionen, die angewendet oder entwickelt werden müssen, um den Benutzer zufrieden zu stellen.

Diese herunterladbare Vorlage für Benutzergeschichten von Powerslides zeigt uns eine weitere elegante Möglichkeit, unsere Benutzergeschichten zu organisieren. Diese Karten können in einer Powerpoint-Präsentation gezeigt oder auch ausgedruckt und verteilt werden.

Uns gefällt auch die klare Aufteilung der wichtigsten Abschnitte: die Benutzergeschichte und die Benutzer-ID, sowie einige Abschnitte, die sich von anderen Beispielen unterscheiden.

Im Abschnitt Story sehen wir die User Story und die Akzeptanzkriterien. Unter dem Abschnitt Benutzer-ID befindet sich jedoch ein Bereich, in dem Sie ein Bild Ihrer user persona anhängen können, zusammen mit einigen Kontrollkästchen für die Art der Funktion, auf die sie sich konzentriert, und Feldern für die Priorität und die Zeiteinschätzung.

Was uns an dieser guten alten Karteikarte User Story gefällt, ist die Einfachheit und die Art und Weise, wie sie die Dinge auf das Wesentliche zurückführt. Manchmal müssen Sie vielleicht schnell eine Geschichte für eine Produktfunktion oder einen schnellen Überblick über Funktionen wie ein Epos verfassen.

Dieses einfache und traditionelle Beispiel einer Benutzergeschichte zeigt uns genau, wie einfach es sein kann. Das Tolle an Karteikarten ist, dass Sie auch die Akzeptanzkriterien auf die Rückseite schreiben können und die User Story-Karte dann im Team herumgereicht werden kann.

Hier haben wir ein traditionelles Beispiel für eine Benutzergeschichte, das zeigt, wie man eine Benutzergeschichte auf eine Karteikarte schreiben könnte. Aus der Story geht klar hervor, was der Benutzer erreichen möchte und warum er es erreichen möchte.

In diesem Fall wollen sie ihre Reservierungen stornieren, um im Falle eines Falles nicht ihr gesamtes Geld zu verlieren.

Auf der Rückseite der Karte sind die Akzeptanzkriterien aufgelistet. Sie zeigt alle Funktionen der App, die erfüllt werden müssen, damit der Nutzen für den Benutzer und die Geschäftsziele zufriedenstellend erfüllt werden können.

Dieses Beispiel einer User Story für eine Banking-App eignet sich hervorragend, um eine benötigte Funktion und die Gründe, warum der Benutzer sie benötigt, kurz und bündig zu erläutern.

Es kommt direkt auf den Punkt, wer der Benutzer ist und was er erreichen muss. Das Tolle an der App ist, dass sie sogar eine der typischen Sorgen des Nutzers einer Banking-App (in diesem Fall des Kreditkarteninhabers) aufgreift, nämlich die Sorge um den ausstehenden Kreditsaldo, um eine gute Kreditwürdigkeit und darum, nicht in die roten Zahlen zu geraten.

Der Benutzer in diesem Beispiel möchte seinen Kontostand bezahlen. Das erste, was das Design-Team also tun könnte, ist, an einer Lösung zu arbeiten, die ihm mehr oder weniger sofortigen Zugriff auf den Kontostand seiner Kreditkarte ermöglicht. Entweder sollte es das erste sein, was er sieht, wenn er die App öffnet, oder es sollte eine klare Option geben, um den Saldo der Karte zu sehen, die nur einen Fingertipp entfernt ist.

Unser nächstes User Story-Beispiel von Whizible ist ebenfalls eine Vorlage, die Sie herunterladen können, um Ihnen und Ihrem Team einen Vorsprung zu verschaffen.

Mit dieser Vorlage können Sie eine Liste mit mehreren User Stories auf derselben Karte schreiben. Die horizontalen Spalten oben zeigen den formelhaften Satz der typischen Benutzergeschichte, d.h. die Leerstellen müssen nur ausgefüllt werden.

Das spart definitiv Zeit, wenn Sie mehrere User Stories schreiben, und hilft Ihnen, direkt auf den Punkt zu kommen. Aus diesem Beispiel für eine Benutzergeschichte können wir zum Beispiel auf einen Blick ersehen, dass der Content Manager die folgende Geschichte hat:

„Als Content Manager möchte ich einen wöchentlichen Bericht über die Analyse der Inhalte erhalten, damit ich die Effektivität des Inhaltsautors überwachen kann.“

Wir haben dieses Beispiel für eine Amazon-Benutzergeschichte ausgewählt, weil es uns einen Einblick in die Art von Geschichten gibt, die in einer agilen Umgebung in einem großen multinationalen Technologieunternehmen erwartet werden. Das Interessante daran ist, dass sie wirklich einfach ist. Es gibt kein technisches Fachchinesisch und jeder, egal aus welcher Disziplin, kann sie verstehen – und genau darum geht es bei User Stories.

In diesem Beispiel ist der Benutzer bei ihnen registriert und möchte einen Kindle für seinen Freund kaufen. Je nachdem, wer die user persona ist, könnte das Team auf diese Geschichte reagieren, indem es einen Geschenkbereich auf dem Startbildschirm einrichtet. Dort könnte etwas stehen wie „Das perfekte Geburtstagsgeschenk“. Sie könnten aber auch eine Nachricht einblenden, die den Nutzer darauf hinweist, dass er sofort Geschenke verschicken kann, während er nach Artikeln wie dem Kindle stöbert.

Eine weitere Maßnahme, die sie vielleicht verfolgen möchten, ist sicherzustellen, dass der Kunde schnell und einfach neue Adressen hinzufügen oder seine aktuelle Adressliste auswählen kann. Wenn Sie Amazon nutzen, werden Sie sehen, dass dies tatsächlich der Fall ist!

In diesem Beispiel erhalten wir einen Eindruck davon, wie die User Stories in einem Backlog in einer agilen Produktentwicklungsumgebung aussehen.

Wie wir hier sehen können, sind die Backlog-Elemente nach Priorität gruppiert und die Aufgaben werden durch User Stories dargestellt. In jeder User Story können wir die verschiedenen Scrum-Punkte notieren, die angeben, wie viel Arbeit für die jeweilige Funktion anfällt.

Uns gefällt dieses einfache Beispiel einer Benutzergeschichte von BBC Sport. Was uns daran gefällt, ist die Tatsache, dass es in nur wenigen Worten eine Menge Informationen vermittelt, was genau das ist, was eine gute Benutzergeschichte tun sollte.

In diesem Beispiel dachte die BBC daran, ihren Sportartikeln eine Schaltfläche zum Teilen hinzuzufügen, damit die Leser sportbezogene Nachrichten mit anderen teilen und auch die Meinung ihrer Freunde einholen können. Es ist vollständig, vermittelt eine Menge Informationen und die Logik ist einfach. Sie rechtfertigt auf jeden Fall die Notwendigkeit einer Share-Schaltfläche und deutet darauf hin, dass jemand vor dem Verfassen dieses Anwenderberichts gründliche Nachforschungen über seine Nutzerbasis angestellt hat.

Dieses Beispiel einer Benutzergeschichte von Easy Agile ist ein wenig anders. Erstens ist uns aufgefallen, dass es bemerkenswert einfach zu lesen ist.

Zu Beginn wechselt jede Zeile zwischen Farbe und Weiß, um die Konzepte leicht zu trennen und das Scannen zu erleichtern. Der linke und rechte Teil der Karte, d.h. die Anweisungen und die Satzformel, sind grün und blau kodiert.

Als nächstes dienen die Anweisungen auf der linken Seite dieses Beispiels für eine Benutzergeschichte als nützliche Aufforderung mit den Kategorien „Wer“, „Was“ und „Warum“. Sie helfen uns, die Geschichte aus dem Blickwinkel des Unternehmens zu betrachten, z. B. „Für wen bauen wir es?“, „Wer ist der Benutzer?“ und „Was ist die Absicht?“ Wenn dieses Beispiel vervielfältigt würde, wäre es unglaublich nützlich und würde als einfache Aufforderung dienen, mit dem Schreiben von User Stories zu beginnen.

Hier sind einige Beispiele für Benutzergeschichten von einer Reise-Website. Wir sehen vier verschiedene Geschichten, die uns einen Einblick in die verschiedenen Funktionen geben, die sie entwickeln könnten, um ihren user personas zu helfen, ihre Ziele zu erreichen.

Ein Problem, das wir sehen, ist jedoch, dass drei der vier Angaben falsch sind. Nun, nicht so sehr falsch, sondern eher unvollständig. Und warum? Weil in den User Stories immer der Grund angegeben werden sollte, „warum“ man eine Aktion durchführen möchte.

Die Funktion sollte immer einen Nutzen für den Benutzer haben. Dies hilft Ihrem Team, denjenigen Funktionen Priorität einzuräumen, die für Ihre Benutzer einen echten Wert und eine Bedeutung haben. Und zufriedene Benutzer bedeuten ein erfolgreiches Produkt und ein glückliches Unternehmen.

Im ersten Beispiel geht es um Hotelreservierungen. Eine bessere, vollständigere Version könnte lauten:

Als Nutzer möchte ich ein Hotelzimmer in der Nähe des Stadtzentrums buchen, damit ich nicht jeden Tag weit fahren muss.

Es ist unwahrscheinlich, dass der Nutzer nicht einen bestimmten Ort für das Hotel im Kopf hat, ob er sich dessen bewusst ist oder nicht. Durch das Hinzufügen des „Warum“-Teils können Sie sich kreativere Lösungen einfallen lassen, die dem Nutzer helfen könnten, wie z.B. die Anzeige von Hotels, die je nach Budget näher am Stadtzentrum oder am Flughafen liegen. Das könnte verhindern, dass der Benutzer die Seite verlassen und die Hoteladressen auf Google Maps suchen muss, um die Entfernungen zu überprüfen. Andernfalls könnte es sich genauso gut um eine beliebige andere Reise-Website handeln, die dem Nutzer keine besonders nützliche Funktion bietet.

Das letzte Beispiel für eine Benutzergeschichte ist jedoch vollständig und nützlich für das Design-Team. Es zeigt genau, was der Benutzer möchte – nämlich vergangene Buchungen speichern und zusätzlichen Aufwand für die Dateneingabe vermeiden. Sie kann auch dabei helfen, bessere und strengere Akzeptanzkriterien zu formulieren.

Agile USA fasst mit dem Beispiel einer User Story für einen Kundenbetreuer auf einem Klebezettel kurz und bündig zusammen, was in diese Art von Arbeit einfließen sollte.

Dies ist ein recht einfaches Beispiel, das zeigt, wie wichtige Informationen für das Design- und Entwicklungsteam auf einem einfachen Klebezettel zusammengefasst werden können. Was uns an dieser Art von Beispielen gefällt, ist, dass sie nicht einschüchternd und für jeden leicht verständlich sind.

So können Sie eine einfache Formel für das Verfassen von Artikeln befolgen. Das ist wichtig, wenn es um Kreativität geht, vor allem, wenn Sie am Tag des Verfassens von Artikeln einen Artikel nach dem anderen verfassen müssen.

Wir haben uns entschlossen, dieses Beispiel für eine Benutzergeschichte von Alexander Cowan aufzunehmen, weil es deutlich zeigt, wie viele Gedanken man sich selbst bei der Erstellung einer einfachen Benutzergeschichte machen muss.

Beim Schreiben von Benutzergeschichten geht es nicht nur darum, sich eine hypothetische Situation mit einem hypothetischen Benutzer auszudenken. Stattdessen sollten die Informationen auf echten Untersuchungen und user personas beruhen. Dieses Beispiel für eine Benutzergeschichte hilft uns, diese Informationen zu nutzen, indem es uns an die Grundlagen erinnert, warum wir diese Geschichte überhaupt schreiben.

Die Eingabeaufforderungen in diesem Beispiel helfen Ihnen dabei, eine Benutzergeschichte zu entwerfen, die die user persona widerspiegelt, in deren Erstellung Sie und Ihr Team Mühe investiert haben. Was uns an diesem Beispiel für die user persona ebenfalls gefällt, ist die Tatsache, dass die Fragen auch zu den Akzeptanzkriterien führen, indem sie fragen: „Wie werden wir wissen, ob es funktioniert?“.

Diese Fitness-App User Story geht es darum, dass Benutzer motiviert bleiben, indem sie ihre täglichen Trainingseinheiten verfolgen. Die Benutzergeschichte ist ganz einfach: „Als Fitness-Enthusiast möchte ich mein tägliches Training verfolgen, damit ich meine Fortschritte überwachen und motiviert bleiben kann.“

Das Ziel ist es, Fitnessliebhabern dabei zu helfen, ihre Fortschritte im Auge zu behalten und motiviert zu bleiben. Die App sollte es den Nutzern ermöglichen, verschiedene Arten von Workouts zu protokollieren und ihnen wöchentliche und monatliche Zusammenfassungen zu geben. Auf diese Weise können die Benutzer sehen, wie sie vorankommen und ihre Motivation hoch halten.

Außerdem sollte es Benachrichtigungen senden, um die Benutzer an ihre Trainingspläne zu erinnern. Diese Benutzergeschichte ist klar, umsetzbar und konzentriert sich auf das Bedürfnis des Benutzers nach Verfolgung und Motivation.

Stellen Sie sich einen junior designer Freiberufler der eine gemütliche Umgebung zum Arbeiten sucht, während er eine Tasse Kaffee genießt. Die Benutzergeschichte beschreibt: „Als freiberuflicher Junior-Designer möchte ich in einer gemütlichen Atmosphäre Kaffee trinken, während ich arbeite, so dass ich eine schnelle Bestellung, einen freien Platz für mich mit dem Laptop und die Möglichkeit, das Gerät aufzuladen, erwarte.“

In dieser Geschichte werden die Bedürfnisse der Freiberufler hervorgehoben und die Bedeutung eines komfortablen Arbeitsbereichs mit schnellem Service, ausreichend Platz für einen Laptop und Zugang zu Lademöglichkeiten betont. Wenn Sie sich auf diese Details konzentrieren, kann das Café eine einladende Atmosphäre schaffen, die Freiberufler und Telearbeiter anzieht.

In dieser User Story geht es um eine Person, die ihren Einkauf optimieren möchte. Lebensmitteleinkauf Erfahrung. Die Anwendergeschichte lautet: „Als jemand, der hart arbeitet, möchte ich meine Lebensmitteleinkäufe ohne Zeitverlust erledigen, damit ich mehr Zeit mit mir selbst verbringen kann.“

Diese Geschichte unterstreicht das Bedürfnis der Nutzer nach einem effizienten und schnellen Lebensmitteleinkauf und betont, wie wichtig es ist, Zeit zu sparen und den Komfort zu erhöhen. Sie konzentriert sich auf ein optimiertes Einkaufserlebnis, das es dem Nutzer ermöglicht, seine Aufgaben effektiv zu erledigen und gleichzeitig mehr Zeit für sich selbst zu haben.

Das richtige Medium für Ihre User Story und die richtigen Informationen, die darin enthalten sein sollten, hängen von Ihrem Unternehmen, der Größe und dem Umfang Ihres Projekts und der Komplexität der Funktionen ab, die Sie designen.

Unabhängig von der Art und Weise, wie Sie Ihre User Story vermitteln, ist das Wichtigste, was Sie beachten müssen, die Recherche. Sobald Sie eine angemessene Nutzerforschung durchgeführt und Ihre Persona-Profile definiert haben, können Sie Ihre User Stories verfassen.

Wenn Sie die in diesem Beitrag genannten Best Practices befolgen und sich von den gezeigten Beispielen und Vorlagen inspirieren lassen (oder diese sogar herunterladen), sollten Sie auf dem besten Weg sein, eine hervorragende User Story zu schreiben.