Erweiterte User Stories

Das im Beitrag klassische User Stories beschriebene Vorgehen weist  Mängel aus Sicht eines "agiles Anforderungsmanagements" auf. Streng genommen fehlen bei diesem Vorgehen reproduzierbare Anforderungen, mit Ausnahme flüchtiger mündlicher Vereinbarungen und einer unsortierten Liste von Überschriften. Sie verletzen sowohl die Vorgaben moderner Scrum Guides als auch die gesammelten Vorgaben aus dem Beitrag "agiles Anforderungsmanagement".

Vorgabe: Die in der Folge empfohlenen Erweiterungen müssen vom Entwicklungs-Team in Abstimmung mit dem Product-Owner ausgewählt und eingesetzt werden. Das Team entscheidet darüber, welche zusätzlichen Maßnahmen zur Dokumentation von strukturierten Anforderungen im aktuellen Sprint angemessen sind, und erweitert bei Bedarf die "Definition of Done" für Stories, die bereit zur Umsetzung sind. Der/Die Product-Owner ist in diese Entscheidung einzubinden, da er/sie für den Inhalt des Product-Backlogs verantwortlich ist. Die Erstellung zusätzlicher Anforderungen kann delegiert werden, nicht aber ihre laufende Überprüfung und Korrektur.

Folgende Erweiterungen werden empfohlen:

1. Produkt-Anforderungen werden vom Produkt-Owner (und HelferInnen) mit Workshop-Techniken zu abgegrenzten Domänen/Subdomänen erarbeitet, die von Beginn an die strukturierte Beschreibung von Anforderungen fördern: Workshops zum "Event Storming" und zur "Geschäftsprozess-" oder "GUI-Workflow" Analyse" mit Post-It Notation, die wichtige Elemente des "Story Mapping" beinhalten um die Reise eines Benutzers in einer Applikation, oder die Reise eines Geschäftsstückes durch einen Geschäftsprozess zu veranschaulichen. Hinweis: Sowohl Workflows in grafischen Benutzeroberflächen als auch Geschäftsprozesse auf höheren Ebenen folgen einem Ablauf, der in beiden Fällen mit ähnlichen Kreativ-Techniken in einem fachlichen Workshop ausgearbeitet und visualisiert werden kann. Für Benutzermasken ist darüber hinaus ein Skizze der Masken und ein Glossar bereits identifizierter grob beschriebener Gechäftsobjekte hilfreich, die in den Masken bearbeitet werden.
   
