Der Weg zu einer guten Priorisierung ist weit. Manchmal führt er über MoSCoW

Fragt man Anforderer nach „Was genau brauchst du? Welche Inhalte müssen gebaut werden?“, dann kann die Antwort schnell mit einem „Alles“ abgetan werden.
Bei einem größeren Featurewunsch „Alles“ liefern zu wollen, kann schnell zu einem langwierigen Prozess werden. Gelingt es einem Team zudem nicht, iterative Zwischenschritte zu liefern, verkommt die Entwicklung schnell zu einem Wasserfallprozess ohne Feedbackschleifen.
Henrik Kniberg bringt es in seinem Video „Agile Product Ownership in a Nutshell“ schön auf den Punkt. Frei zitiert: „Entweder wir liefern dir alle Featurewünsche, die du hast bis Zeitpunkt X, oder die wichtigen Features in der Hälfte der Zeit. Die anderen Features können wir dann immer noch liefern, wenn sie dann noch wichtig sind.“

Es gilt also gemeinsam mit dem Kunden oder Anforderungssteller herauszufinden, welche Teile einer Anforderung entscheidend sind und welche „nur“ die Kirsche auf der Sahnetorte darstellen.

Priorisierung mit MoSCoW

Ein einfaches Werkzeug, hierfür ist MoSCoW. Das Acronym hilft, sich 4 Ebenen der Anforderungswichtigkeit zu merken:

M (Must Criteria) –

Die Muss-Kriterien, welche den entscheidenden Mehrwert der Anforderung enthalten. Ein großer Fokus auf MVP (Minimal Viable Product) oder das Pareto Prinzip (20% der Anforderungen erzeugen 80% des Nutzermehrwertes) kann hier helfen die Aufwände zu minimieren, die auf dieses Prioritätslevel anfallen.

o

S (Should Criteria) –

Sollte-Kriterien beschreiben all die Wünsche, die schon da sein sollten. Es darf gern auch schmerzhaft sein, Kriterien hier einzuordnen. Sei es, dass der Nutzer einzelne Dinge weiterhin manuell machen muss oder Fremdsysteme eingebunden werden müssen. Sobald der Fokus nicht mehr auf den Muss-Kriterien liegt (etwa weil diese bereits erledigt sind), kann sich ein Entwicklungsteam immer noch an die Sollte Kriterien machen.

C (Could Criteria) –

Hier finden sich all die Aufwände, welche optional sind, also umgesetzt werden „könnten“. Optionale Anforderungen sollten nicht prinzipiell abgetan werden nach dem Motto „Dafür haben wir eh keine Zeit“, sondern genug Beachtung und wirtschaftliche Betrachtung erfahren, um den Kunden zu begeistern. Ich empfehle hierfür sich etwas mit dem „Kano-Modell“ auseinander zu setzen.

o

W (Won’t Criteria) –

Kann man schon zu Beginn aus technisch, fachlich oder wirtschaftlicher Sicht ausschließen Dinge zu entwickeln, kann man sich eine nähere Betrachtung oder Product Backlog Refinement dieser Anforderungen direkt sparen und die gewonnene Zeit direkt in die nächsten Kundenwünsche stecken.

Das zehnte Prinzip hinter dem Agilen Manifest (Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell) perfekt zu leben ist wohl die Königdisziplin eines jeden Product Owners.

Hat euer Team auch Herausforderungen, nicht getane Arbeit zu maximieren? Sicher hilft ein kurzes Telefonat mit einem Emendator hier weiter!

Weitere spannende Beiträge findet ihr hier!