Vom Requirements Engineering zum Storytelling

Früher haben wir Projekte durchgeführt, die ein Start und ein Ende hatten. Zu Beginn stand eine umfangreiche Analyse- und Design-Phase, in der die Wünsche des/der Kunden – oder besser Stakeholder – von Business Analysten oder Requirements Engineeren in Form von Anforderungen aufgenommen, niedergeschrieben, analysiert und konsolidiert wurden. Ergebnisse dieser Phase waren Fach- und IT-Konzepte. Auf deren Grundlage fand in der nächsten Phase die Entwicklung statt; anschließend umfangreiche Tests. Am Projektende dieses wasserfall-artigen Prozesses war die zu implementierende Software fertig oder wurde als fertig definiert und erfüllte mehr oder minder die Anforderungen der Kunden bzw. Stakeholder.

Heute arbeiten wir in der Softwareentwicklung an Produkten. Die Wünsche der Stakeholder werden von Product Ownern in Form von User Stories erst in Product Backlogs und anschließend in Sprint Backlogs geschrieben. Die Inhalte der Sprint Backlogs werden dann vom Entwicklungsteams in zwei- bis vier-wöchigen Sprints implementiert, getestet und am Ende der Sprints dem Product Owner und die Stakeholdern präsentiert. Rückmeldungen aus der Präsentation fließen in das Product Backlog ein. Das Ganze wird fortwährend iteriert, sodass der Funktionsumfang der Software bzw. des Produkts mit jedem Sprint wächst.

Aus Sicht des Requirements Engineering könnte ein erster oberflächlicher Versuch Parallelen zwischen früher und heute zu ziehen, wie folgt aussehen:

• Business Analyst/ Requirements Engineer = Product Owner
• Anforderung = User Story
• Fach-/IT-Konzept = Product Backlog/Sprint Backlog

Im Mittelpunkt stehen die Anforderungen bzw. die User Stories und die Art und Weise, wie diese beschrieben und dokumentiert werden. Im Falle der Anforderungen haben sich folgende Kriterien bei deren Erfassung etabliert:

• Vollständig: Alle Anforderungen des Kunden müssen explizit beschrieben sein, es darf keine impliziten Annahmen des Kunden über das zu entwickelnde System geben.
• eindeutig definiert / abgegrenzt: Präzise Definitionen helfen, Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden.
• verständlich beschrieben: Damit sowohl der Auftraggeber als auch der Entwickler mit vertretbarem Aufwand die gesamten Anforderungen lesen und verstehen kann.
• Atomar: Es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein. Das Kriterium für ein „Atom“ sollte die Entscheidbarkeit einer Anforderung sein.
• Identifizierbar: Jede Anforderung muss eindeutig identifizierbar sein (z.B. über eine Kennung oder Nummer).
• einheitlich dokumentiert: Die Anforderungen und ihre Quellen sollten nicht in unterschiedlichen Dokumenten stehen oder unterschiedliche Strukturen haben.
• Nachprüfbar: Die Anforderungen sollten mit Abnahmekriterien verknüpft werden, damit bei der Abnahme geprüft werden kann, ob die Anforderungen erfüllt wurden. Testfälle werden aus den Abnahmekriterien abgeleitet.
• Konsistent: Die definierten Anforderungen sind untereinander widerspruchsfrei.

Das Ergebnis dieses Kriterienkataloges war folgende Schablone zur Formulierung von Anforderungen:

[System] - MUSS/KANN/SOLL - [Akteur] die Möglichkeit bieten/FÄHIG SEIN – [Objekt] – [Prozesswort]

Ein Beispiel könnte sein: „Das Zeiterfassungssystem muss dem Mitarbeiter die Möglichkeit bieten, seine Arbeitszeit projektbezogen zu erfassen.“

Bei der Suche nach etwas Vergleichbaren für User Stories weiß das Internet auch schnell Rat. So sollen User Stories nach den INVEST Kriterien formuliert werden:

• Independent: Eine User Story sollte unabhängig von anderen User Stories sein.
• Negotiable: Sie soll verhandlungsfähig sein, also nicht spezifisch für ein Feature sein.
• Valuable: Jede User Story soll nicht nur einen Nutzen, sondern auch einen Mehrwert aufweisen.
• Estimable: User Stories sollen gut schätzbar sein.
• Small: Sie soll nicht zu umfangreich, sodass sie in einen Sprint passt.
• Testable: Eine User Story soll testbar sein, auch wenn es noch keinen Test für die User Story gibt.

Analog zur Anforderungsschablone gibt es auch eine für User Stories:

Als [Rolle] möchte ich [Ziel/Wunsch], um [Nutzen]

Das obige Beispiel ließe sich als User Story wie folgt formulieren: „Als Mitarbeiter möchte ich das Zeiterfassungssystem nutze, um meine Arbeitszeit projektbezogen zu erfassen.“

Die Parallelen sowohl zwischen den Kriterien als auch bei den Schablonen lassen schnell den Eindruck entstehen, dass lediglich eine kleine Anpassung in der Formulierung der Kundenwünsche erforderlich ist, um agil und auf dem Stand der Zeit zu sein. Sollten dann eine oder mehrere User Stories für die Erfassung der Kundewünschen nicht ausreichen, können zum Glück noch die Akzeptanzkriterien der Stories, sowie die Definition of Ready und die Definition of Done herhalten, um weitere Details zu beschreiben. – Und schon entsteht ganz schnell auch in agilen Projekten eine umfangreiche Dokumentation, die es leicht mit einem Fach- oder IT-Konzept aus der „alten“ Zeit aufnehmen kann.

War das die Idee hinter dem Konzept der User Stories? – Nein! Denn sobald ein Team bei dem oben skizzierten Vorgehen angekommen ist, ist es der Gruppe der „Template Zombies“ (vgl. Tom DeMarco et al.) beigetreten. Es lässt sich bei der Arbeit von Templates (Schablonen u.ä.) steuern, statt vom Denkprozess, der nötig ist, um gute Produkte abzuliefern.

Der Begriff „Story“ drückt aus, wie wir diese benutzen (sollen), nicht was wir aufschreiben „sollen). Ziel ist es, eine gute Geschichte zu erzählen und eine Konversation zu starten, die das Team mitnimmt und begeistert. Dabei sollen der Story-Gedanke und die Art der Formulierung helfen, den Fokus auf den Kunden zu legen und die Wünsche aus seiner Perspektive zu sehen. Um das zu gewährleisten, kann auch jedes andere Konstrukt als Basis für die gemeinsame Konversation genommen werden. In diesem Gespräch entsteht nach und nach ein gemeinsames Bild der Welt. Im Vordergrund steht, gemeinsam die besten Lösung für ein Problem zu finden, das alle Beteiligten verstanden haben. Hierbei gilt: Der Weg ist das Ziel. – Die in der Konversation gemachten Erkenntnisse sind das wichtigste an der „Story“ – nicht die Story selbst. Daher ist es sinnvoll, diese erlangten Erkenntnisse in geeigneter Form zu dokumentieren, damit das Wissen darüber nicht verloren geht.

Sinnvolle Inhalte einer Story-Konversation sind:

• Wer macht das?
• Was macht er/sie?
• Warum macht er/sie das?
• Was passiert außerhalb der Software? (z.B. wo wird diese eingesetzt)
• Was läuft schief?
• Welche Fragen und Annahmen habe bzw. treffe ich?
• Wie könnte eine bessere Lösung aussehen?
• Wie könnte es umgesetzt werden?
• Wie lange dauert die Umsetzung?

Wichtig ist, dass in der Konversation keine Diskussionen und Vereinbarungen von Anforderungen stattfinden, sondern ein Gespräch über Probleme und Lösungen geführt wird. Der Fokus liegt auf dem Wesentlichen! Das hat bereits Antoine de Saint-Exupéry Anfang des 20. Jahrhunderts erkannt: Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn es nichts mehr wegzulassen gibt.