2. Mit Bedacht ausgewählte elektronische Hilfsmittel verhindern weder den Einsatz physischer Scrum-Boards, Backlog-Boards noch die korrekte Anwendung agiler Rahmenwerke und die damit verbundene persönliche Kommunikation. Für das Produkt wird eine für alle Stakeholder einsehbare Product-Backlog Applikation bereit gestellt, die die nachfolgend beschriebenen Erweiterungen unterstützt.
3. Die klassische User Story kann in einer geeigneten Product-Backlog Applikation zusätzlich zu den im Scrum Guide geforderten Attributen (Id, Beschreibung, Priorität, Readyness) weitere Informationen enthalten, für die auf einer Papier-Karte kein Platz ist, z.B. ergänzende "Lean UML Diagramme". Zu beachten: Zusätzliche Information muss immer aktuell und vom Product-Owner geprüft sein und den damit verbundenen Aufwand aus Produktsicht rechtfertigen. Dabei bitte die Erstellung, die Wartung und das Lesen berücksichtigen!
4. Die Story-Karte ist ein Managementwerkzeug, das bei einem initalen Workshop wie bisher von Hand erstellt werden kann. Stories können auch nach ihrer Erfassung in der Product-Backlog Applikation wieder ausgedruckt und auf einem physischen Board angeordnet werden.
5. Geeignete Product-Backlog Applikationen erlauben zudem die nachträgliche Zuordnung von Spezifikationsdokumenten z.B. mit Prozessdiagrammen, Lösungsdesign, GUI-Design, Architekturvorgaben, Status-Diagrammen, Testdaten und Testszenarien an einzelne User Stories oder übergeordnete Epics. Diese Zuordnung muss zumindest während dem Produktlebenszyklus erhalten bleiben.
6. Product-Backlog Applikationen erlauben bei der Ersterfassung von User Stories die Zuordnung zu vorgebenen fachlichen Domänen (Themen) und Subdomänen. Eine einfache Möglichkeit dazu bieten namentlich speziell gekennzeichnete Epics, z.B.: DR <Domain-Name>, DS <Subdomain-Name>, denen zugehörige User Stories bei der ersten Erfassung zugeordnet werden: z.B. "DS Authentifizierung von Kunden". Eine "DR Todo" Domäne dient als Platzhalter für den Produkt Owner, bis die Story zugeordnet wurde. Ein gemeinsam gewartetes Domänen-Glossar und ein Glossar der Akteure und Rollen wird zudem zur Erleichterung des einheitlichen Gebrauches der entsprechenden Bezeichnungen empfohlen. Im Beitrag "Lean UML und Use Case 2.0" - werden dazu unter Punkt 2 hilfreiche ergänzende Diagramme empfohlen.
7. Mit Hilfe von Workshops zum "Event Storming" oder zur "Geschäftsprozess-" oder "GUI-Workflow" Analyse", können einzelne User Stories als Ablauf-Variante oder Schritte von einem übergeordneten Ablauf identifiziert werden. Geeignete Product-Backlog Applikationen erlauben bei der Ersterfassung von User Stories die Zuordnung zu übergeordneten Abläufen, die über namentlich speziell gekennzeichnete Epics dargestellt werden, z.B.: PX <Geschäftsprozess-Name oder Workflow auf Ebene X>, z.B. "P5: Anlegen eines neuen Geschäftsfalles".
   Hinweise zur Benennung: Workflows in Benutzermasken stellen die tiefste Prozess-Ebene dar. Die höchste Ebene beschreibt eine Prozesslandkarte des Unternehmens mit den Wertschöpfungsketten der zentralen Geschäftsbereiche aus der Vogelperpektive. Im Zweifelsfall wird P3 für abteilungs- bzw. produktspezifische Prozesse verwendet, P4 für direkt ausführbare Prozesse mit und ohne Benutzer-Tasks, und P5 für untergeordnete Masken-Workflows oder automatisierte Subprozesse.
8. Epics, die Domänen representieren, enthalten eine kurze, grobe Prosabeschreibung mit Charakterisierung der enthaltenen Akteure/Rollen, Geschäftsobjekte (fachliches Datenmodell) der beteiligten IT-Systeme und Geschäftsprozesse (digitale Produkte) und deren Funktionalität (z.B. "Verwaltung von <Geschäftsobjekt XY>"). Diese Charakterisierung kann in entsprechende DSL-Glossare [Domain specific Expert-Language] ausgelagert werden. In diesem Fall reicht in der Epic Beschreibung ein Verweis auf das Glossar und eine Liste der zugeordneten Artefakte.
9. Epics, die Abläufe representieren, enthalten bei Bedarf eine Kurzfassung, eine prägnante Prosabeschreibung mit Referenzen (Links) auf untergeordnete User Stories, fachlich vorgesehene Fehlerbehandlungen, Verweise auf alternative Abläufe (ggfs. eigene Epics) und falls verfügbar eine grafische Darstellung (BPMN oder Activity Diagramm) - siehe Beitrag "Lean UML und Use Case 2.0" - unter Punkt 2. Zu jedem Ablaufschritt kann bei Bedarf ein Satzmuster (Template) mit beteiligten Akteure/Rollen, Geschäftsobjekten, IT-Systemen (digitale Produkte) und deren Schnittstellen dokumentiert werden - vgl. "Use Case 2.0" für weitere Details. Zu jedem Ablauf oder Ablauf-Schritt können optional noch Vor- und Nachbedingungen, Geschäftsegeln (z.B. Berechnungsformeln, Prüfregeln) und potentielle fachliche Fehler (Codes) ergänzt werden.
10. Stories und Epics, die im Zusammenhang mit grafischen Benutzer-Schnittstellen stehen, sollten möglichst unabhängig von einem konkreten Masken-Design und einem technischen Datenmodell beschrieben werden. Ideal sind Verweise auf ein grobes fachliches Geschäftsobjekt-Modell der zugeordneten Domäne, das nur soweit verfeinert wird, wie es zur Beschreibung bereits analysierter fachlicher Abläufe, Regeln usw. erforderlich ist. Dazu wird die Pflege eines gemeinsam gewarteten Geschäftsobjekt-Glossars (DSL-Glossar) mit entsprechender Verlinkung  empfohlen.
11. Zu jedem Product-Backlog muss zudem ein Wartungs-Handbuch aus Sicht der Betreiber bereit stehen, sowie ein Benutzer-Handbuch, wenn Benutzerschnittstellen (GUI) oder technische Schnittstellen (API) enthalten sind. Aus entsprechend markierten Inhalten (z.B. Epic Texte, bestimmte Diagramme) kann diese Dokumentation idealer Weise nach fachlichen und technischen Domänen sortiert mit Hilfe eines Templates erzeugt werden. Hinweis: die redundante Begründung offensichtlicher Geschäftswerte im Text von User Stories verhindert die Verwendung von User Story Texten in generierten Dokumenten.
12. Eine geeignete Product-Backlog Applikation bewahrt die Historie nachträglicher Änderungen, oder sie muss durch organisatorische Maßnahmen, z.B. durch eine manuelle Versionierung sicher gestellt werden. Bevor zu viele iterative Änderungen den aktuellen Stand von Funktionalitäten unkenntlich machen, müssen die Anforderungen und Story Beschreibungen manuell zu einer aktuellen Fassung zusammengeführt werden.

