So schreiben Sie agile User Stories: 7 Richtlinien

Grundsätzlich sind agile User Stories kurze, einfache Werkzeuge, um eine einzelne Aktion oder Absicht zu dokumentieren, die der Zielbenutzer zur Erreichung eines Ziels wünscht. Die einfachsten User Stories haben das Format „Als Benutzertyp oder Rolle möchte ich handeln oder beabsichtigen,  damit Grund oder Nutzen “, das mindestens drei einfache Fragen dazu beantwortet, wer, was und warum sich die Story in der Backlog-Warteschlange befindet.

Wenn Teams ausgereift sind und Unternehmen agil über mehrere Teams und Initiativen hinweg einsetzen, werden agile User Stories häufig viel definierter und strukturierter, um sicherzustellen, dass ein gemeinsames Verständnis der Absichten und der zugrunde liegenden Anforderungen besteht.

Erste Schritte mit dem Schreiben agiler User Stories

Es gibt viele Ressourcen, die neuen Produktbesitzern, Geschäftsanalysten, Scrum-Mastern und technischen Leads helfen, die Grundlagen des Schreibens von User Stories zu verstehen. Einige Startpunkte sind Artikel von Atlassian, FreeCodeCamp, Agile Modeling und diese 200 User Story-Beispiele. Eine der vollständigeren Beschreibungen ist in Alexander Cowans bester agiler User Story. Es gibt Bücher über das Schreiben von Geschichten, darunter User Story Mapping  von Jeff Paton und Peter Economy sowie User Stories  von Mike Cohn. Sie können auch Kurse zum Schreiben von Geschichten von Udemy, Learning Tree, VersionOne und Lynda belegen.

Ein grundlegendes Prinzip, das zuerst von Bill Wake geteilt wird, besteht darin , in gute Geschichten zu investieren . Invest  steht für "unabhängig, verhandelbar, wertvoll, schätzbar, klein und überprüfbar", was eine gute Checkliste für agile Storywriter darstellt. „Ein Leitfaden für agile Führungskräfte zum Schreiben von User Stories“ ist ein Artikel, in dem die Anwendung von Anlagegrundsätzen  erläutert wird .

Die Grundlagen sind relativ einfach, aber ich höre und sehe oft Trennungen zwischen Stakeholdern, Produktbesitzern, Entwicklern und Testern hinsichtlich der Qualität der Anforderungen oder ob eine Story wirklich fertig ist. Es gibt manchmal widersprüchliche Standpunkte in Bezug auf den erforderlichen Detaillierungsgrad, wo technische Anforderungen erfüllt werden müssen und welche Artefakte mit User Stories erstellt werden sollten.

In Anbetracht dieser Fragen finden Sie hier sieben über das Wesentliche hinausgehende Richtlinien zum Schreiben agiler User Stories.

1. Schreiben Sie Geschichten für das Publikum, das sie verwenden wird

