Gib mir fünf (User Stories!) Automatisierte Perspektivwechsel mit dem User Story-Assistenten

Fast jeder Product Owner kennt das Problem mit den User Stories. Es ist schwierig sich in die Rollen einer Person zu versetzen, die die Anwendung anders nutzen würde als man selbst. Manche Annahmen sind möglicherweise auch zu offensichtlich, um sie ausdrücklich zu erwähnen. Übersehene Perspektiven werden Probleme verursachen oder Potenziale verschenken. Schauen wir uns an, wie KI helfen kann diese Herausforderung von Product Ownern etwas leichter und vielfältiger zu machen.

Der Perspektivwechsel als Schlüsselmoment beim Schreiben von User Stories

Für Menschen gibt es kaum eine größere kognitive Herausforderung als eine andere Perspektive einzunehmen. Insbesondere beim Schreiben von User Stories ist es wichtig, möglichst alle Stakeholder mit ihren Anforderungen an eine Software abzudecken und dabei den tatsächlichen Bedarf zu treffen. In der agilen Software Entwicklung kommen User Stories zum Einsatz, um die notwendigen Perspektiven zu explizieren. Das gelingt durch eine konsistente Struktur, die wie folgt aussieht:

Als [Rolle] möchte ich [Funktion verwenden], um [etwas zu erreichen].

Was eine gute User Story ausmacht, können Sie in unserem Beitrag über User Stories nachlesen. Aber wie kann man methodisch dabei unterstützen, dass die richtigen Stories erst einmal entstehen?

Besonders schwierig wird es mit dem Perspektivwechsel dann, wenn die einzunehmende Perspektive nicht den eigenen Ansichten oder Bedürfnissen entspricht. Diese absolut menschliche Eigenschaft kann dazu führen, dass einige Nutzungsperspektiven vernachlässigt werden (Stichwort Accessibility, i8n) oder im schlimmsten Fall sogar ein (nicht immer offensichtliches) Missbrauchspotenzial entsteht, wenn niemand bei der Planung die Perspektive von Angreifer:innen und Trollen einnimmt.

Das führt uns zu der Idee, kreative Perspektivwechsel mit NLP-Technologien zu fördern. Können wir moderne Transformer-basierte NLP-Modelle wie GPT-3 und unsere Erfahrung zum guten Umgang mit User-Stories so zusammenbringen, dass es Product Ownern hilft, die relevanten Perspektiven zu finden und einzunehmen?

Challenge: "Gib mir 5 User-Stories zu Deinem System. Ich ergänze die Liste mit Ideen, an die vielleicht noch niemand gedacht hat."

Diese KI-Modelle haben durch das "Lesen" im freien Internet gelernt, kurze Texte sinnvoll fortzusetzen - mit unterschiedlichsten Perspektiven und diese Vielfalt machen wir uns gezielt zu nutze.

Challenge 1: User Stories vermehren am Beispiel der Corona Warn App (CWA)

Wir haben uns an dieser Stelle für ein Anwendungsbeispiel in Form einer Corona Warn App entschieden. Dafür gibt es folgende Gründe:

1. Die App ist inkl. User-Stories auf Github verfügbar.
2. Diese Form von Anwendung ist sehr neu und bisher einmalig, demnach ist die Datengrundlage, auf die KI zugreifen kann vergleichsweise klein.
3. Eine App dieser Art ist sehr spezifisch, sie ist als Lösung für ein Problem gedacht und funktioniert nur in einem eng definierten Kontext.

Dementsprechend führen wir hier direkt eine Art "Härtetest" für das NLP-Model durch.

Hier sind einige User Stories für die Corona Warn App des RKI:

Mit modernen NLP-Modellen kann man das Konzept Few-Shot-Learning umsetzen: Wir zeigen dem Modell wenige Beispiele. Es generiert weitere.

Preisfrage: Welche dieser 5 User Stories ist von den Product Ownern des RKI geschrieben und welche sind von einem NLP-Modell generiert?
Lösung: Story 2 und Story 5 sind automatisch generiert. Wäre es Ihnen aufgefallen?

Es ist erst einmal beeindruckend, dass die Unterscheidung schwer fällt, aber sind die neuen Fälle nützlich?

• Der generierte Fall 2 ergänzt die Perspektive eines:einer Nutzer:in, der:die ggf. ein Smartphone nicht persönlich, sondern gemeinsam mit anderen Personen nutzt. Testergebnisse und Begegnungen sind personenbezogene Daten. Die sind auch vor Co-Nutzer:innen zu schützen. Idealerweise kann so ein Vorschlag ausreichen, um weitere Ideen anzustoßen. Ich selbst bin Co-Nutzer mit meinen Kindern – dass Eltern für Ihre Kinder ein Testergebnis abfragen möchten, war lange ein Stolperstein. Wer keine Kinder hat, kommt vielleicht nicht selbst auf diese Anforderung. Version 2.5 der CWA hat diesen Bedarf tatsächlich adressiert – eine nützliche Perspektive.
• Der generierte Fall 5 ergänzt die Perspektive eines:einer Nutzer:in, der:die keine oder keine zuverlässige Internetverbindung hat. Das kommt in Deutschland generell vor, kann aber auch daran liegen, dass man bspw. den Flugzeug-Modus nicht verlassen hat. Das führt im Zweifel dazu, dass mich ein Testergebnis oder eine Warnung nicht rechtzeitig erreicht. Es ist plausibel dafür einen Hinweis zu geben.

