Was ist eine User Story?
User Stories sind kurze, einfache Beschreibungen einer Funktion, die aus der Perspektive der Person erzählt werden, die die neue Funktion wünscht, normalerweise eines Benutzers oder Kunden des Systems. Sie folgen normalerweise einer einfachen Vorlage:
Als a möchte ich das so .
User Stories werden häufig auf Karteikarten oder Haftnotizen geschrieben, in einem Schuhkarton aufbewahrt und an Wänden oder Tischen angeordnet, um die Planung und Diskussion zu erleichtern., Daher verlagern sie den Fokus stark vom Schreiben über Funktionen auf deren Diskussion. Tatsächlich sind diese Diskussionen wichtiger als der geschriebene Text.
Können Sie einige User Story Beispiele zeigen?
Einer der Vorteile agiler User Stories ist, dass sie auf unterschiedlichen Detailebenen geschrieben werden können. Wir können eine User Story schreiben, um große Mengen an Funktionalität abzudecken. Diese großen User Stories werden allgemein als Epen bezeichnet. Hier ist ein episches Beispiel für agile User Story aus einem Desktop-Backup-Produkt:
- Als Benutzer kann ich meine gesamte Festplatte sichern.,
Da ein Epos im Allgemeinen zu groß ist, als dass ein agiles Team es in einer Iteration abschließen könnte, wird es in mehrere kleinere User Stories aufgeteilt, bevor es bearbeitet wird. Das obige Beispiel könnte in Dutzende (oder möglicherweise Hunderte) unterteilt werden, einschließlich dieser beiden:
- Als Power User kann ich Dateien oder Ordner angeben, die basierend auf Dateigröße, Erstellungsdatum und Änderungsdatum gesichert werden sollen.
- Als Benutzer kann ich Ordner angeben, die nicht gesichert werden sollen, damit mein Sicherungslaufwerk nicht mit Dingen gefüllt ist, die ich nicht speichern muss.
Wie werden Details zu User Stories hinzugefügt?,
Details können Benutzergeschichten auf zwei Arten hinzugefügt werden:
- Durch Aufteilen einer Benutzergeschichte in mehrere, kleinere Benutzergeschichten.
- Durch hinzufügen von „Bedingungen der Zufriedenheit.“
Wenn eine relativ große Story in mehrere, kleinere agile User Stories aufgeteilt wird, ist es natürlich anzunehmen, dass Details hinzugefügt wurden. Immerhin wurde mehr geschrieben.
Die Bedingungen der Zufriedenheit ist einfach ein High-Level-Akzeptanz-Test, der wahr sein wird, nachdem die agile User Story abgeschlossen ist., Betrachten Sie Folgendes als ein weiteres Beispiel für agile User Story:
Als Vice President of Marketing möchte ich eine Ferienzeit auswählen, die bei der Überprüfung der Leistung vergangener Werbekampagnen verwendet werden soll, damit ich rentable identifizieren kann.
Details können zu diesem User Story-Beispiel hinzugefügt werden, indem die folgenden Bedingungen für die Zufriedenheit hinzugefügt werden:
- Stellen Sie sicher, dass es mit den wichtigsten Feiertagen im Einzelhandel funktioniert: Weihnachten, Ostern, Präsidententag, Muttertag, Vatertag, Tag der Arbeit, Neujahr.
- Unterstützt Feiertage, die sich über zwei Kalenderjahre erstrecken (keine erstrecken sich über drei).,
- Urlaub jahreszeiten können eingestellt werden von einem urlaub zum nächsten (wie Thanksgiving zu Weihnachten).
- Die Ferienzeit kann auf mehrere Tage vor dem Feiertag festgelegt werden.
Wer schreibt user stories?
Jeder kann schreiben von user stories. Es liegt in der Verantwortung des Product Owners, sicherzustellen, dass ein Produkt-Backlog agiler User Stories existiert, aber das bedeutet nicht, dass der Product Owner derjenige ist, der sie schreibt. Im Laufe eines guten agilen Projekts sollten Sie erwarten, dass User Story-Beispiele von jedem Teammitglied geschrieben werden.,
Beachten Sie auch, dass es weitaus weniger wichtig ist, wer eine User Story schreibt als wer an den Diskussionen beteiligt ist.
Wann werden User Stories geschrieben?
User Stories werden im gesamten agilen Projekt geschrieben. In der Regel findet kurz vor Beginn des agilen Projekts ein Story-Writing-Workshop statt. Jeder im Team nimmt mit dem Ziel teil, einen Produkt-Backlog zu erstellen, der die im Laufe des Projekts oder eines drei – bis sechsmonatigen Release-Zyklus hinzuzufügenden Funktionen vollständig beschreibt.
Einige dieser agilen user stories werden zweifellos Epen., Epen werden später in kleinere Geschichten zerlegt, die leichter in eine einzelne Iteration passen. Darüber hinaus können neue Geschichten geschrieben und dem Produkt-Backlog jederzeit und von jedem hinzugefügt werden.
Ersetzen User Stories ein Anforderungsdokument?
Agile Projekte, insbesondere Scrum-Projekte, verwenden einen Produkt-Backlog, bei dem es sich um eine priorisierte Liste der in einem Produkt oder einer Dienstleistung zu entwickelnden Funktionen handelt. Obwohl Produkt – Backlog-Elemente alles sein können, was das Team wünscht, haben sich User Stories als die beste und beliebteste Form von Produkt-Backlog-Elementen herausgestellt.,
Während ein Produkt-Backlog als Ersatz für das Anforderungsdokument eines herkömmlichen Projekts angesehen werden kann, ist es wichtig, sich daran zu erinnern, dass der geschriebene Teil einer agilen User Story („Als Benutzer möchte ich …“) unvollständig ist, bis die Diskussionen über diese Story stattfinden.
Es ist oft am besten, den geschriebenen Teil als Zeiger auf die reale Anforderung zu betrachten. User Stories können auf ein Diagramm verweisen, das einen Workflow darstellt, eine Tabelle, die zeigt, wie eine Berechnung durchgeführt wird, oder ein anderes Artefakt, das der Product Owner oder das Team wünscht.,
Empfohlene Ressourcen im Zusammenhang mit User Stories
- Vorteile der User Story-Vorlage „Als Benutzer möchte ich“.,
- Ein Beispielformat für einen tabellenkalkulationsbasierten Produktrückstand
- Vorteile von User Stories für Anforderungen
- Nicht funktionale Anforderungen als User Stories
- Einführung in User Stories
Leave a Reply