Denken Sie vor dem Schreiben von Geschichten daran, dass Geschichten von Personen gelesen und verstanden werden sollen, die am Entwicklungsprozess mit unterschiedlichen Bedürfnissen und Verantwortlichkeiten beteiligt sind. Autoren und Mitwirkende von Geschichten sollten das Publikum im Auge behalten und Geschichten entwerfen, um den kollektiven Bedürfnissen gerecht zu werden:

  • Produktbesitzer sind möglicherweise nicht diejenigen, die die Geschichten schreiben, insbesondere wenn Ihre Organisation diese Funktion an Geschäftsanalysten delegiert oder wenn mehrere Personen am Schreiben von Geschichten beteiligt sind. Produktbesitzer möchten sicherstellen, dass die Story die Bedürfnisse und Absichten der Benutzer vollständig erfasst. Sie sollten die detaillierten Akzeptanzkriterien durchlesen, möchten sich aber nicht unbedingt mit Details zur technischen Implementierung abfinden. Produktbesitzer sollten auch verstehen, wie die Geschichte auf das Gesamtbild ausgerichtet ist, und sich daher aktiv dafür interessieren, wie Epen und Funktionen definiert und wie ihnen Geschichten zugewiesen werden.
  • Die Stakeholder werden die Details der Geschichte nicht lesen, sondern einen Drilldown aus den Epen durchführen und die Zusammenfassung der Geschichte lesen. Wenn Sie viele Stakeholder haben, sollten Sie ein beschreibendes Format für Zusammenfassungen verwenden und die Beschreibung "Als Benutzertyp oder Rolle " an den Anfang der Beschreibung der User Story verschieben.
  • Technische Leads sind oft die erste Person im Team, die Geschichten überprüft. Sie untersuchen die Anforderungen, um festzustellen, ob eine Geschichte zu groß ist und in mehrere Geschichten aufgeteilt werden sollte, oder ob die Geschichte im Voraus technische Arbeit benötigt, um die besten zu ermitteln Lösung.
  • Der Beauftragte ist die Person, die dafür verantwortlich ist, die Details zu überprüfen und bei täglichen Standup-Meetings über den Fortschritt zu berichten. Die Verantwortlichen sollten Storys auf Abhängigkeiten überprüfen, die während des Sprints zu Blöcken werden können.
  • Teammitglieder überprüfen häufig alle Geschichten, um ihre zugewiesenen Geschichten im Kontext anderer Geschichten zu verstehen, die dem Sprint zugewiesen sind.
  • Tester stellen fest, ob Lücken oder Risiken in den Akzeptanzkriterien nicht identifiziert wurden, und überlegen dann, wie sie am besten in automatisierten Test-Frameworks implementiert werden können.
  • Der Analyst des Teams, der möglicherweise Programmmanager oder Mitglied des Projektmanagementbüros ist, möchte, dass die Storys vollständig beschriftet und kategorisiert werden, damit aussagekräftige Kennzahlen aus dem Rückstand entnommen werden können.

2. Beginnen Sie mit dem Benutzer im Auge

Obwohl agile User Stories viele Details erfordern können, ist es sehr wichtig, mit dem Benutzer zu beginnen. Die Geschichte sollte definieren, welche  Aktion oder Absicht der Benutzer ausführen möchte und warum  dies ein Bedürfnis, einen Kernwert oder ein aus der Erfahrung abgeleitetes Ziel anspricht.

Für komplexere Anwendungen ist das Definieren verschiedener Benutzerpersönlichkeiten, die Bedürfnisse, Werte und Verwendungsmuster verschiedener Benutzertypen veranschaulichen, eine wichtige Disziplin und kann das Schreiben von Geschichten verbessern. In „10 Tipps zum Schreiben guter User Stories“ schlägt Roman Pichler vor, dass „die Persona-Ziele Ihnen helfen, die richtigen Storys zu finden. Fragen Sie sich, welche Funktionen das Produkt bieten sollte, um die Ziele der Personas zu erreichen. “ Die Verwendung von Personas zur Stärkung der Benutzerziele bietet eine umfassendere Bedeutung dafür, warum eine Story wichtig ist, und hilft bei der Priorisierung des Rückstands.

3. Beantworten Sie, warum die Geschichte wichtig ist

Das Verstehen, Dokumentieren und Diskutieren von Benutzeranforderungen oder Zielen der Benutzerpersönlichkeit ist nur eine Dimension dafür, warum der Product Owner Storys priorisiert. Die Geschichte sollte auch Mehrwert bieten, etwas , das schwer zu quantifizieren ist , aber sein qualifizierbare  an der Geschichte, Funktion, episch, oder Release - Level.  

Die Beantwortung warum  kann für den Entwickler wichtig sein , wenn sie befugt sind verschiedene Umsetzungsmöglichkeiten vorzuschlagen. Beispielsweise kann eine Funktion, die die Anmeldeerfahrung für Benutzer verbessert, auch dem Unternehmen zugute kommen, wenn die neue Erfahrung auch bessere Kundendaten generiert. Ein Entwickler kann über diesen geschäftlichen Mehrwert nachdenken und die Implementierung für dieses Ziel optimieren, auch wenn die Akzeptanzkriterien der Story nicht spezifisch für diese Anforderung sind.

4. Definieren Sie Akzeptanzkriterien, ohne eine Lösung vorzuschreiben

