Die XP-Community hatte vor etwa zehn Jahren die Idee, User Stories zu benutzten, um die Essenz einer Funktionalität aus der Sicht des Anwenders aufzuschreiben.

Zu Erinnerung:

Als User-Rolle
möchte ich eine Funktionalität
so dass ich den folgenden Nutzen habe. [1]

Eine super Idee, die dann von Mike Cohn aufgegriffen und durch sein Buch „User Stories applied“ populär gemacht wurde. Die Idee war so einfach, dass sie die damals gängigen Use Cases als Analysetool sofort überholte. Das Tool ist aber so einfach wie schwierig. Funktionalität aus Anwender-Sicht zu beschreiben, fällt vielen sehr schwer. Noch spannender ist zu beobachten, dass es tausende User Stories gibt, die im folgenden Format formuliert werden:

Als User möchte ich XX

Also wird zum einen einfach aus User-Rolle = User und die Frage nach dem “Wozu” wird oft weggelassen.

Echte Menschen für echte Rollen – die Persona

Heute möchte ich kurz über den User reden. Es ist wichtig zu sehen, dass User-Rolle gemeint war, nicht User. Es geht darum, dass sich der Product Owner und das Team eine echte Anwenderrolle überlegen und mit dieser arbeiten. Das Konzept der User-Rolle ist hier aber offenbar nicht griffig genug. Daher schlage ich vor, das Konzept der User-Rolle aus den User Stories zu streichen und durch das Konzept der Persona zu ersetzen. Personas sind am lebenden Menschen orientierte, imaginierte Personen, die unsere Applikationen, unsere Anwendungen, unsere Produkte benutzen.

Eine noch schönere und ausführlichere Beschreibung einer Persona findet ihr auf dieser Website, zusammen mit der folgenden Beschreibung, was eine Persona ist:

“Personas are archetypal users of an intranet or website that represent the needs of larger groups of users, in terms of their goals and personal characteristics. They act as ‘stand-ins’ for real users and help guide decisions about functionality and design. Personas identify the user motivations, expectations and goals responsible for driving online behaviour, and bring users to life by giving them names, personalities and often a photo.
Although personas are fictitious, they are based on knowledge of real users. Some form of user research is conducted before they are written to ensure they represent end users rather than the opinion of the person writing the personas.“

Wir machen also aus der Rolle Administrator zum Beispiel: Hans Müller, 35 Jahre, IT-Fachmann, lebt in München, fährt morgens mit der U-Bahn zur Arbeit. Er hat zwei Kinder, ist Studienabbrecher und faszinierter Science Fiction Fan. Er liebt es, mit seinen Kinder Lego zu spielen.

Diese Person ist aber erforscht. Das heißt, wir reden mit einigen Admins, finden heraus, wie die wirklich leben, wie sie unsere Applikation tatsächlich nutzen werden. Hat man mit seinem Team diese Personas identifiziert – und davon gibt es natürlich einige, ihr könnt auch mehr als eine Persona pro User-Rolle definieren -, dann kann man anschließend die User-Rolle durch die Persona ersetzen. Auf diese Weise entsteht eine wesentlich lebendigere Vorstellung davon, für wen man die Applikation erzeugt, als durch die User-Rolle. Zumal dann per se klar wird, dass es nicht nur einen User gibt.

Viel Spaß beim Erstellen von Personas!

[1] Boris Gloger: Scrum – Produkte zuverlässig und schnell entwickeln, Hanser, 3. Auflage, 2010

Avatar of Boris Gloger
„Mut“ ist jener Wert von Scrum, mit dem sich Boris Gloger am stärksten identifiziert. Er hat in seinem eigenen Leben keine Angst vor radikalen Entscheidungen und vor dem Glauben an eine Idee. Für kein Geld der Welt würde er sich Regeln unterwerfen, die keinen Sinn machen. Er glaubt an Scrum, weil es nicht nur bessere Produkte, sondern auch eine bessere und menschlichere Arbeitswelt schaffen kann.