Priorisieren Sie noch oder MoSCoW‘en Sie schon?
MoSCoW: „Must“, „Should“, „Could“ und „Won’t“.
„Bitte priorisieren Sie diese Liste“
A: „Womit fangen wir an?“
B: „Nehmen wir die Liste und priorisieren die Punkte...!“
Wie oft haben wir diesen Dialog schon gehört? Wie oft haben wir dem Fachbereich oder das Management aufgefordert: „Bitte priorisieren Sie diese Liste“. Das Ergebnis ist immer ähnlich: 95% der Punkte haben „Prio 1“ oder „A“. Und wenn man sich auf eine sinnvollere Reihung der Anforderungen einigt, kommt sicher kurz danach jemand und setzte seine Punkte über alle anderen ganz nach oben.
Gewinnen wir dabei einen Mehrwert an Information um unsere Arbeit oder die eines Teams zu steuern? Wissen wir jetzt, womit wir anfangen? Nein, eigentlich nicht.
Priorisierung - und dann?
Also: wie geht’s besser? Überlegen wir uns ein paar Begriffe neben dem der „Priorisierung“.
Zuerst gibt es die „Wichtigkeit“: Perfekt! Das Wichtigste zuerst! Aber auch hier stellt sich bald die Frage: Ist „A“ wirklich wichtiger als „B“? Jeder, den Sie fragen, wird Ihnen eine andere Antwort geben. Und dann gibt es ja noch die Dringlichkeit: Arbeiten, die zu einem bestimmten Zeitpunkt erledigt sein müssen, können in der Liste plötzlich ganz nach oben rutschen, weil der Termin naht und noch viel zu tun ist. Und das, obwohl sie als niedrig priorisiert und bei der Einschätzung noch gar nicht dringend waren.
Bedeutet das nun, dass wir Dinge zuerst erledigen die vielleicht gar nicht so wichtig sind!?!
Es muss also eindeutigere Kriterien geben, die man zur Entscheidung heranziehen kann. Wie wäre es, wenn man den Aufwand, also die Menge der Arbeit, die hinter jedem der Punkte auf der Liste steht, betrachtet? Also starten wir mit dem Punkt, der am meisten Arbeit macht. Wir wollen ja zeitgerecht fertig werden. Oder sollten wir doch die „Low hanging fruits“ zuerst ernten und „quick win’s“ einfahren?
Irgendwann werden wir es schaffen und einigen uns auf eine „Reihung“: also eine eindeutige Reihenfolge, in der die einzelnen Punkte zu erledigen sind. Schön und perfekt! Jetzt wissen wir womit wir beginnen.
Was haben wir gewonnen? Wir haben eine sortierte aber statische Liste, nach der wir unsere Arbeit oder ein Projekt ausrichten und steuern. Eine Liste, die uns die Planung und Steuerung teilweise aus der Hand genommen hat, deren Sortierung in der Regel von Dritten erstellt wird und die uns steuert: klassisches Linienmanagement!
Was lehrt uns hingegen die Agilität? Wie können wir mit solchen starren und statischen Listen leben, wenn Agilität doch bedeutet:
- Veränderung
- Selbst organisierende Teams
- Iteratives Arbeiten
Agile PM verwendet dazu die Methode „MoSCoW“. „MoSCoW“ ist (auch außerhalb der Zeiten der Fußball-WM) kein Verweis auf die russische Hauptstadt, sondern ein Akronym, gebildet aus den Worten „Must“, „Should“, „Could“ und „Won’t“.
Must
Mit „Must“ werden jene zu erstellende Artefakte klassifiziert, die in jedem Fall zu liefern sind: Dinge, die nicht verhandelbar sind, Anforderungen die essentiell sind und deren (auch teilweise) „Nicht-Erreichung“ ein Scheitern des Projektes zur Folge hat. Wobei „Must“ ein Akronym für „Minimal Usable SubseT“ ist, also die Minimalanforderung an eine Lösung darstellt.
Should
Die „Should“-Anforderungen haben für das Projekt hohe Relevanz, sind wichtig, aber nicht erfolgskritisch. Solche Anforderungen nicht um zu erfüllen ist in der Regel schmerzhaft, aber es gibt wahrscheinlich einen Workaround, eine ineffiziente aber (zeitlich begrenzt) lebbare Alternativlösung
Could
Die als „Could“ klassifizierten Anforderungen sind die Wünsche, die „Nice to Have’s“, und sind weniger wichtiger als die „Should’s“. Auch sind die Auswirkungen bei der Nicht-Erbringung deutlich geringer.
Won't
Und was dann noch übrigbleibt, das wird nicht umgesetzt. Ganz einfach: die „Won’ts“.
Fazit
Damit dieses Konzept funktioniert, sind zwei Voraussetzungen notwendig:
Einerseits muss das Team die Business-Needs und langfristigen Ziele kennen. Andererseits muss diese Bewertung öfter durchgeführt werden: Einmal, wenn eine erste Requirementsliste für das Projekt erstellt wird und dann zyklisch im Rahmen der z.B. Sprintcommits bzw. auch im Rahmen von zyklischen „Backlog-Groomings“ (gemeinsame Betrachtung des Gesamt-Backlogs).
Das gleiche gilt nicht nur für das Gesamtprojekt, sondern auch für die jeweilige Iteration und Timebox. Items, die in einer Timebox als „Should“ eingestuft sind, können dann z.B. in der nächsten Timebox schon ein „Must“ sein. Für die Zuteilung der einzelnen Punkte der Liste in eine Timebox gilt als Regel: Maximal 60% Must und bis zu 20% Could-Items. Damit sollte das Team in der Lage sein, trotz aller Unschärfen in der Schätzung des Aufwandes, die Must’s zu schaffen. Denn das Ziel ist, am Ende jeder Iteration eine brauchbare, funktionsfähige Lösung zu haben. Auch, wenn diese „nur“ das Minimal Usable SubseT der Lösung darstellt.
