Ob ein Team im Sprint oder im Phasenmodell arbeitet, verändert die Taktung der Prüfungen, nicht ihre Inhalte. Die vier Artefakte nach ISO 9241-210 müssen in beiden Arbeitsweisen an einem Entscheidungspunkt vorliegen. Der Beitrag zeigt, wo diese Punkte in beiden Modellen liegen und an welchen Stellen die Übertragung schwierig wird.
Ausgangslage
Prozessbeschreibungen für Nutzerzentrierung sind häufig in Phasen gedacht: erst Kontext, dann Anforderungen, dann Konzept, dann Evaluation, je mit Abnahme. Teams, die in Sprints arbeiten, finden diese Punkte in ihrem Ablauf nicht wieder und schließen daraus, dass die Artefakte für sie nicht gelten. Umgekehrt halten Organisationen im Phasenmodell die Artefakte für einmalige Lieferungen und wiederholen sie nicht, wenn sich der Kontext ändert.
ISO 9241-210 beschreibt die vier Aktivitäten als iterativ und lässt offen, in welchem Vorgehensmodell sie stattfinden. Die Entscheidungspunkte gelten deshalb in beiden Modellen; die Frage ist, wo sie im jeweiligen Takt liegen.
Entscheidungspunkte im Phasenmodell
Im Phasenmodell liegen die Punkte an den Phasenübergängen. Die Nutzungskontextbeschreibung liegt vor der Projektfreigabe, die Nutzungsanforderungen vor der Konzeptabnahme, die Gestaltungslösung vor der Implementierungsentscheidung, das Evaluationsergebnis vor dem Release. Die Zuordnung ist einfach, weil die Gates bereits existieren und eine abnehmende Rolle haben.
Die Schwierigkeit liegt in der Wiederholung. Ändert sich der Nutzungskontext während der Implementierung, sieht das Modell keine Rückkehr zur Kontextbeschreibung vor. Und die Evaluation liegt so spät, dass Befunde mit hohem Schweregrad kaum noch in das Release einfließen. Die Übertragung braucht deshalb zwei Ergänzungen: eine Evaluation an Prototypen vor der Implementierungsentscheidung und eine Regel, welche Änderungen eine Aktualisierung von Kontextbeschreibung und Anforderungen auslösen.
Entscheidungspunkte im Sprint
Im Sprint gibt es keine Phasen, aber Entscheidungen in festem Takt: die Aufnahme eines Themas ins Backlog, das Refinement, die Sprint-Planung, das Sprint-Review, die Release-Entscheidung. Die Artefakte lassen sich diesen Entscheidungen zuordnen. Die Nutzungskontextbeschreibung gehört zur Aufnahme eines Themas ins Backlog: Ein Epic ohne beschriebenen Kontext wird nicht priorisiert. Die Nutzungsanforderungen gehören zum Refinement: Eine Story, die keine Nutzungsanforderung referenziert, ist nicht bereit für die Planung. Die Gestaltungslösung gehört zur Sprint-Planung: Was implementiert wird, hat ein Konzept, das gegen die Anforderungen geprüft wurde. Das Evaluationsergebnis gehört zum Sprint-Review oder zur Release-Entscheidung: Was ausgeliefert wird, wurde mit Nutzenden geprüft.
Die Taktung ist enger, die Artefakte sind kleiner. Eine Kontextbeschreibung für ein Epic hat einen anderen Umfang als eine für ein Produkt. Der Inhalt bleibt derselbe: Wer nutzt, welche Aufgaben, welche Bedingungen, welche Quelle.
Was in beiden Modellen gleich bleibt
In beiden Fällen gilt: je Artefakt eine Mindestanforderung, eine erstellende und eine abnehmende Rolle, eine Folge bei Fehlen. In beiden Fällen ist der Reifegrad-KPI derselbe, der Anteil der Vorhaben oder Stories, die den Entscheidungspunkt mit Artefakt passiert haben. Und in beiden Fällen entscheidet eine benannte Rolle, ob ein Punkt mit Ausnahme passiert werden darf, und dokumentiert das.
Wo die Übertragung schwierig wird
Beim Umfang: Im Sprint muss die Evaluation in den Takt passen; ein Usability-Test, der länger dauert als ein Sprint, kommt zu spät. Die Lösung liegt in kleineren, häufigeren Evaluationen und in einer Rekrutierung, die nicht je Test neu beginnt. Das ist Gegenstand von Research Operations.
Bei der Verantwortung: Im Phasenmodell nimmt eine benannte Rolle das Artefakt ab. Im Sprint ist der Product Owner meist Ersteller und Abnehmer zugleich, und dann fehlt die Prüfung. Die Lösung ist eine Rolle außerhalb des Teams, die an Review und Release-Entscheidung teilnimmt, etwa eine UX-Verantwortliche über mehrere Teams.
Bei gemischten Organisationen: Häufig arbeitet die Entwicklung agil, und die Freigabe folgt einem Phasenmodell mit Lenkungsausschuss. Dann liegen die kleinen Entscheidungspunkte im Sprint und die großen im Phasenmodell, und beide müssen dieselben Artefakte referenzieren. Die Kontextbeschreibung aus dem Backlog ist die Grundlage für die Projektfreigabe, das Evaluationsergebnis aus dem Sprint-Review die Grundlage für die Release-Entscheidung im Ausschuss. Wer die Verbindung nicht herstellt, erhebt die Artefakte doppelt oder an keiner der beiden Stellen.
Grenzen
Der Beitrag beschreibt die Zuordnung, keine Vorlage für ein bestimmtes Framework. Wie die Entscheidungspunkte in Scrum oder in einem hausinternen Modell heißen, ist je Organisation zu prüfen. Dokumentierte Werte darüber, wie häufig Artefakte in agilen gegenüber klassischen Vorhaben vorliegen, haben wir nicht erhoben.
Was danach vorliegt
Eine Zuordnung der vier Artefakte zu den Entscheidungspunkten des eigenen Vorgehensmodells, mit Mindestanforderung, Rollen und Folge bei Fehlen. Für gemischte Organisationen dazu die Verbindung zwischen den Punkten im Sprint und den Gates der Freigabe.