it's OK to say NO, - a Priori (un-) mögliches mit Konsequenz und der Spalt zwischen Mi-NO-rität, Majorität und Priorität

Schritt 1 – DU (du nicht) bist (jetzt) dabei

In einem ersten Schritt, und hier empfehle ich ein ordentliches Augenmass und Bauchgefühl, geht es darum, aus einer Menge ALLER Backlog-Items NUR diejenigen zu wählen, die anschliessend in einem zweiten Schritt in eine Reihenfolge (welche ist jetzt erstmal egal) gebracht werden sollen. Kurz: es geht (etwas) um die Haufentheorie, deren zusätzliches Ordnungselement Zeit, also “jetzt als nächstes” zwei Stapel erzeugt. Der eine Stapel, sagen wir links, wird anschliessend priorisiert, der andere (rechts), sorgfältig zur Seite gelegt und durchläuft dann später wieder genau diesen Prozess (links, rechts).

In dieser Übung ist schon der erste Scherge des agilen Optimierungskults versteckt: ALLES was jetzt hier und nachfolgend beschrieben wird, sollte linear, also nacheinander durchgeführt werden. Eine versuchte Priorisierung, parallel „abgefackelt“ – weil im Moment gerade dafür keine Zeit ist -, wird scheitern! Konkret: Ihnen später (schmerzhaft) auf die Füße fallen. Einfache Begründung: Wenn Sie nicht bewusst (und sei es nur für sich selbst) begründen, wo sie sich FÜR und bei was DAGEGEN entschieden haben – Ich weiß, wovon ich spreche …

Fangen wir an! Eine Auswahl. Folgende Methoden eigenen sich dafür ganz gut:

Steine, Kiesel, Sand

Diese Übung hat ein einfaches Ziel: Alle ‚Items‘ (Vorhaben) in drei einfache Cluster einzuteilen, das äussere Kriterium der Bemessung ist dimensioniert und UN-veränderbar, das innere Kriterium ist Größe kombiniert mit Relevanz, also das, was rein passt. Es geht hier um das Prinzip:

  • Große, wichtige Blöcke, die wirklich was bewegen, wenn sie umgesetzt sind (z.B. ein neues, zusätzliches Add-On, was ein bestehendes Produkt ergänzt. Ein elementares Feature, was ein bestehendes Produkt für alle Kunden deutlich aufwertet, …) → Steine
  • mittelgroß sind Themen, die für einen Teil der Kunden/Nutzer von Bedeutung sind und das Produkt eher ergänzen – aber nicht alle Kunden werden das sofort nutzen (z.B. eine neue Anmelde-Methode, eine alternative Darstellung, …) → Kiesel
  • Alles, was nicht Steine oder Kiesel ist, könnten kleine Themen sein, die man „mal so mit machen“ kann (Bugfixes, Beseitigung techn. Schuld, Code-Optimierungen) → das ist also Sand. Hinweis: Stellen Sie, und sei es nur emotional, fest, dass es noch nicht mal Sand ist, könnte es sein, das dieses ‘Item’ (Vorhaben) hier gar nicht hingehört.
Große Steine, kleine Steine und Sand – der passt immer dazwischen

