Eine User Story verliert im Refinement ihre Begründung, wenn die zugehörige Nutzungsanforderung nicht verknüpft ist. Die Akzeptanzkriterien beschreiben dann, was die Funktion tut, und nicht, was Nutzende damit erreichen. Der Beitrag zeigt Schritt für Schritt, wie aus einer Nutzungsanforderung Akzeptanzkriterien entstehen, die im Test überprüfbar sind, und wo auf diesem Weg regelmäßig etwas verloren geht.
Voraussetzungen
Sie brauchen eine dokumentierte Nutzungsanforderung nach ISO 9241-210: einen Satz, der beschreibt, was Nutzende in einem bestimmten Nutzungskontext erreichen müssen, mit Verweis auf die Beobachtung, aus der er stammt. Beispiel: „Sachbearbeitende müssen einen Vorgang anlegen können, bevor alle Angaben vorliegen, und die Angaben nachtragen können, sobald sie bekannt sind." Quelle: Hospitationsprotokoll H-2, Aufgabe „Vorgang anlegen".
Dazu brauchen Sie den Nutzungskontext zu dieser Anforderung: Wer erledigt die Aufgabe, unter welchen Bedingungen, mit welchem Ergebnis. Ohne diesen Kontext entstehen Akzeptanzkriterien, die im Test nicht prüfbar sind, weil niemand weiß, mit wem und in welcher Situation getestet werden soll.
Schritt 1: Das Nutzungsziel aus der Anforderung herauslösen
Schreiben Sie in einem Satz auf, welches Ziel Nutzende mit der Anforderung erreichen und woran sie erkennen, dass sie es erreicht haben. Im Beispiel: Der Vorgang ist im System angelegt und lässt sich später vervollständigen, ohne dass Sachbearbeitende einen Platzhalter eintragen oder den Vorgang liegen lassen. Warum: Das Nutzungsziel ist der Maßstab für jedes Kriterium. Ein Kriterium, das nicht auf dieses Ziel einzahlt, beschreibt eine Funktion und kein Ergebnis. Ergebnis: ein Zielsatz mit erkennbarem Endzustand.
Schritt 2: Die Bedingungen aus dem Nutzungskontext übernehmen
Notieren Sie die Bedingungen, unter denen das Ziel erreicht werden muss: Nutzergruppe (erfahrene Sachbearbeitende und Neueinsteiger), Situation (Information liegt am Anfang nicht vor), Umgebung (Telefon parallel, Unterbrechungen). Diese Bedingungen stehen im Nutzungskontext und werden im Refinement meist weggelassen, weil sie keine Funktion beschreiben. Warum: Sie bestimmen, wie später getestet wird. Ein Kriterium, das nur für erfahrene Kräfte gilt, ist ein anderes als eines, das auch Neueinsteiger erfüllen müssen. Ergebnis: eine Liste der Bedingungen je Anforderung.
Schritt 3: Kriterien als prüfbare Aussagen formulieren
Formulieren Sie je Bedingung ein Kriterium, das eine Person im Test mit Ja oder Nein beantworten kann. Muster: „Eine Person aus [Nutzergruppe] kann in [Situation] [Handlung], und danach [erkennbarer Zustand]." Im Beispiel: „Eine Neueinsteigerin kann einen Vorgang anlegen, ohne das Feld X auszufüllen, und der Vorgang erscheint in ihrer Liste als offen." Und: „Eine Sachbearbeiterin kann das Feld X an einem offenen Vorgang nachtragen, und der Vorgang lässt sich danach abschließen." Warum: Kriterien wie „Feld X ist optional" beschreiben die Implementierung. Sie lassen sich im Code prüfen, sagen aber nichts darüber, ob Nutzende die Aufgabe erledigen können. Ergebnis: zwei bis fünf Kriterien je Anforderung, jedes mit Nutzergruppe, Situation, Handlung und Endzustand.
Schritt 4: Das Messverfahren zuordnen
Legen Sie je Kriterium fest, wie es geprüft wird: im Usability-Test mit Teilnehmenden aus der Nutzergruppe, in einem Review mit einer Person aus dem Fachbereich, oder automatisiert, wenn das Kriterium rein funktional ist. Kriterien mit Nutzergruppe und Situation brauchen den Test mit Menschen. Warum: Ein Kriterium ohne Messverfahren wird im Sprint-Review vom Team selbst abgehakt. Ergebnis: je Kriterium ein Verfahren und der Zeitpunkt, an dem es angewendet wird.
Schritt 5: Den Verweis in die Story eintragen
Tragen Sie in die Story den Verweis auf die Nutzungsanforderung und ihre Quelle ein, im Beschreibungsfeld oder in einem eigenen Feld, wenn das Ticketsystem eines hat. Warum: Wenn im Refinement ein Kriterium gestrichen oder geändert werden soll, führt der Verweis zur Beobachtung zurück. Die Frage lautet dann, ob die Beobachtung noch gilt, und nicht, ob das Kriterium jemandem zu aufwendig ist. Ergebnis: eine Story mit Kriterien, Messverfahren und Quelle.
Typische Verluste auf dem Weg
Aus unserer Arbeit in agilen Setups kennen wir vier Stellen, an denen Anforderungen ihre Begründung verlieren. Erstens beim Übergang vom Ziel zur Funktion: „Nutzende müssen X erreichen" wird zu „Es gibt einen Button für X". Zweitens beim Weglassen der Bedingungen: Die Nutzergruppe und die Situation fallen weg, und übrig bleibt ein Kriterium, das für den Entwickler am Testsystem erfüllt ist. Drittens beim Messverfahren: Der Usability-Test wird durch den Sprint-Review ersetzt, in dem das Team sich selbst die Funktion zeigt. Viertens beim Verweis: Die Story wird geteilt oder verschoben, und die Quelle bleibt in der alten Story zurück.
Ergebnis
Am Ende liegt je Nutzungsanforderung eine Story vor, deren Akzeptanzkriterien mit Nutzergruppe, Situation, Handlung und Endzustand formuliert sind, ein Messverfahren zugeordnet haben und auf die Beobachtung verweisen, aus der die Anforderung stammt. Im Test lässt sich jedes Kriterium mit Ja oder Nein beantworten. Im Refinement lässt sich jede Änderung an einem Kriterium auf die Frage zurückführen, ob die Beobachtung noch gilt.