Fehler passieren nicht auf dem Happy Path – sondern auf dem Problem Path.

Gerade junge oder wachsende agile Teams konzentrieren sich in der Anforderungsanalyse häufig auf den idealen Ablauf. Doch was passiert, wenn Nutzende den vorgesehenen Pfad nicht verstehen, Systeme ausfallen, Rollen fehlen oder Edge Cases auftreten? Genau dann entstehen die berüchtigten „blinden Flecken“ – sie kosten später Zeit, Zufriedenheit, Akzeptanz, Geld und Nerven.

In dieser praxisnahen Session lernen die Teilnehmenden, wie sie mit sogenannten Problem Personas spielerisch genau diese Fehlerpfade sichtbar machen – bevor sie Realität werden.

Was sind Problem Personas?
Problem Personas sind gezielt gestaltete Charaktere, die typische Muster von Fehlverhalten, Missverständnissen oder systembedingten Schwächen verkörpern. Sie reichen von Chaos Claus, dem IT-Admin, der heimlich alles verstellt und dann in die Mittagspause verschwindet, bis zu Norbert Newby, einem unsicheren Nutzer, der aus Versehen ganze Prozesse zum Erliegen bringt.

Die Personas basieren auf echten Erfahrungen aus agilen Softwareprojekten, psychologischen Verhaltensmustern – und auf AI-generierten Inhalten, die aus realen Fehlerquellen und Szenarien gewonnen wurden.

Das Kartenset für Teams – und ein AI-Modus für Einzelne
Das Herzstück der Methode ist ein physisches und digitales Kartenset, das Teams gemeinsam in Refinements, Pre-Mortems oder Architektur-Workshops einsetzen können. Dabei schlüpfen Teilnehmende aktiv in die Rolle einer Persona und „challengen“ gezielt einzelne Backlog Items oder UI-Flows aus Sicht eines Problemnutzers oder eines risikobehafteten Systemverhaltens.

Für Einzelpersonen oder Remote-Sessions gibt es eine ergänzende AI-gestützte Version:
Ein LLM (Large Language Model) analysiert bestehende Anforderungen und schlägt automatisch passende Problem Personas vor – inklusive potenzieller Edge Cases, Nutzerfehler und Szenarien.

Demo: Von Problem Persona zu BDD-Szenario

In der Session zeigen wir live, wie sich aus einer Problem Persona mit Hilfe eines LLMs ein konkretes BDD-Szenario (Behaviour Driven Development) generieren lässt. So wird aus einem vagen Risiko ein testbares Beispiel – und aus blinden Flecken konkrete Requirements.