Eine Anleitung Zum Schreiben Effektive User Stories

Wie schreibt man effektive user stories?

Es gibt 5 Leitprinzipien, die ich empfehle:

1. Jeder sollte glücklich sein
   Es ist wichtig, dass alle an Bord sind, also holen Sie sich alle, die Ihre User Stories schreiben und verwenden, um ihre Ideen einzugeben und sich auf das Format zu einigen, das Sie alle verwenden werden.
2. Be consistent
   Sobald Sie eine vereinbarte Struktur haben, stellen Sie sicher, dass Sie sich daran halten.
3. Konzentrieren Sie sich auf das, was wichtig ist
   Wenn Sie sie schreiben, vermeiden Sie unwichtige Details., Nehmen Sie sich Zeit, um sie prägnant zu machen, entfernen Sie jede Waffel, wie es nur in der Quere kommt.
4. Keine Implementierungsdetails
   Konzentrieren Sie sich immer auf das „Warum“, nicht auf das „Wie“. Warum will ein Benutzer etwas, nicht wie werden wir es bauen. Wenn Sie technische Details angeben müssen, sollten diese als separate Spezifikationsdatei angehängt werden.
5. Klar, machbar & testbar
   Stellen Sie sicher, dass jeder jede Geschichte verstehen kann und dass sie in dem Zeitrahmen erreichbar ist, mit dem Sie zufrieden sind. Wenn Sie in 2 Wochen Sprints liefern, sollte es nicht länger als diese 2 Wochen dauern.,

User story anatomy

Es gibt 3 obligatorische Teile für eine User Story, den Titel, die Beschreibung und die Akzeptanzkriterien. Ihr Team kann zustimmen, dass eine User Story über andere Felder verfügen muss, bevor mit der Arbeit begonnen werden kann. Zum Beispiel benötigen Sie möglicherweise einen Beauftragten, Story Points oder die geschäftlichen Auswirkungen, aber ich halte diese für optional, da nicht jede Organisation diese benötigt.

Titel
Titel sollten kurz, eindeutig und nicht irreführend sein.,

Einige gute Beispiele:

• „Kontakt — Panel zur Startseite hinzufügen“
• „Debitkartenunterstützung zum Warenkorb hinzufügen“
• „E – Mail — Vorlagen-Tagging aktualisieren“

Einige weniger gute (leider reale) Beispiele:

• „Vereinbarte Änderungen vornehmen“
• „32072-Aktualisiertes Mapping-Upsell User story (27263)“
• „Links-tracking query string for bill trigger and smart post install …“

Description

Die Beschreibung enthält die tatsächliche Leistung der User Story. Es sollte Empathie im Team für den Benutzer und ein Verständnis des zu lösenden Problems schaffen.,

Eine sehr beliebte Struktur für die Beschreibung erfolgt in der form „Als … möchte ich … damit ich …“.

Diese Struktur stellt die Frage nach „als Wer“? Wer steht der Benutzer vor dem Problem? Sie können hier auf eine Person verweisen, wenn Sie sie verwenden, oder dem Benutzer einen Namen geben und der Situation des Benutzers einen Kontext hinzufügen. Vermeiden Sie die Verwendung von „Als Kunde“ oder „Als Benutzer“, da dies weniger effektiv ist, um Empathie für einen tatsächlichen Benutzer zu erzeugen.

Die Beschreibung sollte in einfacher, klarer Sprache ohne Fachbegriffe oder Abkürzungen verfasst sein., Sie sollten sich fragen: „Kann Ihr Kind es verstehen?“Ein neues Teammitglied sollte in der Lage sein, die Beschreibung zu lesen und genau zu verstehen, was das Problem ist, das gelöst werden muss.

Die folgenden realen Beispiele stammen aus einem Projekt zum Hinzufügen von Funktionen zu einem Online-Kontosystem für Kunden eines britischen Energieunternehmens.,

Einige gute Beispiele:

• “ Als John, ein Kunde mit einem traditionellen Stromzähler, möchte ich verstehen, warum ich Diagramme meines Energieverbrauchs nicht detaillierter als Monat für Monat sehen kann, damit ich entscheiden kann, ob ich dies ändern und einen Smart Meter installieren möchte.“
• “ Als Bart, ein proaktiver traditioneller Zählerkunde, der sicherstellen möchte, dass meine nächste Rechnung genau ist, möchte ich wissen, ob heute bereits ein Zählerstand eingereicht wurde und dass ich keinen weiteren einreichen muss.,“

Einige weniger gute Beispiele:

• „Als Benutzer möchte ich verhindern, dass trad-Kunden einen Drilldown unter das höchste Niveau durchführen können, damit ihre Kundenerfahrung verwaltet wird“
• „Als Kunde, der entweder heute einen Zählerstand angegeben hat oder heute einen geschätzten Kraftstoffwert angegeben hat, sollte es mir nicht gestattet sein, heute einen weiteren Messwert einzureichen, da SAP nicht mehr als einen Messwert pro Kraftstoff und Tag akzeptieren kann.“

Das weniger gute Beispiele sind tatsächlich umgeschrieben, um die guten Beispiele von oben, wie die Probleme, die Sie beschrieben wurden nicht klar., Dieser Verfeinerungsprozess sollte jederzeit durchgeführt werden, wenn ein Teil einer User Story nicht klar ist. Stellen Sie einfach sicher, dass jeder im Team sich der Änderungen bewusst ist und diesen zustimmt.

Akzeptanzkriterien

Akzeptanzkriterien werden verwendet, um die Vollständigkeit der User Story nachzuweisen. Dies ist hilfreich für Entwickler und Tester.

Das Schreiben der Akzeptanzkriterien ist eine effektive Möglichkeit, alle Details der Geschichte durchzugehen, bevor Sie mit der Arbeit beginnen. Viele potenzielle Fallstricke oder unerwartete Arbeiten können frühzeitig durch das Schreiben guter Akzeptanzkriterien „entdeckt“ werden.,

Eine sehr beliebte Struktur für die Akzeptanzkriterien hat die Form von “ Gegeben… wenn… dann…“, wie in den folgenden Beispielen zu sehen.

Wenn eine User Story mehr als 10 Akzeptanzkriterien hat, kann dies ein Hinweis darauf sein, dass die Story zu viele Dinge tut. In diesem Fall empfehle ich, die Geschichte aufzuteilen.

Das gesamte Team sollte an der Erstellung der Akzeptanzkriterien beteiligt sein. Wenn dies nicht möglich ist, empfehle ich allen, sie zu lesen und ihnen zuzustimmen, bevor Sie daran arbeiten. Dies gilt insbesondere für alle, die an der Erprobung der Arbeit beteiligt sind.,

Die Nummerierung der Akzeptanzkriterien macht es einfach, sie zu referenzieren.

Einige gute Beispiele:

1. Bei einem Kunden mit einem herkömmlichen Zähler im Balkendiagramm für den Energieverbrauch
   Wenn Sie einen Monat lang auf den Tooltip klicken
   Dann wird ein Popup angezeigt, das dem angegebenen Design entspricht.
2. Wenn ein Dual-Fuel-Kunde das Balkendiagramm für den Energieverbrauch anzeigt
   Wenn er Monate mit geschätzten Werten hat
   Dann sollte die Diagrammlegende deutlich ein geschätztes Stromsymbol mit einem hellroten Balken anzeigen
   Dann sollte die Diagrammlegende deutlich ein geschätztes Gassymbol mit einem hellblauen Balken anzeigen.,

Wenn wir keine User Stories benötigen

Technische Aufgaben

Manchmal scheint sich eine technische Aufgabe nicht auf einen Kunden zu beziehen. Wenn dies der Fall ist, verwenden Sie keine User Story. Es lohnt sich jedoch immer zu überlegen, warum Sie eine technische Aufgabe ausführen. Aktualisieren Sie eine Bibliothek, um die Geschwindigkeit für Benutzer zu verbessern? Wenn ja, sollte das eine User Story sein.

Bugs

Wenn während des Testens einer User Story, an der gerade gearbeitet wird, ein Fehler gefunden wird, sollte dieser User Story zugeordnet werden.,

Wenn ein Fehler für etwas gefunden wird, das keine aktuelle Benutzerstory ist, sollte es nicht mit einer User Story verknüpft, sondern als eigenständige Aufgabe zum Backlog hinzugefügt werden.

Kontinuierliche Verbesserung

User Stories werden sich weiterentwickeln, wenn mehr über die zu erledigende Arbeit gelernt wird. Das ist gut, verbessern Sie sie weiter bis zu dem Punkt, an dem Sie die Arbeit für die Benutzer freigeben., Stellen Sie einfach sicher, dass alle in Ihrem Team sich dessen bewusst sind und den vorgenommenen Änderungen zustimmen.

Verfeinern Sie den Prozess weiter. Seien Sie agil, überlegen Sie, wie Ihre User Stories für Ihr Team arbeiten, diskutieren Sie sie im Nachhinein und verbessern Sie die Art und Weise, wie Sie sie schreiben.