Evil User Stories

Bild: Unsplash / Lukas Eggers - Lizenz

Eine der Gemeinsamkeiten praktisch aller agil aufgestellten Organisationen ist die Nutzerzentrierung. Die Anforderungen sind in der Regel aus der Sicht des Nutzers formuliert (so genannte User Stories), und die fertigen Ergebnisse werden zusammen mit ihm getestet und besprochen. Was bei all dem aber zu bedenken ist -  manchmal lassen Benutzer sich zu Aktionen hinreissen die sie besser unterlassen hätten, und von denen das System sie abhalten sollte. Lassen sich auch derartige "verhindernde Funktionen" als User Story formulieren?

Bevor wir darauf eingehen eine kurze Sinnfrage: wenn ein Nutzer eine bestimmte Aktion nunmal durchführen will, warum sollte man ihn davon abhalten? Weiss er nicht am besten was richtig für ihn ist? Die Antwort darauf: leider nicht immer, und ein wie es der Zufall will gibt es auch ein aktuelles Beispiel dafür. Um zu zeigen wie produktiv sie im Home Office war veröffentlichte eine niederländische Ministerin auf Twitter einen Screenshot von einer EU-Ministerrunde an der sie gerade teilnahm. Da dieser in seiner URL den Konferenzdienst und den Zugangscode anzeigte war es für jeden ihrer Twitter-Follower möglich ebenfalls an dem Meeting teilzunehmen. Und ein Journalist gönnte sich den Spass und machte genau das.

Dit was de oorspronkelijke foto die vanaf het account van minister Bijleveld werd gedeeld, met daarin de meeting-ID en vijf cijfers van de pincode.

Het was een zescijferige pincode. Ik joinde met de naam 'admin'. pic.twitter.com/Fztrbqm5FR

— Daniël Verlaan (@danielverlaan) November 20, 2020

Zurück zur Ausgangsfrage. Lassen sich User Story formulieren die zwar aus Nutzerperspektive geschrieben sind aber ein fahrlässiges Verhalten wie das der niederländischen Ministerin verhindern sollen? Natürlich geht das, es fühlt sich aber künstlich an. "Ich als Videokonferenz-Teilnehmer möchte daran gehindert werden Zugangsdaten zu veröffentlichen, damit kein Unbefugter teilnehmen kann" ist kein Satz oder Wunsch den ein echter Mensch jemals äussern würde.

Ein besserer Ansatz wäre es sich den Benutzer/User aus einer anderen Perspektive vorzustellen. In UX-Design und Software-Test gibt es den Typus des "Evil User", der sich dadurch auszeichnet, dass er Funktionen immer wieder so benutzt wie sie nicht gedacht sind und dadurch Fehlfunktionen und falsche Ergebnisse erzeugt. Wichtig ist dabei, dass er das (meistens) nicht aus bösem Willen tut sondern aus Unkenntnis und ohne zu wissen was er anrichtet - wie im Fall der oben genannten Ministerin.

Vom Evil User zur User Story ist es jetzt nur noch ein kurzer Sprung. "Ich als Videokonferenz-Teilnehmer möchte Screenshots mit allen sichtbaren Informationen veröffentlichen, damit jeder sehen kann was ich mache". Mit solchen Anforderungen in ein Refinement zu gehen kann wertvolle Diskussionen ermöglichen. Für den Fall dass jemand etwas Derartiges tut (verhindern kann man es nicht) welche Informationen sind dann öffentlich sichtbar? Welche davon sind sicherheitsrelevant? Und wie könnte man sie unkenntlich machen?

Aus derartigen Diskussionen können sich dann die Akzeptanzkriterien der Evil User Story ergeben, die in diesem Fall negativ formuliert sind, da sie ja das "bösartige" Nutzerverhalten eindämmen sollen. Angelehnt an den oben genannten Fall könnte etwa eines sein, dass weder auf der Website des Video-Calls noch in der URL Zugangsdaten sichtbar sein dürfen.

Als letztes noch ein Tip aus der Praxis: es macht Sinn die Evil User Stories im Backlog mit einer besonderen Kennzeichnung zu versehen. Wenn das nicht passiert besteht das Risiko, dass das Team vergessen hat, dass es sich bei einer älteren Story um eine zu verhindernde Aktion handelt und diese dann in der Weiterentwicklung nicht verhindert sondern erleichtert oder sogar erst ermöglicht. In solchen Fällen steckt eine feine Ironie: das Team ist dann der Evil User seines eigenen Prozesses.