Die wichtigste Disziplin, auf die man sich beim Schreiben von Geschichten konzentrieren sollte, ist die Erstellung von Akzeptanzkriterien. Hierbei handelt es sich häufig um Listen mit Aufzählungszeichen von kurzen Pass-or-Fail-Anweisungen, die Anforderungen, Einschränkungen, Metriken und Erwartungen dokumentieren. Diese Akzeptanzkriterien werden häufig auf verschiedene Arten verwendet:

  • Technische Leads und Teams verwenden sie, um Story Points basierend auf Komplexität und Aufwand zu schätzen.
  • Entwickler beschränken die Implementierungsoptionen auf diejenigen, die die Akzeptanzkriterien erfüllen.
  • Produktbesitzer können den Umfang oder die Komplexität von Akzeptanzkriterien reduzieren, um Implementierungen mit niedrigeren Schätzungen voranzutreiben.
  • Der Beauftragte kommuniziert Blöcke oder Probleme, die bei Stand-ups schwierige Kriterien erfüllen.
  • Qualitätssicherungsingenieure verwenden Akzeptanzkriterien, um automatisierte Tests zu entwickeln.
  • Der Product Owner überprüft die wichtigsten Kriterien während der agilen Demo, um sicherzustellen, dass die Story fertig ist .

Das Schreiben von Akzeptanzkriterien ist nicht trivial. Akzeptanzkriterien für Akzeptanzkriterien heben einige der Probleme hervor, z. B. das Bereitstellen zu vieler Kriterien, das Definieren zu vager Kriterien oder das Dokumentieren komplexer Kriterien, die nicht einfach überprüft werden können. Einige Autoren verwenden Vorlagen für Akzeptanzkriterien, die eine Struktur für kurze, atomare und überprüfbare Kriterien definieren.

5. Verwenden Sie Geschichten, um zu definieren, was und warum; Definieren Sie Aufgaben zur Implementierung

Einer der kritischen Fehler, den Teams beim Schreiben von Geschichten machen, ist die ausführliche und spezifische Umsetzung. Diese schlecht geschriebenen Geschichten investieren viel Aufwand in die Beschreibung, wie sie häufig implementiert werden müssen, auf Kosten der Beschreibung, was der Benutzer benötigt, warum  er seine Ziele erreicht und wo  er den Geschäftswert steigert.

Es gibt einige Gründe, warum dies passieren könnte.

Unerfahrene Produktbesitzer können Geschichten verwenden, um ihre Implementierungsvisionen zu malen. Mit anderen Worten, sie spezifizieren möglicherweise übermäßig das Benutzerdesign und die funktionalen Implementierungen, anstatt die Benutzererfahrung und die Vorteile des Ziels zu teilen. Einige Produkt Besitzer verwirren ihre Konzeptualisierung, wie etwas Macht  Arbeit (der Prozess , durch den sie kommen , die Anforderungen zu verstehen) mit , wie es sollte  funktionieren, versehentlich eine interne Implementierung Beispiel in eine externe Implementierung Spezifikation drehen.

Andere Produktbesitzer überschreiten möglicherweise ihre Grenzen, indem sie das Team bitten, „mir das aufzubauen“. Dies ist eines meiner 20 schlechten Verhaltensweisen von Produktbesitzern, für die ich Produktbesitzern Empfehlungen zur Zusammenarbeit mit dem Team für Lösungen gebe.

Der andere Grund, warum Storys mit Implementierungsdetails überfüllt sein können, ist, dass einige Teams und technische Leiter diese Detailebene wünschen. Neu gebildete technische Teams, die an der Verbesserung vorhandener Anwendungen arbeiten, möchten möglicherweise diesen Detaillierungsgrad, bis sie die Funktionsweise der Anwendung besser verstehen und die Benutzeranforderungen vollständig verstehen. Einige verteilte Teams, die mit Offshore-Entwicklern oder Freiberuflern zusammenarbeiten, möchten möglicherweise auch die Implementierungsdetails dokumentieren, um sicherzustellen, dass diese Mitglieder ihre Verantwortlichkeiten verstehen.

Für solche Teams ist es am besten, auf Implementierungsdiagramme zu verlinken und zu dokumentieren, wer was und wie als Aufgaben im Zusammenhang mit der Story tut. Die meisten agilen Verwaltungstools ermöglichen Aufgaben oder Unteraufgaben, und diese Detailebene ist normalerweise vom Hauptteil der Geschichte getrennt. Ein Diagramm in diesem Beitrag macht einen guten Job und veranschaulicht dieses wichtige Prinzip, agile Storys zu verwenden, um Benutzererfahrungen und Geschäftsprozesse aufzuschlüsseln, und Aufgaben hinzuzufügen, um die Implementierung für einzelne Arbeiten zu definieren.

