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

Walkin Skeleton

Das „Walking Skeleton“ ist die einfachste Umsetzung eines kompletten Funktionsbereiches bzw. Geschäftsprozesses. „Walking“ bezieht sich auf den Umstand, daß diese erste Umsetzung bereits „lauffähig“ ist. Der Begriff „Skeleton“ umschreibt, daß nicht alle Funktionen, die möglich sind, berücksichtigt werden. Das „Fleisch“ am Knochen fehlt also noch. (siehe Bild …, deutlich mehr links als rechts … nach Iterationen.)

es läuft schon (links) – und mit mehr Fleisch (rechts) besser

Einige Unternehmen nennen diese erste Umsetzung auch „Proof of Concept“. Wichtig bei dieser Selektionsmethode ist es, alle Funktionen auszuwählen, die dazu beitragen, dass man einen Prozess von Beginn bis Ende funktional durchspielen kann. Nicht schön, aber derart, dass diese Funktion zeigt, wofür sie gebaut wurde. Also z.B. vom Startseitenaufruf, über die Produktsuche, die Produktauswahl, den Warenkorb, die Bezahlung bis hin zum finalen Checkout. Alles ist dann nicht hübsch und vielleicht auch noch nicht richtig ‚fluffig‘ oder responsiv, aber es „geht“.

Schritt 2 – Reihenfolge (Ihr seid dabei – Wie und wann?)

Mit etwas Übung werden die hier vorgestellten Methoden als erster Schritt schnell in den Arbeitsalltag eingehen. Die Anzahl an ‚Items‘ (Vorhaben) – bevorzugter Wohnort im Backlog oben (so 30-50 ist ganz gut) ist gesetzt und Sie wissen, welche Themen es nun gegeneinander zu priorisieren gilt. Hier ist jetzt der semantische Unterschied und auch die Arbeitshilfe als solches:

Die Bezugsgröße ist jetzt primär nur noch das benachbarte ‚Item‘ (Vorhaben) für die kommende Arbeit, nicht mehr alle ‚Items‘ (Vorhaben). Das reduziert deutlich das Geplärr und die Ablenkung im Kopf, weil einfach ⅔ schon aussortiert sind. Jetzt können Sie mit diesen Methoden eine echte Reihenfolge mit der harten Regel: („there aren’t 2 prio 1 topics!!“) in ihr Backlog bringen:

Business Value Based

Die gängige Literatur schreibt und fordert, daß Backlogs immer priorisiert sein sollen. Sind sie aber sehr selten. In vielen Unternehmen werden Business Ziele gar nicht so klar kommuniziert, dass der PO danach priorisieren könnte. Was fatal ist. Noch fataler ist, dass die ausgerufenen Business Ziele (gerne oben), so weit weg oder nebulös sind, dass der PO an der Basis (unten) im „Nebel der (Un-)wissenheit“ komplett ohne Sicht agieren muss. Das wird „fahren auf Sicht“ genannt. Macht das Spass? Nein. Ist aber notwendig.

In einer Priorisierung ist es in dieser Konstellation durchaus sinnvoll, mal wieder nach Business Cases, Forecast Dokumenten, weniger KPI Scorecards (ggfls. auch hartnäckig) zu fragen. Was glauben das Management oder die Sales-Kollegen, bringt den Kunden wirklich einen Mehrwert? Für was wären die Kunden bereit zu bezahlen? Aber auch Entwickler haben hier ein Wort mitzureden: Welche Teile der ausgerufenen Entwicklung machen unproportional viel Arbeit und sind damit aus deren Sichtweise nicht wirtschaftlich? Sehen Sie mal genau in oder zu manuellen Prozessen im Unternehmen. Kann das automatisiert werden? Und wenn Ja, welcher Business Value wird damit gestiftet? (Manchmal mehr als vermutet …)

