Modellieren im agilen Requirements Engineering – wohldosiert und leichtgewichtig
Modelle – also abstrahierende, meist graphische Darstellungen komplexer Sachverhalte – haben es im Zeitalter agiler Softwareentwicklung nicht immer leicht. Vielen agilen IT-Profis gilt Modellierung als zu schwergewichtig, zu aufwändig, und die zugehörigen Tools als nicht bedienbar genug. In diesem Artikel möchte ich anhand eines Beispielprojekts zeigen, dass Modelle an der richtigen Stelle und in geeigneter Dosierung einem agilen Team definitiv von Nutzen sein können – und auf diese Weise einen kleinen Beitrag zu ihrer Ehrenrettung leisten.
Aus meiner eigenen Coaching-Erfahrung kann ich berichten, dass es Vorurteile gibt, die mir in agil arbeitenden Teams immer wieder begegnen. Was etwa den Umgang mit Anforderungen angeht, führen die folgenden beiden meine private Hitliste an:
- "Im Agilen brauchen wir kein Requirements Engineering mehr, es gibt nur noch User Stories."
- "Im Agilen wird nichts dokumentiert." (Ergänzt um: "Modelle sind ohnehin nur Dokumentation.")
Laut Albert Einstein ist es schwieriger, ein Vorurteil zu zertrümmern als ein Atom… Trotzdem, diese beide Aussagen sind in ihrer Absolutheit schlicht falsch. Wie sich Techniken des "klassischen" RE nutzbringend in ein agiles Vorgehen integrieren lassen, habe ich ausführlich in einem früheren Artikel beschrieben [1]. Hier nun werde ich mich – sozusagen als Spezialfall zum eben genannten Artikel – auf den punktuellen und konkreten Einsatz von Modellen konzentrieren. Diese hatten es schon vor dem Aufkommen agiler Arbeitsweisen nicht immer einfach, obwohl von zahlreichen Autoren mehrfach darauf hingewiesen wurde, dass sie eben nicht "nur Dokumentation" sind, sondern als Kommunikationsmittel fungieren können, die frühe Fehlerfindung unterstützen, die Generierung von Code- und Test-Artefakten ermöglichen u.v.m [2]. Ich möchte alle diese Möglichkeiten hier jedoch ausblenden und stattdessen näher am agilen Vorgehen argumentieren:
Die Aussage, dass "im Agilen nichts mehr dokumentiert wird", ist, wiewohl verlockend, grundverkehrt und übrigens auch durch nichts im agilen Manifest oder der agilen Literatur belegt. Richtig ist hingegen, dass Agilität im speziellen und Lean Management im allgemeinen es ablehnt, Dokumente zu erstellen, die niemand braucht! Diese heißen dann plakativ "waste" oder im Denglischen – sehr schön angelehnt an Hard- und Software – "Schrankware". Positiv formuliert: Agile Teams dokumentieren nur, wenn mit dem Dokumentationsaufwand ein Wert oder Nutzen einhergeht!
Wie aber entsteht Wert von Dokumentation? Auf zwei Arten: Entweder das fragliche Dokument muss zwingend erstellt werden (z. B. weil vertraglich oder regulatorisch gefordert), oder es hilft dem Team, das Produkt und den damit verbundenen "customer value" effektiver und effizienter zu liefern. Die erste Art ist selbsterklärend und kann etwa mittels einer "Definition of Done" systematisch im Entwicklungsprozess berücksichtigt werden. Die zweite Art hingegen steht im Zentrum dieses Beitrags: Ich möchte an konkreten Beispielen illustrieren, welche Modelle einem agilen Team wann wie helfen können.
Das Beispiel-Projekt
Schauen wir uns dazu folgendes IT-Projekt an, in dem es um die Entwicklung einer "Zeiterfassungs-App" geht. Auslöser ist der Wunsch des Managements eines IT-Dienstleisters, eine "mobile IT-Unterstützung zu haben, die unseren MitarbeiterInnen eine unkomplizierte Erfassung ihrer Projektzeiten ermöglicht und die alle notwendigen Schnittstellen auf Knopfdruck mit den benötigten Daten versorgt". Ein internes Projekt wird aufgesetzt, bei dessen Kick-Off-Veranstaltung die Vertreter der identifizierten Stakeholder bereits mit am Tisch sitzen bzw. am Whiteboard stehen:
- ein Consultant, der in wechselnden Kundenprojekten arbeitet,
- ein Vertreter der Buchhaltung, die insbesondere für die Rechnungsstellung an die jeweiligen Kunden verantwortlich ist und
- ein Team Lead, der ein Team von Consultants unterstützt und deren Auslastung und Einsatzplanung im Auge hat.
Ein Vertreter von Kundenprojekten – also der Stakeholder Kunde – ist aus verständlichen Gründen im firmen-internen Kick-Off nicht dabei, wird aber bei allen entstehenden Fragestellungen grundsätzlich berücksichtigt, da jedes Kundenprojekt die geleisteten Arbeitsstunden gemeldet haben möchte (meist mit jeweils sehr individuellen Wünschen und Anforderungen hinsichtlich Format und Inhalt).
Da alle Beteiligten mit agiler Softwareentwicklung wohlvertraut sind, entsteht zügig ein Projektteam gemäß Scrum mitsamt Product Owner, Scrum Master und Entwicklungsteam (Abb. 1). Das Entwicklungsteam ist cross-funktional aufgestellt, d. h. die Teammitglieder bringen Wissen und Erfahrung aus den Bereichen Programmierung, Architektur und Design sowie Test und Qualitätssicherung mit. Fachliches Domänenwissen besitzen die meisten von ihnen aus eigenen Kundeneinsätzen ohnehin. Insbesondere aber gibt es ein Teammitglied, das sich sowohl mit "klassischem" Requirements Engineering als auch mit UML-Modellierung auskennt. Der Product Owner des Projekts ist in diesen beiden Disziplinen hingegen sehr unerfahren, hatte mit ihnen aber erste Berührungspunkte in seinem letzten Projekt.
Die Produktvision
Erster Schritt ist die Erstellung einer Produktvision, damit alle Projektbeteiligten ein möglichst gutes und einheitliches Verständnis über das Endprodukt besitzen und mit ihren Aktivitäten und Entscheidungen auf dasselbe Ziel zusteuern. Dazu wird ein Workshop aufgesetzt, in dessen Vorfeld die identifizierten Stakeholder um ihre Wünsche und Bedürfnisse gebeten wurden. Diese vorbereitende Sammlung beinhaltet u. a. folgende Aussagen:
- "Die Geschäftsführung möchte, dass nur Zeiten erfasst werden, die dem Arbeitszeitgesetz entsprechen."
- "Als Consultant möchte ich Arbeitszeiten jederzeit unterwegs erfassen und ändern können."
- "Die Buchhaltung möchte die erfassten Zeiten so zugeliefert bekommen, dass die kundenspezifische Rechnungsstellung vereinfacht wird."
- "Team Leads möchten Übersichten über die Arbeitszeiten ihrer Mitarbeiter."
- "Mir als Consultant ist wichtig, dass andere Consultants meine Zeiten nicht einsehen können."
- "Besonders praktisch wäre es für mich als Consultant, wenn Zeiteinträge aus meinen Outlook-Terminen generiert werden könnten."
Im Workshop selbst entsteht die Produktvision in Form eines leichtgewichtigen "Produktposters". Gemäß der in [1] beschriebenen Vorgehensweise kommen verschiedene agile und RE-Techniken zum Einsatz (z. B. Satzschablonen, Kontextmodell, UseCase-Analyse, aber auch Wireframing, Personas, User Journeys), um in der Produktvision die wichtigsten Merkmale, Geschäftsziele, Produktrisiken, Constraints und Funktionalitäten zu versammeln. Auf diese Weise soll jedes (neue) Teammitglied auf einen Blick die zentralen Informationen zum Produkt mit einem Blick erfassen können – aber eben nur die "wichtigsten", ohne Anspruch auf Vollständigkeit. Im Beispiel-Projekt sah das Ergebnis so aus wie in Abb. 2:
Mit Blick auf unser Thema (= wo und wie kann gezielte Modellierung agilen Teams helfen?) möchte ich an dieser Stelle kurz innehalten und auf zwei Details des Produktposters hinweisen:
- (M1) Graphische Modelle – hier: ein UseCase- und ein Kontext-Diagramm – helfen dem Team, das Endprodukt, seine Funktionen und seine Umgebung (Schnittstellen, Nutzerrollen) aus Außensicht besser zu verstehen.
- (M2) Modelle können initial immer leichtgewichtig am Whiteboard entstehen.
Im Verlaufe eines Projekts wird sich zeigen, dass es sich für die Wartung und Pflege des Produkts lohnt, ausgewählte Modelle vom Whiteboard in ein Modellierungstool zu überführen, um sie in die Produkt-Dokumentation zu integrieren oder sie fürs Tracing mit anderen Projektergebnissen einsetzen zu können. Dies wird aber jeweils vom Team im Einzelfall entschieden und folgt immer einer Nutzenabwägung.
Permanente Aktivitäten
Das Produktposter beinhaltet Informationen, die im Projektverlauf immer wieder erweitert oder aktualisiert werden, weil sie Veränderungen unterliegen können. Das kann beispielsweise jederzeit in einem Daily Stand-Up passieren, etwa wenn ein Teammitglied auf ein neu identifiziertes Produktrisiko hinweist oder technologische Neuerungen die Liste der Constraints beeinflussen. Anders gesagt: Das Produktposter ist ein erstes Artefakt, das permanenter Pflege unterliegt. Weitere werden später im Text noch auftauchen, eins davon ist aber für unser Modellierungsthema interessant: das fachliche bzw. Domänen-Glossar.
Ich betrachte das Domänen-Glossar gerne als permanent anwachsende "Sammlung" von fachlichen Begriffen, die von allen Projektbeteiligten einheitlich gebraucht werden sollten, um Missverständnisse und daraus resultierenden Mehraufwand zu vermeiden. Die Arbeit daran beginnt im Beispielprojekt spätestens im Produktvisions-Workshop: Bei der Beschreibung des Produkts aus Kundensicht tauchen unvermeidlich fachliche Spezialbegriffe auf, die Kandidaten für eine zentrale Definition an geeigneter Stelle sind (z. B. in einem Projekt-Wiki). In einem ersten Wurf entsteht deshalb eine typische Tabellen-Struktur mit den zwei Spalten "Begriff" und "Definition" (im Beispielprojekt: "Erläuterung"):
Bald darauf führt das Team Diskussionen wie "Was genau gehört zu einem Zeiteintrag?" und "Wie ist das Verhältnis zwischen Mitarbeitern und Projekten?". Deshalb entstehen bedarfsgetrieben – wieder am Whiteboard – in einer Refinement-Session erste einfache Klassenmodelle, die die reine Begriffsdefinition des Glossars um Begriffs-Beziehungen und Begriffs-Details bedarfsgerecht erweitern. Da sich ebenfalls schnell abzeichnet, dass Diskussionen rund um gewünschte Changes an eben diesem Modell stattfinden und die Entwickler es außerdem als hilfreichen Input für ihre Design- und Coding-Aktivitäten bewerten, wandert auch dieses Klassenmodell in einem frühen Sprint vom "Papier" in das gewählte Modellierungstool.
Als Benefit halten wir also fest:
- (M3) Modelle können bei der Klärung von Begriffszusammenhängen und beim Design unterstützen.
Initiales Product Backlog
Wie in jedem Projekt stellt sich dem Product Owner schnell die Frage: Wie komme ich zu ersten User Stories? In unserem Beispielprojekt hängt die Antwort förmlich vor seinen Augen, denn: Neben den zu Projektbeginn gesammelten Stakeholder-Wünschen beinhaltet das Produktposter (Abb. 2) ein – wenn auch unvollständiges – UseCase-Modell! Die dort identifizierten UseCases erweisen sich als gute Kandidaten für erste Stories, genauer: für Epics (also große Stories, die nicht innerhalb eines Sprints umzusetzen sind). Ein erstes Herunterbrechen und Priorisieren von Stories stellt den PO vor keine großen Schwierigkeiten, da ihm die Methode "Story Mapping" pro UseCase gute Dienste leistet [3]. Und die benötigten Akzeptanzkriterien zu den Stories werden als konkrete Beispiele gemäß der Methode "Specification By Example" ebenfalls gut und zügig erstellt [4].
Refinement der ersten Story
Mit Blick auf Kriterien wie Kernfunktionalität (MVP!) und Business Value wird die Story "Als Consultant möchte ich meine Stunden pro Tag erfassen können, um meine Arbeitszeiten und Projektaktivitäten tagesgenau nachvollziehen zu können" Gegenstand des ersten Refinements. Die Vorstellung der Story durch den PO führt im Team zu Fragen wie: Was ist mit Pausenzeiten? Was sind denn die genauen Vorgaben des Arbeitszeitgesetzes? Soll es Begrenzungen für die Arbeitszeit geben? Das Team erkennt dabei, dass es Gefahr läuft, sich in zu vielen Details und Sonderfällen zu verlieren, und beschließt deshalb: Wir sollten erstmal den einfachsten Fall behandeln! Und fast im selben Atemzug: Lasst uns den einfachsten Ablauf "mal schnell" hier am Whiteboard skizzieren. Das Ergebnis, wenn auch schon in der toolbasierten Version, ist zu sehen in Abb. 5.
Dieses kleine Modell fördert nicht nur das gemeinsame Verständnis des Teams, sondern hilft ihm dabei, die "Größe" der Story zu bewerten (abgesehen davon, dass es für anstehende UI/UX-Aufgaben wertvollen Input liefert). Das Team kommt zu dem Schluss, den Prozessschritt "Zeiterfassung prüfen" und die Eingabe mehrerer Zeiten zum gleichen Projekt für spätere Stories zurückzustellen, da es das Risiko sieht, dass der in Abb. 5 modellierte Ablauf nicht innerhalb eines Sprints in der nötigen Qualität entwickelt, getestet und dokumentiert werden kann. Kurzzeitig wird als alternative Lösung diskutiert, jeden einzelnen Prozessschritt in einer eigenen Story abzubilden (eine bekannte Story-Splitting-Strategie für große Stories), aber das Team befürchtet, dass bei diesem Vorgehen sowohl Demo-Fähigkeit als auch Business Value nicht optimal ausfallen. Man einigt sich stattdessen auf einen minimalen "Happy Path", der in Abb. 6 zu sehen ist.
Das zentrale Akzeptanzkriterium zu dieser Story lautet, sich in der (entstehenden) Testumgebung als "Testconsultant1" anzumelden, die Arbeitszeit "8:30-10:00" am 2.2.2020 dem vorkonfigurierten "Testprojekt3" zuzuweisen, als Kurzbeschreibungstext "All work and no play makes Jack a dull boy" einzutragen, den Eintrag abzuschließen, sich abzumelden, wieder als "Testconsultant1" anzumelden und diesen Eintrag anzeigen zu lassen. Dieses mittels SBE gefundene konkrete Beispiel wird in Gherkin-Notation an der Story spezifiziert und dann während des Sprints in einen automatisierten Testfall überführt. Und die Frage, mit welchen Demo-Szenarien der PO über eine Abnahme der Story entscheiden will, ist damit gleich mit erledigt.
Rund um das Product Backlog sind mit Modellhilfe also gleich mehrere Dinge geschehen:
- (M4) Modelle können dabei helfen, Stories zu finden (s. UseCase-Modell oder das Zerlegen von Ablaufdiagrammen).
- (M5) Modelle können beim Verstehen, beim Schätzen und beim "Schneiden" von Stories helfen.
Weitere Team-Tasks
Das Produktposter liefert dem Team nicht nur einen guten Startpunkt für erste Stories, sondern führt auch sofort zu ersten technischen Tasks, z. B. den Aufbau benötigter Komponenten in einer Testumgebung. Diese Aufgaben werden bewusst nicht in Form von "technischen Stories" vom PO ins Product Backlog eingeführt, sondern als Tasks (!) in eine eigene Swimlane des Sprint Backlogs gepackt, um diese Arbeit im Sprint einplanen zu können, auch wenn sie nicht unmittelbar mit einem "Business Value" einhergeht [5]. Dazu gehören u.a. Tasks wie:
- Testumgebung aufbauen und
- Architekturdokumentation beginnen (für spätere Wartung und Pflege des fertigen Produkts).
Diese beiden Aufgaben bekommen Input aus dem Produktposter – sowohl vom Kontextmodell (welche Schnittstellen brauchen wir in unserer Testumgebung?) als auch vom UseCase-Modell (welche Testkennungen mit welchen Rollen/Rechten müssen wir anlegen?). Wir sehen:
- (M6) Modelle können dem Team bei Test- und Entwicklungsaufgaben helfen.
Einige Sprints später
Gönnen wir uns an dieser Stelle ein "Vorspulen": Im Beispiel-Scrum-Projekt kommen und gehen weitere Sprints (nicht, ohne in Retrospektiven kritisch untersucht zu werden), es entstehen wie gewünscht "Routine & Rhythmus" im Team, und viele der bisher genannten Artefakte – Glossar, Modelle, Produktvision – entwickeln sich erwartungsgemäß Story für Story weiter.
Eine spezielle Story in Sprint 6 bietet dem Team Gelegenheit, mit einem weiteren Modell zu experimentieren. Sie lautet: "Als TeamLead möchte ich, dass Consultants bei der Einhaltung der gesetzlich vorgeschriebenen Pausenzeiten unterstützt werden, um dem Arbeitszeitgesetz zu entsprechen." Natürlich bestürmt das Team den Product Owner mit Detailfragen, um "gesetzlich vorgeschriebene Pausenzeiten" und "unterstützen" genauer zu verstehen. Der Product Owner hat für das Refinement eine erste Story-Spezifikation vorbereitet, die in natürlicher Sprache gehalten ist und folgendermaßen beginnt:
"Bei einer Arbeitszeit von 6-9 Stunden muss das System sicherstellen, dass mindestens 30 Minuten Pause eingehalten werden. Bei einer Arbeitszeit von mehr als 9 Stunden muss das System sicherstellen, dass mindestens 45 Minuten Pause eingehalten werden (…)." Als das Team diese Informationen sieht, hebt das Teammitglied mit RE-Erfahrung die Hand und fragt zum einen, wie sichergestellt ist, dass alle denkbaren Konstellationen beschrieben werden, und zum anderen, wie genau das System jeweils reagieren bzw. das Gewünschte "sicherstellen" soll. Ein weiteres Teammitglied, das sich hauptsächlich um Testaufgaben kümmert, schließt sich an und ergänzt, dass das Thema aufgrund seiner komplexen Fachlogik doch förmlich nach einer Entscheidungstabelle schreien würde – und man dem PO bei ihrer Erstellung gerne behilflich sein könne.
Der PO nimmt die Unterstützung dankbar an, da er Entscheidungstabellen in seiner bisherigen Laufbahn nur "aus der Ferne" gesehen hat. Das Ergebnis einer ersten Pairing-Session ist in Abb. 7 zu sehen:
Das Feedback im Team ist erstaunlich: Alle stufen das Artefakt in der Sprint-Retrospektive als "besonders hilfreich" ein, weil es schnell umfassend Verständnis erzeugt hat. Aus Qualitäts- und Testsicht sind Entscheidungstabellen ohnehin ein Geschenk, weil sie sich viel einfacher auf Vollständigkeit und Widerspruchsfreiheit prüfen lassen als Freitext und weil sie den Einsatz von Testentwurfsmethoden erlauben (die zugehörigen abstrakten Testfälle lassen sich vom Team quasi mit freiem Auge aus der Tabelle ablesen). Und auch die Entwicklungstasks gehen schneller und mit weniger Korrekturen von der Hand. Wir halten fest:
- (M7) Modelle können helfen, Stories zu spezifizieren.
- (M8) Modelle sind eine Möglichkeit, komplexe Sachverhalte verständlich und testbar aufzubereiten.
Damit verlassen wir das Beispiel-Projekt.
Klarstellungen
Wenn ich über das Projekt berichte, erlebe ich einige typische Fehlschlüsse oder Missverständnisse rund um den beschriebenen Einsatz von Modellen. Um diese hier zu vermeiden, möchte ich vor allem drei Details betonen und vertiefen:
Nicht alles kann und soll modelliert werden!
Manche Anforderungen lassen sich am besten textuell festhalten (etwa nicht-funktionale Requirements, wobei Satzschablonen gute Dienste leisten können). Und niemals käme ich auf die Idee, vor Beginn des ersten Sprints zuerst ein modellbasiertes Fachkonzept o. ä. als vollständige (wie soll das gehen?) Spezifikation zu erstellen. Das wäre komplett un-agil! Indem wir stattdessen vor allem im Story-Refinement mit Modellen arbeiten, wenn (!) das Team zu dem Schluss kommt, dass das für diese konkret vorliegende Story hilfreich sein könnte, wächst die Spezifikation quasi iterativ mit, genau wie das Produkt. Betrachten Sie Modelle einfach als mögliche Zutat beim Kochen der jeweils nächsten Story. Und die Modelle, die sich dabei als hilfreich und wertstiftend erweisen, können Sie in einer "Helpful Artifact Map" sammeln [1].
Nicht jedes Modell muss sofort in einem Modellierungstool erstellt werden!
Beginnen Sie ruhig am Whiteboard und halten Sie hilfreiche Ergebnisse einfach als Foto fest. Aber fragen Sie sich bitte: Hätte es einen Wert, dieses Modell dauerhaft in einem geeigneten Werkzeug abzubilden, zu pflegen, zu versionieren, zu aktualisieren – oder Traces dorthin zu haben oder andere Artefakte daraus zu generieren oder… oder…? Wenn nein, genügt das Foto! Wenn aber doch, dann tätigen Sie den Invest. Denn: Vielleicht wird ein anderes Team einmal das Produkt übernehmen? Die Frage des Werkzeugeinsatzes ist nicht trivial [6] und muss besonders gründlich einer Aufwand-Nutzen-Abwägung unterzogen werden. Letztlich sind hier jeweils Einzelfallentscheidungen durch ein agiles Team zu treffen: Hilft ein konkretes Modell dem Team beim Verständnis, und entstünde Wert durch dauerhafte Pflege des Modells in einem Tool?
Ein Product Owner muss nicht modellieren können.
Dies ist eine Spezialisierung der Frage "Muss ein Product Owner ein ausgebildeter Requirements Engineer sein?" Antwort: Auch wenn es natürlich kein Schaden wäre – hier liegt kein "Muss" vor. Viel wichtiger ist die Bereitschaft im gesamten Team, sich RE- bzw. Modellierungswissen anzueignen, d. h. sich offen zu zeigen, Neues dazuzulernen und etwa in Pairings sein Wissen zu teilen. Erinnern Sie sich: Im Beispiel-Projekt habe ich ausdrücklich betont, dass ein Teammitglied mit RE- und Modellierungskenntnissen an Bord ist. Unter dieser Voraussetzung lässt sich das, was wir unter "agilem RE" verstehen, in einem Scrum-Projekt etablieren: Pro Story wird jeweils nur so viel RE und Modellierung betrieben, wie es für das Verständnis des Teams im nächsten Sprint und die Weiterentwicklung des Produkts hilfreich ist (Details in [1]).
Zusammenfassung
Mein Vorschlag: Probieren Sie’s aus! Experimentieren Sie! Ein agiles Vorgehen ist bestens dafür geeignet, neue Techniken anzuwenden und sie nach kritischer Bewertung entweder aufzugeben oder weiterzuentwickeln. Die Liste potenzieller Benefits aus einem wohldosierten Modellierungs-Einsatz, die ich in diesem Beitrag zusammengetragen habe, sieht insgesamt so aus:
- (M1) Grafische Modelle – hier: ein UseCase- und ein Kontext-Diagramm – helfen dem Team, das Endprodukt, seine Funktionen und seine Umgebung (Schnittstellen, Nutzerrollen) aus Außensicht besser zu verstehen.
- (M2) Modelle können initial immer leichtgewichtig am Whiteboard entstehen.
- (M3) Modelle können bei der Klärung von Begriffszusammenhängen und beim Design unterstützen.
- (M4) Modelle können dabei helfen, Stories zu finden (s. UseCase-Modell oder das Zerlegen von Ablaufdiagrammen).
- (M5) Modelle können beim Verstehen, beim Schätzen und beim "Schneiden" von Stories helfen.
- (M6) Modelle können dem Team bei Test- und Entwicklungsaufgaben helfen.
- (M7) Modelle können helfen, Stories zu spezifizieren.
- (M8) Modelle sind eine Möglichkeit, komplexe Sachverhalte verständlich und testbar aufzubereiten.
Vielleicht möchten Sie dem einen oder anderen Benefit in Ihrem eigenen IT-Projekt ja einmal eine Chance geben.
Danksagung
Alle Modelle und Abbildungen in diesem Artikel entstanden mit freundlicher und tatkräftiger Mitwirkung der MID GmbH, Nürnberg. Mein besonderer Dank hierfür geht an Michel Goumet, Florian Winter und André Boerner.
- Dr. C. Brandes: Verständnis durch story-spezifische Artefakte: Requirements Engineering in agilen Projekten, in: OBJEKTspektrum 03/2019
- M. Winter, T. Roßner, Dr. C. Brandes; H. Götz: Basiswissen Modellbasierter Test, 2. Auflage, dPunkt, 2016
- J. Patton: User Story Mapping, O’Reilly, 2015
- G. Adzic: Specification By Example, Manning Publishing, 2011
- Podcast Quality Heroes, Episode 14: Wie passen nicht-funktionale Requirements und technische Stories in ein agiles Backlog?
- A. Zündorf: Geh mir aus dem Weg! Was Modellierungswerkzeuge von Whiteboards lernen können, in: OBJEKTspektrum 01/2012