6. Kennzeichnen Sie Ihre Geschichten, um Analysen voranzutreiben und Verbesserungen zu üben

Sobald Storys geschrieben, bearbeitet und abgeschlossen sind, versuchen viele Teams, Metriken zu erfassen und Analysen durchzuführen, die die Prozessverbesserung vorantreiben oder Geschäftsfälle für zusätzliche Investitionen erstellen können.

Hier sind einige Beispiele:

  • Beschriften Sie Storys als technische Schulden, um die Größe der Schulden, den Prozentsatz der Geschwindigkeit des Teams, mit der sie angegangen wurden, und die mit jeder Veröffentlichung abgeschlossenen Gesamtschulden zu quantifizieren.
  • Definieren Sie funktionale und technische Spike-Storys, um Experimente und Innovationen voranzutreiben, und berichten Sie dann, wo sich dies auf das Geschäft auswirkt.
  • Wenn Ihr Team agile User Stories schätzt, bitten Sie das Team, Storys am Ende des Sprints zu markieren, um zu signalisieren, ob sie überschätzt oder unterschätzt wurden, um die Genauigkeit der Schätzungen zu verbessern.
  • Verwenden Sie Beschriftungen, Komponenten und benutzerdefinierte Felder, um das Backlog nach historischen Erkenntnissen oder Metriken zu durchsuchen. Wenn Storys mit funktionalen und technischen Komponenten versehen werden, können Sie beispielsweise wissen, welche Storys die APIs beeinflusst haben oder welche Anforderungen zu den letzten funktionalen Verbesserungen in einem bestimmten Bereich der Anwendung geführt haben.
  • Kennzeichnen Sie Storys, in denen vertrauliche Informationen wie personenbezogene Daten (PII), E-Commerce-Transaktionen oder branchenregulierte Daten wie HIPAA-Daten gesammelt oder verarbeitet werden, um Sicherheits- und Compliance-Überprüfungen zu ermöglichen.
  • Geben Sie dem Product Owner und dem Team Feedback. Neben der Kennzeichnung einer abgeschlossenen Geschichte kann ein Produktbesitzer dem Team auch Feedback geben, z. B. die Anerkennung einer großartigen Arbeit . Ebenso kann das Team dem Product Owner Feedback zur Gesamtqualität und Interpretierbarkeit einer User Story geben.

7. Definieren Sie agile Story-Vorlagen und Style-Guides

Größere Organisationen, die mit mehreren agilen Teams und Produktbesitzern zusammenarbeiten, möchten möglicherweise Standards und Stilrichtlinien für das Schreiben von Geschichten erstellen. Die Konsistenz hilft neuen Produktbesitzern, die Schreibfähigkeiten schneller zu erlernen, und verbessert auch die Effizienz der Teammitglieder beim Konsumieren der Informationen.

Ein weiterer Grund für das Entwerfen von Story-Vorlagen besteht darin, dass sich verschiedene Arten von Produkten und Anwendungen für unterschiedliche User Story-Ausdrücke und -Artefakte eignen. Einige Beispiele:

  • Für Geschäftsprozessgeschichten sind möglicherweise Links zu Workflowdiagrammen erforderlich, und es werden Rollen und Berechtigungen angegeben.
  • Kundenbezogene Anwendungsberichte sollten Links zu Wireframes enthalten und Leistungskriterien enthalten.
  • API-Storys sollten erwartete Nutzungsmuster und Metriken dokumentieren.
  • Business Intelligence- und Datenvisualisierungsberichte sollten Richtlinien dazu enthalten, welche Felder und Informationen für die angeforderte Analyse benötigt werden.

Vorlagen helfen dabei, die Kommunikation zwischen Teams und Produktbesitzern darüber zu überbrücken, worauf Sie sich beim Schreiben agiler Geschichten konzentrieren sollten.

Und ist das nicht der Sinn agiler Geschichten? Mit agilen Praktiken, Richtlinien und Prinzipien zum Schreiben von Geschichten können Teams erkennen, was für Benutzer und Unternehmen wichtig ist, bevor sie über die Implementierung nachdenken.