Die Sprint-Planung beginnt, und für das Thema des Sprints liegen keine Nutzungsanforderungen vor. Das Team schätzt Stories auf Annahmen oder wartet. Die vier Aktivitäten nach ISO 9241-210, also Nutzungskontext verstehen, Nutzungsanforderungen festlegen, Gestaltungslösungen entwerfen und evaluieren, sind unabhängig vom Vorgehensmodell definiert. In einem Sprint-Takt müssen Sie sie so verteilen, dass das Entwicklungsteam zu Sprintbeginn Erkenntnisse vorfindet. Diese Anleitung beschreibt, welche Research- und Evaluationsschritte in welchem Sprint liegen und welche Aktivität dem Sprint vorauslaufen muss.
Voraussetzungen
Ihr Team arbeitet in Sprints fester Länge mit Planung, Review und Retrospektive. Es gibt eine Person oder Rolle, die Research und Evaluation verantwortet, im Team oder als Zulieferung. Ein Nutzungskontext liegt in einer ersten Fassung vor, also eine Beschreibung der Nutzenden, ihrer Aufgaben, Arbeitsmittel und Umgebung. Fehlt diese Fassung, beginnt der Zyklus mit einem Vorlauf für die Kontexterhebung. Der liegt außerhalb des Sprint-Takts und wird hier nicht behandelt.
Schritt 1: Die vier Aktivitäten auf zwei Spuren verteilen
Was: Teilen Sie die Aktivitäten in eine Research-Spur (Nutzungskontext verstehen, Nutzungsanforderungen festlegen) und eine Entwicklungs-Spur (Gestaltungslösungen entwerfen, umsetzen). Die Evaluation verbindet beide: Sie prüft die Lösung der Entwicklungs-Spur gegen die Anforderungen der Research-Spur.
Warum: Die beiden Spuren haben unterschiedliche Rhythmen. Research braucht Rekrutierung und Feldzugang und lässt sich nicht in Tagen takten. Entwicklung braucht zu Sprintbeginn fertige Anforderungen. In einem gemeinsamen Takt fehlt zu Sprintbeginn entweder die Anforderung, oder die Rekrutierung ist noch nicht abgeschlossen.
Ergebnis: eine Übersicht, in der jede Aktivität einer Spur zugeordnet ist.
Schritt 2: Die Research-Spur einen Sprint vorlaufen lassen
Was: Die Research-Spur arbeitet an dem Thema, das im nächsten Sprint entwickelt wird. Während das Team Sprint n baut, erheben und formulieren wir die Anforderungen für Sprint n+1.
Warum: So liegen zur Planung von Sprint n+1 Nutzungsanforderungen mit Erfolgskriterium vor, und das Team plant gegen ein erhobenes Erfordernis. Ohne Vorlauf werden Anforderungen in der Planung improvisiert, oder das Team wartet.
Legen Sie den Vorlauf je Thema fest, wenn es in die Roadmap aufgenommen wird. Ein Sprint ist aus unseren Projekten die Untergrenze. Themen mit Feldzugang, Rekrutierung oder Betriebsratsabstimmung brauchen mehr, und das ist zum Zeitpunkt der Roadmap-Planung bekannt.
Der Einwand, dass der Vorlauf die Roadmap um einen Sprint nach hinten schiebt, trifft für das erste Thema zu. Danach läuft die Research-Spur parallel, und der Versatz bleibt konstant.
Ergebnis: eine Research-Planung, die der Sprint-Planung um mindestens einen Sprint vorausgeht.
Schritt 3: Die Übergabe an der Sprint-Planung festlegen
Was: Legen Sie fest, welche Artefakte an der Sprint-Planung vorliegen: die Nutzungsanforderungen für das Sprint-Thema, das Kontextszenario, aus dem sie stammen, und das Erfolgskriterium je Anforderung. Legen Sie die Anforderungen in der Planung neben die User Stories und verknüpfen Sie beide.
Warum: Die Planung ist der Punkt, an dem Umfang und Priorität entschieden werden. Was dort nicht auf dem Tisch liegt, wirkt auf die Entscheidung nicht.
Ergebnis: ein Planungsergebnis, in dem jede Story auf eine Nutzungsanforderung verweist oder als Story ohne erhobenes Erfordernis gekennzeichnet ist.
Schritt 4: Die Evaluation in den Sprint einbauen
Was: Planen Sie je Sprint eine Evaluation des Ergebnisses aus dem vorherigen Sprint. Das kann ein moderierter Usability-Test mit wenigen Testpersonen sein, eine Inspektion gegen die Dialoggrundsätze der ISO 9241-110 oder ein Test am Prototyp, je nach Reifegrad des Ergebnisses. Die Evaluation prüft gegen die Erfolgskriterien der Anforderungen.
Warum: Ohne Evaluation im Takt endet die Schleife nach dem Entwurf. Die Rückkopplung kommt dann erst beim Release, wenn Änderungen teuer sind.
Ergebnis: je Sprint ein Erfüllungsstatus je Anforderung und eine Liste von Kontextbeobachtungen für die Research-Spur.
Schritt 5: Den Rückfluss organisieren
Was: Die Ergebnisse der Evaluation gehen in zwei Richtungen. Nicht erfüllte Anforderungen gehen als Überarbeitung in einen der nächsten Sprints. Kontextbeobachtungen gehen an die Research-Spur und aktualisieren die Kontextbeschreibung.
Warum: Der Zyklus ist erst geschlossen, wenn die Evaluation den Nutzungskontext für die nächste Schleife verändert. Sonst arbeitet die Research-Spur mit einem Kontext weiter, den die Tests überholt haben.
Ergebnis: ein Ablauf, in dem jede Evaluation Einträge in der Kontextbeschreibung und im Backlog erzeugt.
Typische Fehler
Aus eigenen Projekten kennen wir vier Muster. Research läuft im selben Sprint wie die Entwicklung des Themas, und das Team wartet oder baut auf Annahmen. Die Research-Spur arbeitet an Themen, die nicht auf der Roadmap stehen, und ihre Ergebnisse kommen an keiner Planung an. Die Evaluation wird bei Zeitdruck als Erstes gestrichen, weil sie kein Feature liefert; in einem unserer Projekte war der Sprint-Review danach die einzige Rückmeldung, und die stammte vom Team selbst. Und der Rückfluss in die Kontextbeschreibung fehlt, so dass jede Schleife mit dem Wissensstand der ersten startet. Seitdem steht die Evaluation bei uns als eigener Eintrag im Sprint-Backlog, mit demselben Status wie eine Story.
Was am Ende vorliegt
Ein Sprint-Takt, in dem die Research-Spur einen Sprint vorausläuft, die Sprint-Planung Nutzungsanforderungen mit Kriterien vorfindet, jeder Sprint eine Evaluation enthält und die Ergebnisse in Backlog und Kontextbeschreibung zurückfließen. Das Team entscheidet in der Planung auf Grundlage von Erhobenem und erfährt in der Evaluation, ob die Lösung funktioniert hat.