Agiles Requirements Engineering mit Story Maps

Professionelles Requirements Engineering ist auch bei agilen Vorgehensweisen wie Scrum oder Kanban eine wesentliche Voraussetzung für den Projekterfolg. Die maßgeblichen Gründe hierfür liegen in der Vielzahl von Stakeholdern, die unterschiedliche Interessen haben können, sowie in komplexen Anforderungen, die für Einzelne und insbesondere die Projektsponsor:innen und Product Owner kaum überschaubar sein können. In diesem Artikel zeigen wir die Herausforderungen des Requirements Engineering in agilen Projekten auf und geben Tipps und Erfahrungswerte weiter, wie man diese mit Story Maps meistert.

Was sind die eigentlichen Aufgaben des Requirements Engineering?

• Es beschreibt in der Produktvision die Idee und das Ziel der Software sowie ihren Nutzen aus Sicht des Auftraggebers.
• Es identifiziert und integriert alle relevanten Stakeholder und ihre Interessen.
• Es spezifiziert Anforderungen auf einer recht abstrakten Ebene.
• Es spezifiziert und dokumentiert Anforderungen in einem angemessenen Detailgrad für die Software-Entwicklung.
• Es grenzt in der Systemplanung das zu erstellende System von allen weiteren Systemen ab.
• Es lässt die Anforderungen von den betroffenen Stakeholdern prüfen und abstimmen.
• Es beschreibt und etabliert einen Änderungsprozess für Anforderungen.

Herausforderungen des Requirements Engineering im Wandel der Zeit

Gutes Requirements Engineering ist eine höchst anspruchsvolle Tätigkeit. Schon immer war die Interaktion mit verschiedensten Personenkreisen, die Modellierung auf verschiedenen Abstraktionsebenen und die unmissverständliche Dokumentation der Anforderungen sehr herausfordernd. Durch die digitale Transformation beschleunigt, setzen sich zunehmend agile Methoden auch in vormals „klassischen“ Branchen durch. Es kommen somit neue Herausforderungen auf das Requirements Engineering zu.

Auch im agilen Kontext müssen alle oben beschriebenen Aufgaben vollständig erfüllt werden. Allerdings steht hierfür nun weitaus weniger Zeit zur Verfügung: Eine kurze Time to Market muss erreicht werden und just-in-time Requirements Engineering ist zu leisten. Tätigkeiten, für die vormals mehrere Wochen oder Monate gegeben waren, müssen nun parallel zur Software-Entwicklung, aber dennoch in der gleichen Qualität erfolgen. Deshalb sind klassische Methoden und Tools nur noch bedingt geeignet:

Aufgrund der langen Laufzeit der Erstellung von Fach- und IT-Konzepten waren Ideen und Gedanken von vor 6 Monaten zum Implementierungs- oder Testzeitpunkt nicht mehr präsent in den Köpfen. Darum musste sehr viel Wert auf eine nachhaltige, eindeutige und unmissverständliche Spezifikation gelegt werden. Im agilen Umfeld wird der Fokus anders gesetzt, „individuals and interactions over processes and tools“. Es wird angestrebt, dass sich die Beteiligten just-in-time zusammen über die Ausprägung eines Features abstimmen und die Spezifikation im Detail kurzfristig geklärt wird.

Zwischen der Requirements-Erhebung, der Implementierung und dem Test lag in klassischen Projekten ein längerer Zeitraum und oft haben organisatorisch voneinander getrennte Personengruppen diese Tätigkeiten durchgeführt. Aus diesem Grund war die Vollständigkeit und die Rückverfolgbarkeit von der Anforderungen bis zum Entwicklungsergebnis und dem entsprechenden Testfall sehr wichtig. In den Methoden und Tools wird daher ein hoher Detailgrad mit dazugehöriger Dokumentation eingefordert. Im agilen Kontext hingegen heißt es: „Working software over comprehensive documentation“. Vormals notwendige Dokumentation wird eher als zu umfangreich oder sogar Verschwendung betrachtet.

Die daher auch sehr umfangreichen Tools (u.a. IBM Rational Requisite Pro, Telelogic Doors, Borland Caliber,…), die diesen Ansprüchen gerecht werden mussten, fühlen sich heute eher überdimensioniert an und entsprechen nicht mehr dem agilen Setup, das schnelle und intuitive Lösungen fordert. Intensive, flache und lange Lernkurven für Tools lassen sich mit den Time-to-Market-Notwendigkeiten und der Denkart „responding to change over following a plan“ nicht mehr in Einklang bringen.

