Ein Priorisierungsraster ist nur so gut wie die Daten in seinen Spalten. Das Raster in diesem Beitrag erfasst je Backlog-Eintrag drei Angaben: wie häufig die zugehörige Aufgabe vorkommt, welche Folgen ein Fehler in dieser Aufgabe hat und wie weit die zugehörige Nutzungsanforderung heute erfüllt ist. Der Beitrag zeigt die Anwendung an einem anonymisierten Beispiel und benennt, welche Daten dafür vorliegen müssen.
Voraussetzungen
Das Raster funktioniert, wenn drei Dinge vorliegen. Erstens ein Aufgabenmodell aus dem Nutzungskontext: eine Liste der Aufgaben, die Nutzende mit dem Produkt erledigen, mit Quelle (Kontextinterview, Hospitation, Usability-Test). Zweitens dokumentierte Nutzungsanforderungen nach ISO 9241-210, jede mit Verweis auf die Beobachtung, aus der sie stammt. Drittens ein Backlog, in dem jeder Eintrag einer Aufgabe zugeordnet ist. Wie diese Zuordnung entsteht, beschreibt der Beitrag „Priorisierung beginnt bei der Aufgabe der Nutzenden".
Fehlt eine der drei Voraussetzungen, füllt das Team die Spalten mit Schätzungen. Das Raster wird dann zur Abstimmung im Meeting, mit anderem Layout.
Schritt 1: Die Spalten festlegen
Das Raster hat je Backlog-Eintrag eine Zeile und drei Bewertungsspalten.
Häufigkeit der Aufgabe: Wie oft erledigen Nutzende die Aufgabe, zu der der Eintrag gehört? Die Stufen kommen aus der Erhebung, zum Beispiel „mehrmals täglich", „wöchentlich", „zum Monatsabschluss", „selten". Die Stufen sind Beobachtungskategorien, keine Zahlen.
Folgen eines Fehlers: Was passiert, wenn die Aufgabe scheitert oder ein falsches Ergebnis liefert? Auch hier stammen die Stufen aus dem Nutzungskontext: „Nutzende wiederholen den Schritt", „Nutzende weichen auf ein anderes Werkzeug aus", „falsche Daten gehen an Dritte", „Aufgabe bleibt unerledigt".
Erfüllungsgrad der Nutzungsanforderung: Wie weit unterstützt das Produkt die Anforderung heute? „Erfüllt", „teilweise erfüllt", „nicht erfüllt", jeweils mit Verweis auf den Befund, der das zeigt.
Warum diese drei: Häufigkeit und Fehlerfolgen beschreiben die Bedeutung der Aufgabe für Nutzende, der Erfüllungsgrad beschreibt den Abstand zwischen Anforderung und Produkt. Das Ergebnis dieses Schritts ist eine leere Tabelle mit definierten Stufen je Spalte.
Schritt 2: Die Spalten aus der Erhebung füllen
Für jeden Eintrag trägt das Team die drei Werte ein und daneben die Quelle: den Interviewcode, das Hospitationsprotokoll, den Testbefund. Ein Wert ohne Quelle bekommt die Markierung „Annahme". Warum: Das Raster soll später im Konfliktfall zeigen, worauf eine Bewertung beruht. Ohne Quelle ist die Zeile im Streitfall wertlos. Ergebnis: eine Tabelle, in der jede Bewertung entweder auf eine Beobachtung zeigt oder als Annahme markiert ist.
Schritt 3: Lesen, nicht rechnen
Die Versuchung ist groß, die drei Spalten zu Punkten zu verrechnen und nach der Summe zu sortieren. Wir raten davon ab. Ein Eintrag mit „mehrmals täglich", „falsche Daten gehen an Dritte" und „nicht erfüllt" ist offensichtlich vordringlich. Interessant sind die uneindeutigen Fälle, und die lassen sich mit einer Summe nicht entscheiden, weil die Stufen keine Zahlen sind. Das Team liest das Raster stattdessen in einer festen Reihenfolge: zuerst alle Einträge mit schweren Fehlerfolgen und nicht erfüllter Anforderung, dann alle mit hoher Häufigkeit und teilweiser Erfüllung, dann der Rest. Ergebnis: eine begründete Reihenfolge, bei der jede Position auf Werte im Raster zeigt.
Schritt 4: Annahmen in Erhebungsaufträge verwandeln
Alle Zeilen, in denen eine Spalte als „Annahme" markiert ist, werden gesammelt. Für die Einträge, die nach Schritt 3 weit oben stehen, lohnt sich eine kurze Erhebung, bevor gebaut wird: ein Kontextinterview, eine Hospitation, ein Blick in vorhandene Nutzungsdaten. Warum: Eine Annahme in einer hoch priorisierten Zeile ist ein Risiko für ein ganzes Release. Ergebnis: eine Liste offener Fragen mit zugeordneter Methode.
Beispiel, anonymisiert
Ein Finanzdienstleister betreibt ein Portal für Firmenkunden. Im Backlog liegt der Eintrag „Report als Datei exportieren". Aus den Hospitationen ist dokumentiert: Die Aufgabe „Monatsauswertung an das Meldewesen liefern" fällt zum Monatsabschluss an. Ein Fehler bedeutet, dass falsche Zahlen an Dritte gehen. Die Nutzungsanforderung „Nutzende müssen die Auswertung ohne Nachbearbeitung weitergeben können" ist nicht erfüllt; im Hospitationsprotokoll steht, dass Nutzende die Werte in eigene Tabellen übertragen. Die Zeile lautet: zum Monatsabschluss, falsche Daten an Dritte, nicht erfüllt, Quelle Hospitation H-3.
Daneben liegt der Eintrag „Farbschema für Diagramme". Aufgabe: „Bestand auf einen Blick prüfen", mehrmals täglich. Fehlerfolge: Nutzende schauen genauer hin. Anforderung teilweise erfüllt. Der Export steht vor dem Farbschema, obwohl beide im Fachbereich gefordert wurden und das Farbschema weniger Aufwand kostet.
Typische Fehler
Stufen als Zahlen behandeln und summieren, siehe Schritt 3. Spalten ohne Quelle füllen und das später vergessen. Die Häufigkeit aus der Sicht des Fachbereichs statt aus der Beobachtung eintragen; beide Sichten unterscheiden sich regelmäßig. Das Raster einmal füllen und nie aktualisieren; nach jedem Usability-Test ändern sich Erfüllungsgrade.
Ergebnis
Nach den vier Schritten liegt ein Raster vor, das jede Priorisierungsentscheidung auf drei Werte mit Quelle zurückführt. Im Refinement beantwortet es die Frage, warum ein Eintrag oben steht. Im Konfliktgespräch mit einem Fachbereich zeigt es, welche Beobachtung hinter einer Bewertung liegt und wo eine Annahme noch zu prüfen ist.