Was agiles Anforderungsmanagement auszeichnet:

  • Agile Grundwerte der Organisation: vgl. agiles Manifest
  • Die konsequente Vermeidung von Wegwerf-Artefakten und die Reduktion von Planungs-Overhead durch emprische Prozessverbesserung
  • Die Zuordnung von Anforderungen und Domänen/Subdomänen zu Produkten und der Verzicht auf weitere Vorgaben an die Rückverfolgbarkeit
  • Die eingesetzten Management Rahmenwerken und Werkzeugen zur Produkt-Entwicklung und Weiterentwicklung: vgl. Scrum, Kanban mit Produkt-Backlog und Kanban Board und Begriff-Glossare
  • Die eingesetzen Methoden, Notationen und Ziele zur Erhebung strukturierter Anforderungen: vgl. z.B. Klassische und "erweiterte User Stories" und "Lean UML" mit "Use Case 2.0".
  • Der Zeitpunkt der Erstellung, d.h. wann und wie oft strukturierte Anforderungen erhoben bzw. verfeinert werden: Ziel ist eine schrittweise, durch den Geschäftswert gesteuerte Verfeinerung, über die Priorisierung im Product-Backlog

Methoden und Notationen für agiles Anforderungsmanagement

Das Rahmenwerk älterer Scrum Guides (vor 2011) wurde üblicherweise mit "User Stories" als Hilfsmittel zur Erhebung und Pflege von Anforderungen in agilen Projekten ergänzt und zur Entwicklung von mehr und weniger komplexen Produkten eingesetzt. Diese Kombination erwies sich später als eingeschränkt im Vergleich zu den weiterhin praktizierten Techniken für professionelles Anforderungsmanagement. Auf Grund der großen Popularität und Vorteile "schlanker" Vorgehensweisen, wollte aber kaum jemand zu den bewährten, aber schwergewichtigen Methoden und Werkzeugen zurückkehren, die Kreativität und den direkten Kontakt mit dem Kunden einschränken.

Die klassische Technik der "User Stories"

User Stories berücksichtigen ausgewählte Erkenntnisse der kognitiven Psychologie: Menschen ordnen ihre Welt in Akteuere, Beziehungen zwischen Objekten und deren Verhalten mit Hilfe von Abstraktion. Menschen können vor diesem Hintergrund Wünsche äußern, begründen und bewerten. Die in der ursprünglichen "User Story" Technik vorgeschlagene Struktur vernachlässigt wichtige Aspekte "echter Geschichten", weil  zu Beginn der "agilen Revolution" versucht wurde, Anforderungen auf kurze Überschriften auf Papier-Karten zu reduzieren, und darüber hinaus nur Abnahmekriterien (Rückseite der Karte), den Produkt-Code (Programmiersprache) und die persönliche Abstimmung zuzulassen. Der Beitrag "agile Missverständisse" erläutert, warum dieser Ansatz in der Praxis nur für sehr einfache und kurzlebige Produkte ausreicht.

Der inhaltliche Umfang von User Stories ist für die Verwendung in einem Management Rahmenwerk konzipiert, und soll vor der Umsetztung so weit ausgearbeitet sein, dass die damit verbundenen Aufgaben vom gesamten Team in ein bis zwei Tagen erledigt werden können. Der inhaltliche Umfang ist folglich nicht zur effizienten Beschreibung strukturierter Anforderungen gedacht.

User Stories werden vom "Product Owner" zur Bereitstellung eines (meist digitalen) Produktes in persönlicher Abstimmung mit fachlichen AnsprechpartnerInnen (EndbenutzerInnen, Power UserInnen, ExpertInnen) skizziert und dokumentiert. Dazu eigenen sich unterschiedliche Workshop-Techniken und Brainstormings, da wenig formale Vorgaben zu berücksichtigen sind. Erste User Stories werden zunächst in einem Vorbereitungs-Sprint gesammelt, und später laufend ergänzt, verfeinert und unter Umständen auch wieder verworfen. Der Product Owner kann während laufenden Sprints die Dokumentation von User Stories aus Workshops auch an andere Scrum Rollen delegieren, ohne jedoch die Verantwortung für die Korrektheit und Vollständigkeit abzugeben.

User Stories werden nach vereinbarten Regeln in der fachlichen Sprache des Kunden verfasst, die neben empfohlenen Satzmustern (Templates) diverse "Best Practices" aus dem Anforderungsmanagement berücksichtigen können, z.B. die Sicherstellung des einheitliche Gebrauches von Begriffen durch laufend erweiterte Glossare. Davon wird in der Praxis leider selten Gebrauch gemacht.

Typisches Satzmuster (Templates) für User Stories:
Als <Rolle> will ich <Ziel> [,so dass <Grund>]

Zur Begrenzung der Satzlänge wird dabei häufig auf das Konzept des verwendeten Geschäftsobjektes (Daten- und Schlüssel-Analyse) und des beteiligten IT-Systems (Produkt, Schnittstelle) verzichtet oder vergessen. Diese wichtigen Informationen werden z.B. in der Domänen-Analye, Anwendungsfall-Analyse, Schnittstellen-Analyse und Prozess-Analyse berücksichtigt. Es fehlt zudem die Möglichkeit, Abläufe oder fachliche Beziehungen zu fordern.

Das Akronym INVEST hilft beim verinnerlichen folgender Merkmale einer guten Story:

  •  [Independent] Jede Story muss eindeutig identifizierbar sein, dazu wird überlicherweise eine Nummer vergeben. Darüber hinaus sollen möglichst wenig Abhängigkeiten zu anderen Stories bestehen, oder es sind entsprechende Hinweise vorzusehen.
  • [Negotiable] die beschriebene Funktionalität soll keine unnötigen Vorgaben und Annahmen für die Umsetzung beinhalten, und so formuliert sein, das ausreichend Spielraum für eine effiziente Realisierung bleibt. Deshalb sollten Stories nicht auf konkretes GUI Design, konkretes Schnittstellendesign oder konkrete technische Datenstrukturen verweisen, außer diese sind durch nicht funktionale Anforderungen vorgeben.
  • [Valuable] Der geschäftliche Wert der beschriebenen Funktionalität wird ggfs. erläutert, wenn er nicht unmittelbar ersichtlich ist. Hinweise auf den Wert der Möglichkeit, Geschäftsobjekte anlegen, ändern oder entfernen zu können (CRUD) sind in der Praxis z.B. überflüssig.
  • [Estimateable] Die mit der geforderten Funktionalität verbundene Arbeit muss vor dem Hintergrund des gemeinsam erarbeiteten Wissens schätzbar sein.
  • [Small] klein - vom Team in ein bis zwei Tagen umsetzbar.
  • [Testable] Testbar - vor dem Hintergrund des gemeinsam erarbeiteten Wissens muss das Team für die mit einer Userstory verbundenen Akzeptanzkriterien ausreichend genaue Tests erstellen können (wenn möglich automatisiert!).

Es ist zudem gestattet, schriftlich "Akzeptanzkriterien" zu dokumentieren, jedoch ohne konkrete Testdaten und Testszenarien. Derartige Information soll wenn möglich nur mündlich und über wohl strukturierten Code ausgetauscht werden.

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.