Im agilen Software-Entwicklungsprojekten sind der „Customer“, der „Project Leader“ und die übrigen Rollen des Cartoons sehr nahe beieinander und es wird frühzeitig und regelmäßig ein benutzbares Produkt released. Auf diese Weise kann ein- und dieselbe „Schaukel“ schon früh von allen Seiten untersucht und reviewed und etwaige subjektive Interpretationen bzw. Abweichungen können in späteren Iterationen problemlos korrigiert werden. Es wird hierzu viel kommuniziert statt dokumentiert, denn die effizienteste und effektivste Methode, Informationen an das und innerhalb des gesamten Teams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Warum viel Arbeit in Beschreibungen, Skizzen, Modellierungen, Spezifikationen und Dokumentation der Schaukel investieren, wenn alle Beteiligten schon früh die echte erste Version der Schaukel begutachten und benutzen können?

Doch ganz ohne Spezifikation und Dokumentation kommt man nicht aus, ein erfolgreiches Projekt benötigt ein gemeinsames Verständnis des zu Implementierenden – hierzu werden zumeist User Stories verwendet. Dass aber nicht jeder Beteiligte die gleiche Abstraktionsebene benötigt, was zum Beispiel das geistige Gegenüberstellen von Senior Management und Software Engineer deutlich macht, ist auch hier eine Herausforderung, genau wie in klassischen Projektmethoden. Erschwerend kommt allerdings hinzu, dass es keine Zeit mehr gibt, für alle Beteiligten eine eigene zielgruppengerechte Dokumentation zu erstellen und synchron zu halten, z.B. eine Executive Summary als Slideset und UML-Modellierungen für die Techniker.

Somit kommen im agilen Requirements Engineering zu den oben beschriebenen Aufgaben folgende zusätzliche hinzu:

• Wie komme ich schnell von „Vision“ zu „Story“?
• Wenn der angemessene Detailgrad für die Techniker in den Stories steckt, wie behält man die abstrakte Ebene im Blick?
• Wie erhebe ich schnell und intuitiv die Stories und integriere hierbei die verschiedenen Stakeholder und Requirements-Quellen?
• Wie kann man auf einer angemessenen Abstraktionsebene mit den Stakeholdern interagieren, die nicht alle Details im Blick und im Kopf haben können?

Story Maps

Mit dem in der agilen Software-Entwicklung beliebten Werkzeug einer Story Map können Anforderungen in eine übersichtliche Struktur gebracht werden und die Stakeholder und Fachbereiche erhalten einen gemeinsamen Ankerpunkt für den Klärungsprozess.

In diesem Blogbeitrag wollen wir allerdings nicht die Methode im Detail erklären, hierzu gibt es bereits ausreichend viel und gute Literatur wie bspw. den initialen, frühen Blogpost von Jeff Patton, seine Story-Map-Sammelseite, das Buch User Story Mapping – Discover the Whole Story, Build the Right Product, einen ScrumAlliance Community Article und nicht zuletzt Google ;-).

Für die weitere Betrachtung sind nur einige der grundlegenden Elemente relevant. Zum einen beschreibt eine Story Map i.d.R. die „Customer Journey“ auf der horizontalen Achse, was für verschiedenste Stakeholder leicht verständlich ist. Zum anderen ist auf der vertikalen Achse die Priorisierung modelliert. Dinge, die weit oben stehen, werden zuerst implementiert und sind am detailliertesten modelliert. Ausblicke auf spätere Releases oder auch ein „das passiert dann später, in diesem und jenem Kästchen dort unten“ ist so leicht möglich.

Damit erlaubt es eine Story Map, sowohl viele – wenn auch nicht alle – der oben genannten klassischen Aufgaben als auch der neuen agilen Aufgaben im Requirements Engineering zu erfüllen.

