Durch die Untersuchung und Analyse von über 10.000 User Stories aus verschiedenen Quellen haben wir einen Einblick in das gewonnen, was eine gute User Story ausmacht. Wenn du gerne möchtest Lernen Sie, bessere User Stories zu schreiben, sollten Sie diesen Artikel nützlich finden.
Was ist eine User Story?
Bevor wir mit den 10 Schritten beginnen, werfen wir noch einmal einen Blick auf die Frage, was eine User Story ist. Eine User Story wird typischerweise als Platzhalter für eine Konversation über ein Benutzerbedürfnis beschrieben. Normalerweise beziehen wir uns auf die drei C's: Karte, Gespräch Und Zusammenarbeit. In vielen Organisationen SIND die User Stories jedoch die Liste der Anforderungen.
Agile-Puristen und Coaches werden typischerweise sagen, dass die User Story nicht als Ersatz für schriftliche Anforderungen betrachtet werden sollte, da dies die Förderung der Zusammenarbeit zwischen Teammitgliedern untergräbt. Allerdings in den meisten Fällen In den meisten Organisationen ist die Liste der User Stories die Liste der Anforderungen.
Lassen Sie uns nun 10 Schritte zum Schreiben besserer User Stories behandeln:
1. Konzentrieren Sie sich auf funktionale Bedürfnisse
Die Funktionalität sollte nach Möglichkeit wie folgt geschrieben werden: Als __ muss ich __ . Integrieren Sie in jede Story alle Funktionen, die sie vervollständigen. Beziehen Sie Datenbewegungen zwischen Systemen ein (vorausgesetzt, Ihr Aufgabenbereich besteht darin, solche Funktionen hinzuzufügen, zu bearbeiten oder zu löschen). Eine User Story, die mit „Wann“ statt mit „Als“ beginnt, ist in Ordnung, solange sie ein funktionales Ereignis beschreibt, einschließlich eines Benutzers, eines Objekts und einer Aktion. Beispiel: „Wenn der Temperatursensor 100 Grad erkennt, sendet er ein Signal, um die Wärmequelle zu deaktivieren.“
Schließen Sie Teamaufgaben und jegliche Konfigurationsarbeiten aus, die nicht direkt mit der Bereitstellung neuer, geänderter oder gelöschter Funktionen zusammenhängen.
2. Klar und eindeutig
Wenn eine User Story unklar ist, führt dies zu Fehlern. Es ist absolut wichtig, dies frühzeitig zu klären und zu lösen. Es sollte für die beabsichtigte Leserschaft (zumindest: Benutzer, Entwickler, Tester, Analyst, Designer) eindeutig sein. Der einfache Test auf Mehrdeutigkeit besteht darin, sicherzustellen, dass zwei beliebige Leser desselben Textes zum gleichen Verständnis darüber gelangen, welche Funktionalität bereitgestellt werden muss – fragen Sie sie im Zweifelsfall.
Verwenden Sie datenbezogene Verben wie z aktualisieren, schicken oder speichern. Vermeiden Sie Verben wie: überlegen, bereitstellen, wollen, entscheiden, unterstützen Und bewerten . Diese führen den Leser wahrscheinlich in die Irre.
3. Wertvoll und rückverfolgbar bis hin zu Geschäftsergebnissen
Dies ist in vielerlei Hinsicht das wichtigste Merkmal einer User Story. Wenn die Geschichte für das Unternehmen keinen Nutzen hat, sollte sie ausgeschlossen werden. Im Idealfall kann der Wert der Geschichte direkt angesprochen werden Fähigkeiten Und Ergebnisse die messbar sind. Das heißt, es besteht eine klare Rückverfolgbarkeit zwischen der Funktionalität der User Story und der Fähigkeit, die zum Erreichen des messbaren Geschäfts erforderlich ist Ergebnis.
4. Aus der Sicht des Benutzers
Konzentrieren Sie sich auf die Erfahrung des jeweiligen Benutzers der Anwendung. Versuchen Sie auch, den Typ und Kontext des Benutzers genau anzugeben. Versuchen Sie beispielsweise, anstelle von „als Benutzer“ einen Kontext in Ihren Benutzernamen anzugeben, zum Beispiel: angemeldeter_Kunde, angemeldeter_Marketing-Agent. angemeldeter_Administrator. Dies ist informativ über den Kontext, ohne wortreich zu sein.
5. Prägnant
Zu ausführliche User Stories, die zu viele Details zu Funktionsanforderungen, Designaussagen und Testkriterien enthalten, führen zu Verwirrung. Behalte deine Geschichten kurz, einfach und präzise. Es ist besser, sich kurz und klar zu fassen, als zu viel zu spezifizieren.
Versuchen Sie, Ihre User Stories klein und einfach, aber dennoch umfassend genug zu halten, um eine Wucherung der Storys zu vermeiden. Zwei spezifische Tipps bestehen darin, sich auf Objekte zu beziehen, nicht auf Objekttypen (zu groß) oder Objektattribute (zu detailliert). Zum Beispiel "Als eingeloggter_Kunde kann ich mein Profil aktualisieren“ ist besser als "Als eingeloggter_Kunde kann ich alle Daten aktualisieren“ oder „Als eingeloggter_Kunde kann ich meine Telefonnummer aktualisieren“
6. Konsequent
Bleiben Sie im Einklang mit Ihrem Benutzernamen Und Objektnamen.
Achten Sie darauf, dass die im System verwalteten Daten mit den von Ihnen verwendeten Namen konsistent sind. Versuchen Sie, sich so weit wie möglich nur auf Objekte und Objekttypen zu beziehen, und vermeiden Sie Objektattribute innerhalb von Storys. z.B Benutzerprofil (das ein Attribut für das Geburtsdatum enthält) ist besser als Geburtsdatum.
7. In sich selbst vollständig
Wenn eine User Story mehrere Funktionsschritte erfordert, schließen Sie diese alle ein. z.B
Vor: Als Benutzer möchte ich die Store-Details aktualisieren.
Nach: Als eingeloggter_in_Administrator muss ich meine Berechtigung [zum Aktualisieren des Store_Record] überprüfen. Ich kann dann den Store_Record aktualisieren
Die beiden funktionalen Anweisungen weisen darauf hin, dass Berechtigungen überprüft werden müssen, bevor ein Update durchgeführt werden kann.
8. CRUD Vollständig und nicht dupliziert über einen Satz hinweg
Wenn wir aktualisieren Information speichern Gibt es im obigen Beispiel auch eine ähnliche User Story, die es uns ermöglicht, einen Shop zu erstellen? Eine andere Geschichte zum Löschen eines Shops? Und noch eine Geschichte, um einen Laden zu präsentieren? Fehlende Storys sind die Ursache für Scope Creep, was oft dazu führt, dass Projekte über ihren ursprünglichen Zeitplan hinausgehen.
Achten Sie auch auf doppelte User Stories. Doppelte Anforderungen kommen seltener vor, kommen aber dennoch vor. Stellen Sie daher sicher, dass Sie die Funktionalität nicht verdoppelt haben.
9. Testbar
Wenn ein Leser nicht ohne weiteres verstehen kann, wie die User Story getestet werden soll, ist sie nicht testbar. Wir beziehen uns hier auf das Testen aus funktionaler Sicht. Alle Einschränkungen sollten einbezogen werden und alle skalaren Einschränkungen sollten quantifiziert werden.
10. Enthält kein Design
User Stories sollten keine Designaussagen enthalten.
Abschluss
Dies sind 10 meiner Lieblingstipps zum Schreiben besserer User Stories. Das garantiere ich, wenn Sie diese Tipps befolgen Sie werden bessere User Stories schreiben, und das wird zum Schreiben führen bessere Software.
Was ist, wenn meine User Stories nicht gut sind? Spielt es eine Rolle, solange ich den Kern der Geschichte verstehe? Ja tut es. Nur eine Unklarheit führt zu Zeit- und Arbeitsverschwendung bei der Interpretation, zu Fehlinterpretationen und zu einem gewissen Grad an Nacharbeit. Eine Unterlassung könnte eine umfassende Überarbeitung des Designs erforderlich machen (oder zu technischen Schulden führen, wenn es zu spät ist, das Design zu ändern). Beim Schreiben von User Stories oder Anforderungen ist also große Sorgfalt geboten. Gute Anforderungen können zu einer pünktlichen Lieferung führen. Schlechte Anforderungen werden sicherlich mehr kosten und länger dauern.
Brauche mehr
Schauen Sie sich dieses hervorragend gearbeitete Beispiel an Verbesserung einer User Story.
