Eine Persona lässt sich daran messen, ob sie eine anstehende Entscheidung auflöst oder offen lässt. Wir prüfen Personas deshalb an den nächsten Entscheidungen im Backlog. Personas, die keine davon verändern, werden überarbeitet oder gestrichen.
Ausgangslage
Ein Persona-Set wird meist am Ende einer Research-Phase abgenommen. Die Kriterien dabei sind Vollständigkeit, Lesbarkeit und Datengrundlage. Ob die Personas im Alltag etwas bewirken, zeigt sich erst später, und dann fehlt der Anlass, sie zu prüfen. Wir haben in der Nachbetrachtung von Projekten gesehen, dass Persona-Sets im Laufwerk liegen, ohne dass jemand sagen kann, welche Entscheidung sie beeinflusst haben. Wie häufig das vorkommt, haben wir nicht erhoben.
Eine Persona ist nach ISO 9241-210 Teil der Beschreibung des Nutzungskontexts, und der Nutzungskontext ist die Grundlage für Nutzungsanforderungen und Gestaltungsentscheidungen. Der Zweck einer Persona liegt in diesen Entscheidungen. Eine Persona, die keine Entscheidung verändert, erfüllt ihren Zweck nicht, unabhängig davon, wie gut sie erhoben ist.
Die Entscheidungen sammeln
Das Prüfverfahren beginnt im Backlog. Product Owner und Team sammeln die Entscheidungen, die in den nächsten Sprints anstehen: Reihenfolge von Schritten, Pflichtfelder, Standardwerte, Benennungen, Umfang eines Release, Priorität zwischen zwei Stories. Jede Entscheidung wird als Frage formuliert, die zwei oder mehr Antworten zulässt. „Sollen die Standardwerte beim Einrichten erklärt oder vorbelegt werden?" ist eine Entscheidung. „Das Einrichten verbessern" ist keine.
Wir beschränken die Liste auf Entscheidungen, die in absehbarer Zeit fallen. Eine Persona für Entscheidungen zu prüfen, die nie anstehen, sagt nichts. Die Liste entsteht in einer kurzen Runde mit Product Owner und Team; wer sie erstellt, notiert je Entscheidung auch, wer sie am Ende trifft, weil diese Person die Persona später im Zweifel befragen wird.
Jede Persona gegen jede Entscheidung halten
Für jede Entscheidung wird jede Persona geöffnet, und die Frage lautet: Enthält die Karte eine Zeile, die eine der Antworten stützt oder ausschließt? Das Ergebnis wird in einer Tabelle festgehalten, Entscheidungen in den Zeilen, Personas in den Spalten. In jeder Zelle steht die Zeile der Karte, die die Entscheidung berührt, oder ein Strich.
Die Tabelle zeigt nach dem Durchgang, wo Einträge fehlen und wo sie sich widersprechen. Entscheidungen ohne Eintrag in einer Zeile: Dafür liefert das Persona-Set keine Grundlage, und die Entscheidung fällt nach anderen Kriterien. Personas ohne Eintrag in einer Spalte: Diese Persona berührt keine anstehende Entscheidung. Und Zellen, in denen zwei Personas gegenläufige Antworten stützen: Das sind die Stellen, an denen die Persona ihren Wert zeigt, weil ohne sie die Gegenläufigkeit unsichtbar bliebe.
Personas überarbeiten oder streichen
Eine Persona ohne Eintrag hat zwei mögliche Ursachen. Entweder fehlen auf der Karte die Merkmale, die für die anstehenden Entscheidungen relevant wären; dann wird die Karte überarbeitet, mit Blick auf das Material, das dazu vorliegt. Oder die Gruppe, die die Persona vertritt, ist für die anstehenden Entscheidungen ohne Bedeutung; dann wird die Persona gestrichen oder mit einer anderen zusammengelegt. Beides wird dokumentiert, mit Datum und Begründung.
Das Streichen fällt Teams schwer, weil in der Persona Arbeit steckt. Die Arbeit ist im Material und in der Codetabelle erhalten. Was gestrichen wird, ist eine Karte, die im Refinement Aufmerksamkeit kostet und nichts verändert.
Das Verfahren wiederholen
Die Prüfung wird wiederholt, wenn das Backlog eine neue Phase erreicht, etwa vor einem Release-Schnitt oder nach einer Feldphase. Die Tabelle aus dem vorigen Durchgang bleibt erhalten, und über mehrere Durchgänge wird sichtbar, welche Personas regelmäßig Entscheidungen berühren und welche nie.
Grenzen
Das Verfahren prüft die Wirkung einer Persona auf Entscheidungen, nicht ihre Datengrundlage. Eine Persona kann Entscheidungen verändern und trotzdem auf Annahmen beruhen; dann verändert sie sie in die falsche Richtung. Beide Prüfungen gehören zusammen. Außerdem hängt das Ergebnis von der Qualität der Entscheidungsliste ab. Ein Backlog, das nur aus technischen Aufgaben besteht, liefert Entscheidungen, die keine Persona berührt, und das sagt dann mehr über das Backlog als über die Personas.
Wie oft Personas in Kundenteams nach der Übergabe geöffnet werden und welche Entscheidungen sie verändern, haben wir bisher nicht erhoben. Der Beitrag beschreibt das Vorgehen. Häufigkeiten nennt er nicht.
Was danach vorliegt
Eine Tabelle aus Entscheidungen und Personas, ein überarbeitetes oder verkleinertes Persona-Set mit dokumentierten Änderungen, und eine Liste von Entscheidungen, für die keine Grundlage vorliegt. Die letzte Liste ist der Erhebungsplan für die nächste Feldphase. Das Team weiß, welche Personas es im Refinement öffnen sollte, und kann das Verfahren ohne uns wiederholen.