Diese Erweiterungen beheben folgende Nachteile "klassischer" User Stories:

• Die klassische User Story-Technik legt nahe, gänzlich auf die Dokumentation strukturierter Anforderungen zu verzichten.
• Der inhaltliche Umfang von User Stories wurde für die Verwendung in einem Management Rahmenwerk konzipiert, und nicht als Instrument zur Pflege effizient dokumentierter Anforderungen.
• Die Zuordnung zu fachlichen Themenbereichen (Domänen) wird auf das Produkt in der Produkt-Vision beschränkt, und nicht auf einzelne Stories angewendet. Damit verbundene Anforderungen würden bei der Neukonzeption von Produkten mit dem obsoleten Product-Backlog verloren gehen.
• Die einzige geforderter Ordnung von User Stories ist die Priorisierung zur Unterstützung der aktuellen Entwicklung oder Wartung. Aus fachlicher Sicht bzw. aus Sicht der Domäne ist diese Ordnung unerheblich, vgl. z.B. ein Telefonbuch das nach dem Datum der Einträge sortiert wurde.
• Ungeordnete User Stories bieten keine Information zu fachlichen Abläufen, fachlichen Architekturen oder zu übergeordneten Themen (Domäne/Subdomäne).
• Ungeordnete User Stories behindern massiv die Wartung bei Änderungswünschen in ausgewählten Themenbereichen (Subdomänen), oder an bestimmten Schnittstellen und Daten (Geschäftsobjekten), weil die Erwähnung solcher Suchbegriffe ohne Vorgaben dem Zufall überlassen wird.
• Darüber hinaus haben sich mündliche Vorgaben und Abstimmungen als einzige zulässige Ergänzungen zu User Stories, zusammen mit Wegwerfdokumenten wie Workshop-Protokolle für Vorhaben ab mehr als 3 Sprints als ungeeignet erwiesen, z.B. zur Pflege nicht funktionaler Anforderungen, Testdaten, Design Entscheidungen, Prüfkriterien - siehe auch "agile Missverständnisse".

Für die Pflege und Verwendung strukturierter Anforderungen gilt: "Mut zur Lücke", "weniger ist mehr" und "nicht aktualiserte Information ist wertlos". Die Entscheidung des Entwickler-Teams, welche der zuvor beschriebenen Möglichkeiten genutzt wird, ist laufend zu prüfen und ggfs. zu korrigieren, ebenso der Charakter dieser Erweiterungen: handelt es sich um bindende Vorgaben, oder um unverbindliche Zusatzinformationen?  

Warnung: Werden alle hier erwähnten Erweiterungen ohne nähere Prüfung in die "Definition of Done" für neue User Stories aufgenommen, oder im initalen Sprint eingefordert, blockiert der Antipattern des "inkrementellen Wasserfall Vorgehens" agile Werte wie die kontinuierliche empirische Prozessverbesserung durch ausreichend kleine Inkremente. Die Möglichkeit, zusätzliche schriftlich/bildlich dokumentierte Anforderungen mit Epics und Stories zu ergänzen, darf nicht zu Lasten des persönlichen Kontaktes und der erforderlichen Kreativität beim Gestalten von Anforderungen, Abläufen und grafischen (GUI, UX) und technischen (API) Schnittstellen gehen.