Nicht alle generierten Fälle sind nützlich. Bei unserem ersten Experiment dieser Art sind aber zwei nützliche, neue Perspektiven identifiziert worden. Das ist besonders beeindruckend bei einer Produktspezifikation, die A) schon ein hohes Qualitätsniveau und mehrere Perspektiven hat und B) mit Fachbegriffen und Situationen umgeht, die so spezifisch sind, dass sie vor 2 Jahren noch für menschliche Leser:innen abstrakt und schwer nachvollziehbar gewesen wären.

Challenge 2: Die Sicht der "Bad Guys" ergänzen lassen

Im obigen Beispiel haben wir nur die bestehenden Stories ergänzt und damit eher zufällig mehr vom potenziellen Projekt-Scope ausgeleuchtet. Darüber hinaus können wir auch versuchen, unser Erfahrungswissen gezielt mit einfließen zu lassen: Bspw. dass es sich oft lohnt, die Sicht einer bösartigen Nutzerin oder eines Hackers nachzuvollziehen. Das Einnehmen der Angreifer-Perspektive soll es den Entwickler:innen erleichtern Exploits zu verhindern und Missbrauchspotenzial auszuschließen. Dieses Optionen für Missbrauch lassen sich gut in Anti-Stories abbilden, die es dann zu verhindern gilt.

Für die CWA haben sich in unserem ersten Experiment folgende Anti-Stories zu den User-Stories des RKI ableiten lassen:

Anhand der generierten Sätze zeigt sich, dass das Modell das Prinzip einer Anti Story umsetzen kann. Die Ergebnisse zeigen Fälle auf, die dem Nutzen der App erheblich schaden könnten, falls nicht entsprechende Maßnahmen zur Prävention ergriffen werden. Dabei zielen die User Stories wie gewünscht sowohl auf technische Angriffe (1, 2), als auch auf missbräuchliche Nutzung ab (3, 4, 5).

Besonders erschreckend ist Anti Story Nr. 4: Diese verfolgt letztlich den Gedankengang, eine erkrankte Person, die sich einigermaßen sicher geschwächt und in Quarantäne (allein) zuhause aufhält, zu überfallen. Menschen mit intaktem Wertekompass werden von allein sicher nicht auf diese Idee kommen. Für die Konzeption der App begründen Szenarien wie dieses anschaulich die Entscheidung, dezentral und weitestgehend ohne personenbezogene Daten zu arbeiten, um Rückschlüsse auf die Identität der Nutzer:innen auszuschließen.

Künstliche Intelligenz hilft beim Ablegen der "Scheuklappen"

Mit diesem beunruhigenden Zwischenergebnissen haben wir uns gefragt, an welchen Stellen eine Betriebsblindheit bei der Konzeption von User-Stories ggf. noch eine Rolle spielt und wir mit Ansätzen dieser Art darauf reagieren können.

1. User Stories ergänzen: Mehr vom Lösungsraum explorieren.
2. Einzelne Perspektiven und insb. die Sicht der "Bad Guys" gezielt einnehmen.
3. Anforderungen werden übersehen, weil sie ggf. zu offensichtlich scheinen, um explizit erwähnt zu werden. Hierzu können wir Preconditions und implizite Annahmen (mit bestimmten Perspektiven) ableiten.
4. Eine Story lässt immer viel Spielraum offen. Den könnten wir verkleinern, indem wir Testfälle und Erwartungen ableiten.
5. Viele Teams explizieren ihre Ansprüche an User-Stories in einer Definition-of-Ready, blicken aber im Einzelfall unter Zeitdruck darüber hinweg. Ggf. lassen diese sich mit NLP-Mitteln automatisch einfordern?

Die oben genannten Scheuklappen sind alle sehr menschlicher Natur und immer zu erwarten. Sie mit maschineller Hilfe abzulegen liegt nahe.

Interessant?

Welches der Probleme ist für Sie wichtig? Probieren wir es mit Ihren 5 User-Stories aus? Wir freuen uns über Ihre Anfrage!

Was machen wir daraus?

Wir nutzen die NLP-Modelle intern als Kreativitäts-Booster in viadee-Projekten. Aktuell entsteht ein passender Online-Service dazu. Nutzen sie gern das obige Kontaktformular, um als Teil der Beta-Phase davon zu profitieren.

Ebenfalls interessiert uns Ihre Meinung sehr:

• Welche der 5 Scheuklappen soll höchste Priorität haben?
• Wie möchten Sie mit einem Kreativitäts-Booster für User-Stories arbeiten?
• Braucht es eine Integration in Jira oder Confluence? Ist der User-Story Assistent im UI ein "User", der Kommentare hinterlässt oder etwas völlig anderes?
• Woran machen Sie den Nutzen eines Kreativitäts-Boosters für User-Stories fest?

Besonders über den letzten Punkt denke ich gerade nach. Für diese Art von KI-Anwendungen gibt es eben kein offensichtliches Kriterium wie eine Trefferquote. Kreativität von Menschen und ihren Arbeitsergebnissen zu messen ist ja ebenfalls methodisch schwierig. Ein Team des Georgia Institute of Technology hat in diesem Sommer hier den Kreis geschlossen und ein KI-basiertes Verfahren veröffentlicht, um menschliche (verbale) Kreativität zu messen (hier ausprobieren). Etwas Vergleichbares wäre auch für ein Gemisch menschlicher und maschinell ergänzter User Stories gut vorstellbar.

Das Potential hinter Transformer-basierten NLP-Modellen ist riesig. Die Nutzung als "Gedankenstütze" in der Softwareplanung ist nur ein erster Schritt in die Richtung automatisierter Unterstützung bei Software-Konzepten. Auch automatisch generierte Dokumentationen, Code-Kommentare, SQL-Abfragen oder FAQs sind denkbar.

Müssen wir uns vor dieser Technologie fürchten? Nur, wenn wir uns nicht damit beschäftigen. Sprechen wir darüber.