Einfach erfolgt hier die Priorisierung z.B. mit dem „buy a feature„-Spiel. (Es gibt noch andere …) Der PO sammelt zuerst alle Features, Anforderungen, Kundenwünsche etc. und notiert diese auf Karten. Dann laden Sie als PO das Team und alle Stakeholder (Sales, Customer Support, Marketing, …) zu einem Meeting ein – Eins m.M.n. der Meetings, wie wirklich wichtig sind (im Gegensatz zu Meetings, die Unsinn sind. Jeder Teilnehmer erhält einen fiktiven Geldbetrag, sagen wir 500 Euro und kann dann damit Features „kaufen“. Jeder darf seinen Geldbetrag frei aufteilen. Anschließend wird addiert, welche Features am teuersten erkauft wurden. Diese haben den größten Business Value. Und: Wenn ein Beteiligter sein Geld ausgegeben hat, ist er nicht mehr solvent. Ganz einfach und wie im richtigen Leben.

Was würden Sie als END-Kunde (als PO) auch kaufen? Sinnige Frage …

Das kann in dieser Runde schnell gehen – und zeigt möglicherweise tiefliegende Defekte in den Strukturen der Organisation oder der Gesamtplanung, die der PO hätte ausbaden müssen. Jetzt nicht mehr, denn die Fakten (also die Bedürfnisse wie Erwartungshaltungen, incl. auftretender „Verzerrungen“, auch die pyramidal direktiven) liegen für jeden sichtbar auf dem Tisch – und die Person PO befindet sich etwas entspannter daneben. So einfach können unbestreitbare Wirklichkeiten erzeugt werden.

Relative Weight Methode

Die Priorisierung nach relativer Gewichtung eignet sich für umfangreichere Product Backlogs und ist aus verschiedenen Gründen sehr hilfreich. Ein elementarer Vorteil ist, dass hier neben anderen Techniken mit internen Expertenwissen gearbeitet wird. In nur 8 einfachen Schritten führt diese Methode zu einer validen Priorisierung. Der Erfinder, Karl Wiegers, legte dabei die Relation aller zu bewertenden Items in sich fest, heisst, nachdem mit meinem Ansatz hier alles, was nicht betrachtet werden soll, schon mal weg ist, bleibt die zu bewertende Menge an ‚Items‘, (Vorhaben) überschaubar. Es werden diese Items nach den vier Faktoren Vorteil, Strafe, Risiko und Kosten jeweils mit einer Zahl von 1 – 9 bewertet. Der methodische Vorteil sind:

• Es fließen mehrere Kriterien in die Beurteilung zur Wichtigkeit eines Eintrages ein
• Alle Kriterien werden systemisch gleich bewertet
• Unterschiedliche Einträge (Epics, Stories, Themes, NFRs) können bewertet werden
• Jeder Eintrag erhält eine Prioritätszahl, aus der sich die Rangfolge ergibt

Wie wird vorgegangen?

Die 4 Faktoren „Vorteil, Strafe, Risiko und Kosten“ werden nüchtern mit Zahlen zwischen 1-9 bewertet. Die Fragen 1 und 2 bilden ein Paar und sollten vom PO mit Kunden und Stakeholdern ermittelt werden. Die Fragen 3 und 4, zeichnet das Team verantwortlich. Welche Fragen? Diese hier:

  1. Vorteil: Wie groß ist der Vorteil (oder Wert), wenn das Feature geliefert wird? (Kundennutzen)
  2. Strafe: Wie groß fällt die Strafe aus, wenn das Feature nicht geliefert wird? (Kundenreaktion)
  3. Risiko: Wie hoch ist das Risiko, sind Abhängigkeiten zu anderen Teams oder der Technik? (Interner Aufwand, Widerstand)
  4. Kosten: Wie hoch sind die Kosten für die Umsetzung? (Kosten, Wirtschaftlichkeit)

Während Vorteil und Strafe sehr schön aus Business-Sicht bewertet werden können, fliesst durch das Team die Sicht der Expterten (das ist eine ganz andere!) ein. Ist ein Feature komplex in der Umsetzung mit vielen Abhängigkeiten zu anderen Systemen, wird das Risiko höher bewertet und  drückt sich (hoffentlich) das auch in einer höheren Aufwandsschätzung des Teams aus. Eine hohe Estimation (Aufwand) bedeutet oft längere Zeiten bei der Umsetzung mit höheren Kosten.

Ein anderes Beispiel mit geringem Business Vorteil aber potentiell hoher Strafe wären der Impressumslink oder die Datenschutzerklärung auf Websites. Geld verdienen Sie damit nicht – aber teure Ansprüche gegen Sie können verhindert oder abgewehrt werden.

Wie wird die Prio-Zahl nun ermittelt?

Die Prioritätszahl lässt sich mathematisch sehr leicht ermitteln: Bilden Sie die Summen aus Vorteil + Strafe = Zähler und Risiko + Kosten = Nenner (Bruch-Rechnen) und teilen diese. Sie sehen am Beispiel oben, wie die Priorität steigt, wenn der Zähler im Bruch größer ist als der Nenner. Umgekehrt wird die Priorität geringer, wenn der Zähler kleiner als der Nenner wird. Das ist absolut sinnvoll und in der Darstellung objektiv. Ein Feature, das einen hohen Wert liefert und ohne Risiko und zu geringen Kosten umgesetzt werden kann ist höher einzustufen, als ein Feature von geringem Wert mit langer Entwicklungszeit und hohen Kosten.


©2019 Kopitzke ® Pro | Impressum | Datenschutzerklärung

Log in with your credentials

Forgot your details?

Send this to a friend