Seien Sie dann in allen 3 Phasen auch so konsequent, sagen „Nein, Du nicht!“ und sortieren es aus. Weil der Mensch, auch ein PO, evolutorisch bedingt ein Jäger und Sammler ist, passiert was? Die ‚Items‘ (Vorhaben) werden aufgehoben (im schlimmsten Fall wird ein eigenes Backlog erstellt oder diese Einträge bleiben im Backlog – ganz unten – aber sichtbar – und gammeln vor sich hin. Die Schmuddelecke des Backlogs – wollen Sie diese jeden Tag sehen?

Um die versprochene Geschwindigkeit in der Priorisierung zu halten, braucht es keine wirkliche Schätzung mit dem Team. Es geht im ersten Wurf eher um die Wichtung der Themen. Gut beraten ist, für die weitere Priorisierung den Sand erst mal beiseite zu legen und sich auf auf die Ebene der Steine und Kiesel zu begeben. Für den Sand planen Sie ein kleines Zeitkontingent, sagen wir 10-20% ein und priorisieren den dann auf kurzfristiger Basis agil und dynamisch hinzu. Die Weisheit dieses Modells liegt darin, wenn erst die Steine und der Kiesel geordnet sind (also für den Kopf nur 2 Größen) kommt den Sand, die kleinste Größe, immer irgendwie dazwischen.

Fill the Themes

Dieser Begriff, kurz auch nur „Themes“ wird in der Entwicklung von Produkten, meist in Verbindung mit Roadmaps verwendet. Sie entscheiden sich, für eine bestimmte Zeit (-Abschnitt) an einem strategisch relevanten Ziel zu arbeiten. Das Kriterium der Bemessung ist auf der Meta-Ebene zu finden und ist eine Kombination aus Relevanz und Gewicht. Dieses Ziel sollte idealerweise in Form einer Anforderung oder Problems aus der Sicht der Kunden formuliert sein. Eine derartige „Sortierbox“ hilft dabei.

Bunte Sortierbox(en) für Kleinteile oder Schrauben – oder ‚Items‘

Ein Beispiel: „Wir werden in den kommenden [6 Wochen] die Zeit, die ein Kunde braucht um [einen konkreten Prozess] zu durchlaufen, drastisch reduzieren. Die angestrebte Zeit liegt bei [4h pro Kunde].“ Die Angaben in Klammer sind nur als Muster zu verstehen.

Das Bild mit den Kästchen wird das als Prinzip verdeutlichen: Jedes Thema, als eines, was sich abgrenzt, ist eines von den dargestellten Boxen. Die Farben können die Wichtigkeit oder Dringlichkeit darstellen. Viel wichtiger ist, dass die (obige) Anordnung nicht starr ist, sondern je nach Anforderung beweglich bleibt. (Das Gegenbeispiel wäre ein Setzkasten …) Haben Sie Ihre Themen erstellt (Boxen beschriftet) und mit alle Themen waagerecht, senkrecht und ggfls. systemisch mit notwendigen Ansprechpartnern abgestimmt, können Sie aus der langen Liste an ‚Items‘ (Vorhaben) diejenigen auswählen, die, bitte genau (später dazu mehr …) auf dieses Thema einzahlen.

Alles was nicht einzahlt, legen Sie weg! Konkret: Alle anderen Items legen Sie bitte beiseite. Wirklich und Gemäß: Du bist (jetzt und in diesem Thema) dabei – und Du nicht!

Mo.S.Co.W.

Die MoSCoW Methode ist weder kompliziert noch aufwändig. Sie ist ein Akronym aus 4 Buchstaben und schafft erst mal eine solide Grundlage. Das Kriterium der Bemessung ist Wichtigkeit und Auswirkung und wie so viele Methoden ist MoSCoW im Prinzip ziemlich einfach. Und richtig angewandt auch sehr wirksam … WENN man diese konsequent nutzt. Das kleine o interpretiere ich in meinem Ansatz als Gedankenstütze für OUT, also weg.

Priorisieren nach Gewichtung

Bei dieser Methode legt man zuerst eine Art Meilenstein fest. Dieser ist weniger ein ‚Item‘ (Vorhaben), sondern ein Status, was dann eine Nummer größer ist. Ich bitte jetzt hier, sich von Volumen oder physikalische Größe zu trennen – Komplexität ist ein gut gefühltes Attribut, was „Zeit“ und „Business Impact (also Relevanz)“ beinhaltet. Und wenn es gar nicht hilft (mit der Vorstellung) – Im vorherigen „Themen“-Bild wäre das eine der größeren Boxen, z.B. die grüne, nur vielleicht doppelt so hoch in der Bauart. Dieser Meilen-„Stein“ (siehe oben: Steine, Kies, Sand) kann ein festes Datum sein, ein bestimmtes Release oder eine erweiterte Version, auf die viele Kunden warten. Anschließend teilt man seine Userstories oder Backlogitems in 4 Gruppen für diese Relevanz ein:

  • M – MUST: unbedingt erforderlich (Attribute wie essentiell, unverhandelbar, notwendig, …)
  • S – SHOULD: sollte gemacht werden, wenn M-Anforderungen vorab erfüllt werden können
  • C – COULD: kann umgesetzt werden, wenn die Erfüllung von höherwertigen Anforderungen nicht beeinträchtigt wird – kurzum: wenn alles andere erledigt ist.
  • W – WON’T: wird diesmal nicht umgesetzt, ist aber für die Zukunft vorgemerkt.
  • das kleine „o“ kommt vom Kopitzke®: OUT, das ist das ‚Item‘ (Vorhaben), was bei genauer Betrachtung keine der obigen 4 Anforderungen erfüllt – Sie werden sich freuen, wenn Sie erkennen: „DU = gar nicht!“

Um die Kriterien nochmal zu unterscheiden:

MUST Kriterien: Würde eins der Kriterien auch nur teilweise wegfallen, führt das unweigerlich zum Scheitern des Projekts. MUST ist ebenfalls ein Akronym für Minimal Usable SubseT – und steht für Minimalanforderung.
SHOULD Kriterien: Obwohl SHOULD-Anforderungen nicht erfolgskritisch für die Lösung sind, haben sie eine hohe Relevanz, sollten berücksichtigt werden und können oft über verschiedene Wege umgesetzt werden.
COULD Kriterien: Haben eine geringere Relevanz als MUST und SHOULD, werden oft als „nice to have“ bezeichnet und erst dann beplant, wenn noch Kapazitäten (siehe obiges Bild, unten) frei sind. Anmerkung: Oft können ein paar einfache COULD’s einen messbaren Mehrwert erzeugen!
WON’T Kriterien: ‚Will NOT‘ yet. Die ‚Items‘ (Vorhaben) sind existent, nur nicht jetzt. Also: NOT. Das ist einer der größten Vorteile von MoSCoW – es zeigt die Klassifizierung als WON’T, dass die Anforderung nicht in den Abfall, sondern ‚aufgehoben für später‘ gehört. Sie ist zeitlich unkritisch und bleibt existent, z.B. in einer eigenen Liste (was Sie nicht permanent sehen, fokussiert auf das andere.)

Eine gute WON’T-Liste bewirkt drei entscheidende Effekte:

  • Kein Benutzer muss für das Aufnehmen von Anforderungen kämpfen.
  • Werden zukünftige Erforderlichkeiten überlegt, werden auch aktuelle neu überdacht.
  • Wenn die Designer die zukünftige Planung (aus dieser Liste) sehen, können Sie bei der aktuellen Umsetzung (jetzt) schon Vorkehrungen zur späteren Implementierung treffen.

Der Vorteil der Mo.S.Co.W- Priorisierung liegt darin, dass klar und nachvollziehbar definiert werden kann, welche Anforderungen zeitkritisch sind UND den größten Business Impact haben. Er werden funktionale wie auch nicht funktionale Anforderungen berücksichtigt.


©2019 Kopitzke ® Pro | Impressum | Datenschutzerklärung

Log in with your credentials

Forgot your details?

Send this to a friend