• Das Tool, egal ob analog mit Post-its oder digital, ist simpel und erfordert kein intensives Erlernen. Alle Beteiligten können schnell beginnen und die dringlichsten Themen ad-hoc modellieren.
• Während noch Teile der Spezifikation geklärt werden müssen, kann bereits die Implementierung gestartet werden. Auch dann, wenn spätere Phasen oder Releases (weiter unten in der Map) noch vage sind und einen niedrigen Reifegrad haben.
• Durch die gute und intuitive Übersicht können Stakeholder und ihre Interessen in Review- und Feedback-Workshops effizient und effektiv abgeholt werden.
• Auf der Ebene der Kärtchen sind die Anforderungen in hoher Abstraktion dokumentiert. Die Detail-Ebene, die dann typischerweise mehr Text und mehr Informationen auf den Kärtchen enthält, lenkt aber nicht von der High-Level-Perspektive ab.
• Für die Software-Entwickler:innen können ausreichend viele Informationen auf den Kärtchen spezifiziert werden. „Ausreichend“ ist hierbei grob zu verstehen als: Der Umfang ist beschrieben und begriffen und Detailabsprachen können in kurzen, Dialogen mit dem Product-Owner erfolgen. Die Implementierung kann vorgenommen werden.
• Die Abgrenzung vom Produkt- oder Projektumfang ist eindeutig zu erkennen:
  1. Eine Anforderung steht nicht auf der Map, somit ist sie nicht im Scope
  2. Eine Anforderung steht explizit sehr weit unten in der Map oder sogar in einer “out-of-scope“-Zeile

Als Beispiel für eine Aufgabenstellung im agilen Requirements Engineering, bei der eine Story Map out-of-the-box keinen Lösungsvorschlag darstellt, sei der Änderungsprozess für die Anforderungen genannt. Vereinbarungen wie

• Wie werden Entscheidungen gefällt und ggf. auch dokumentiert?
• Wer kann Karten hinzufügen, verschieben oder löschen?
• Wann ist wer zu informieren?

muss das Projekt selbst definieren. Hierfür sind leichtgewichtige Verfahren, die auch regelmäßig in einem inspect-and-adapt-Zyklus hinterfragt und ggf. angepasst werden, zu empfehlen.

Unsere Erfahrungswerte

Eine digitale Story Map zum Schreiben von User Stories hat sich als deutlich besser, einfacher und leichtgewichtiger im Handling erwiesen als klassische Methoden wie z.B. Fachkonzepte oder Requirements Tools. Ganz besonders bewährt hat sich die Story Map mit Papier und Post-its in frühen Requirements Workshops. So haben wir schon mehrfach erfolgreich Anforderungen erhoben und strukturiert, ohne große Aufwände oder Informationsverluste zwischen Workshop und nachträglicher Dokumentation im Tool. Es kam nie zu Situationen, in denen sich ein Workshop-Teilnehmer bei der Betrachtung der dann digitalisierten Story Map nicht wiedergefunden hätte, was ein immenser Vorteil gegenüber Listen, Tool-Exporten oder ausführlicher Prosa in Dokumenten ist.

Die gemeinsame Abstimmung und Priorisierung, inklusive Umpriorisierung von Releases und Stories mit den Stakeholdern, konnte mit einer Story Map zügig durchgeführt werden. Auch verteilte Teams, wie sie in der Realität oft vorkamen, konnten gut gemeinsam an den Anforderungen arbeiten.

Es gibt diverse digitale Tools zum „Storymappen“, auch solche, die direkt in das beliebte Tool Jira integriert sind. Die im Screenshot gezeigte Lösung von storiesonboard.com kann mit geringem technischem Hintergrundwissen innerhalb von fünf Minuten jeder verstehen und erlernen. Der Gesamtkontext der Anforderungen ist dabei sehr übersichtlich dargestellt und die Bearbeitung kann schnell und in verteilten Teams durchgeführt werden.

Wir wollen an dieser Stelle mitgeben, dass sich im Rahmen der digitalen Transition und bei der erfreulicherweise stets zunehmenden Anzahl von echten agilen Projekten auch die notwendigen Methoden ändern. Hierbei haben wir in unseren Projekten praktische und sehr gute Erfahrungen mit Story Maps gesammelt und empfehlen, den Einsatz dieses Tools in Betracht zu ziehen.

Kontakt

In unseren Projekten übernehmen wir unter anderem die Rolle des Product Owners, sowohl in der Anforderungserhebung als auch während der Entwicklung und Implementierung einer Lösung. Wir erachten diese Rolle als essentiell wichtig für den Projekterfolg, wobei wir uns ihrer Herausforderungen bewusst sind. Um sie dennoch erfolgreich ausfüllen zu können, ist eine Story Map ein gutes Werkzeug unter vielen weiteren Methoden und Tools.

Mehr Informationen zu unserem Portfolio gibt es auf inovex.de, per Mail an info@inovex.de oder telefonisch unter +49 721 619 021-0.