Schon die Überschrift ist bei diesem Thema schwierig, eil es ein »richtiges« oder »falsches« Priorisieren eigentlich nicht gibt. Dennoch führen wir immer wieder Diskussionen, warum wir eine Sache einer anderen vorziehen. Warum ist das so, und wie kommt ein Team zu einer sinnvollen und nachvollziehbaren Priorisierung?
Bewegen wir uns im Scrum-Kontext ist die Sache mit der Priorisierung sehr einfach. Dort heißt es: es gibt ein Product-Backlog, dessen Einträge priorisiert sind, wofür der Product Owner verantwortlich ist. That’s it. Wie er das macht, ist völlig egal, kann er auswürfeln oder aus den Eingeweiden von Singvögeln lesen. Die Praxis sieht natürlich etwas anders aus. Dort haben wir Stakeholder, die ihre eigene Sichtweise hereinbringen. Sehr selten finden wir eine Situation, in der Stakeholder lediglich einen Featurewunsch äußern, den Product Owner bzw. das Team machen lassen, und ohne Widerspruch oder Diskussion die Entscheidung akzeptieren, ziemlich weit unten in der Liste zu landen.
All unsere Stakeholder haben eigene Interessen und eigene Sichtweisen. Ihnen fehlt ganz selbstverständlich der Blick für das, was andere sich wünschen. Meine Priorisierung muss also nachvollziehbar sein, damit ich in den unvermeidlichen Diskussionen nicht vollkommen in der Luft zerrissen werde, oder gibt es auch noch andere Optionen?
Bevor wir tatsächlich über Methoden in der Priorisierung sprechen, möchte ich zwei grundsätzliche Dinge vorweg behandeln:
Zum einen möchte ich Euch dringend dazu raten, eine Prio nicht allein vorzunehmen. Und genau diese unterschiedlichen Sichtweisen und Wertungen unserer Stakeholder sind einer der Gründe dafür. Auch wenn ich als Product Owner (oder als Verantwortlicher, wenn ich mich nicht in Scrum bewege) möglicherweise befähigt bin, vollkommen eigenständig zu priorisieren, müssen wir trotzdem mit Erwartungen umgehen, und alle haben unterschiedliche Erwartungen. Es hilft Euch sehr, Euer Stakeholder möglichst früh abzuholen und einzubinden.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Ich spreche hier nicht über die feinste Granulierung, sondern eher über grobe Themen und größere Vorhaben – nicht dass wir uns hier falsch verstehen. Wir möchten keine Detaildiskussionen, sondern die grundlegenden Diskussionen im größeren angemessenen Rahmen führen, damit wir vor unserer Arbeit diskutieren und nicht hinterher. Irgendwann müssen wir diskutieren. Unser praktisches Leben ist eben nicht unser theoretisches Leben.
Wir sollten ebenfalls unsere Teamkollegen bzw. diejenigen, die in der Umsetzung sind, hinzuziehen, auch wenn wir selbst über einige technische Kenntnisse verfügen. Unsere Kollegen wissen jedoch mehr über die technischen Themen, deswegen sitzen sie in der Umsetzung und wir in der Planung, ansonsten könnten wir uns diese Rollenverteilung sparen, nicht wahr? Unsere Entwicklerkollegen können Aufwände wesentlich besser einschätzen als wir.
Sorgt zum anderen bitte dafür, dass Ihr Euch organisationsweit auf Kriterien zur Priorisierung einigt. Sehr oft passiert das nicht, und wir haben wieder Diskussionen, die wir nicht brauchen und die uns endlos nerven. Fragen wir unsere Kollegen, hat jeder eine ganz gute Vorstellung, wie priorisiert wird. Die meisten werden dann von Kosten und Nutzen sprechen. Gehen wir jedoch ins Detail stellen wir fest, dass wir doch größere Unterschiede haben.
Warum?
Bleibe ich bei den Begriffen »Kosten« und »Nutzen«, sind diese reichlich unbestimmt. Wir können alles Mögliche darunter verstehen. Nutzen kann ich beispielsweise eher monetär betrachten, denke also eher in Umsatz und Gewinn. Damit vertrete ich eine Innensicht. Ich kann aber auch diesen nebulösen Kundennutzen sehen, gehe davon aus, dass Umsatz und Gewinn damit sowieso folgen, und hoffe, dass ich meine Kunden damit auch länger an mich binde. So würde ich eine Außensicht vertreten. In der Tendenz ist das auch eher längerfristig gedacht als das rein monetäre Denken.
Erzählt mir jetzt nicht, dass wir in der Agilen Welt immer über Nachhaltigkeit und Kundennutzen sprechen. Wenn sich dieser Kundennutzen nicht wenigstens indirekt auch monetär zeigt, werde ich mir nur einen Satz heiße Ohren holen.
Auch die Gewichtung von Kosten zu Nutzen kann unterschiedlich sein. Das eine Ende der Skala liegt bei »Wir bauen was richtig Geiles, koste es was es wolle« das andere bei »haltet mal den Ball flach, wir haben kein Geld«.
Wie wir die Begriffe interpretieren und sie jeweils werten, hat einen großen Einfluss auf unsere Priorisierung. Sind wir uns dabei organisationsweit nicht einig, führen wir immer wieder Diskussionen, die wir nur einmal führen sollten.
Bei der tatsächlichen Methode gehe ich ganz gern in drei Schritten vor. Eigentlich sind es vier, aber wir gehen hier mal davon aus, dass wir das Sammeln und Erklären, was sich hinter jedem einzelnen Punkt verbirgt, schon erledigt haben. Wir starten also mit einer vollkommen ungeordneten Liste.
Im ersten Schritt wollen wir nur grob clustern. Wir teilen unsere Anforderungen in eine Muss-, eine Soll- und eine Kann-Gruppe. Hier brauchen wir unbedingt die Stakeholder, weil unsere Interpretation eine ganz andere sein kann als ihre.
Die Welt kennt dazu das (Bullshit-Bingo) MuSCoW-Schema, was nichts Anderes bedeutet als Must, Should, Could und Won’t.
Die größte Schwierigkeit ist die Unterscheidung zwischen meinen Muss- und meinen Soll-Themen. Muss ist das, was ich unbedingt brauche. Lasse ich eines davon weg, bricht mein Projekt oder mein Produkt auseinander und erfüllt seinen Zweck nicht mehr. Ich möchte meinen Muss-Cluster also so sauber wie möglich halten. Damit sind Usability oder Performance (wenn nicht ein absoluter Gamebreaker) maximal Soll-Themen. Sicherheitsrelevante Dinge sind hingegen oft Muss-Themen.
Meine Kann-Themen sind Schöner Wohnen oder nice-to-have. Es sind also Dinge, auf die ich auch verzichten kann.
Am Ende dieses ersten Schritts habe ich drei grobe Cluster.
Im zweiten Schritt beschäftigen wir uns mit Abhängigkeiten, sowohl technischer als auch fachlicher Natur. Mindestens für die technischen Abhängigkeiten brauchen wir den Input der Entwickler bzw. der Umsetzenden. Diese müssen uns die Frage beantworten, was wir tun müssen, bevor wir eine andere Sache tun können. Hierbei können uns Dinge einfallen, an die wir noch nicht gedacht haben. Es kann auch passieren, dass Anforderungen, die wir nicht in unseren Muss-Cluster gehoben haben, von anderen Muss-Themen benötigt werden, womit diese Anforderungen plötzlich auch Muss-Themen werden.
Es werden sich Paare bilden, Ketten, oder manchmal auch ganze Bäume, wenn wir Pech haben. Andere Anforderungen haben keinerlei Abhängigkeiten. Wir sollten diese Abhängigkeiten kenntlich machen und auch dauerhaft im Auge behalten. Es ist uns nicht gedient, wenn wir sie vergessen.
Am Ende unseres zweiten Schritts haben wir Ketten innerhalb unserer Cluster gebildet.
Erst jetzt berücksichtigen wir die Aufwände in unseren Überlegungen. Das tun wir, indem wir ein Diagramm mit vier Feldern zeichnen: hoher Nutzen – hoher Aufwand, hoher Nutzen – geringer Aufwand, geringer Nutzen – geringer Aufwand, geringer Nutzen – hoher Aufwand.
Bei allem, was wir in die letzte Gruppe einsortieren, ist die Frage angebracht, warum wir das überhaupt tun sollten.
Spart Euch beim Einsortieren die Detaildiskussionen, ob eine Sache noch eine Winzigkeit aufwändiger ist als eine andere Sache und deswegen noch drei Centimeter weiter rechts einsortiert werden muss. Es sind vier Felder. Punkt. Detaillierter müssen wir nicht werden.
Ich rate dazu, mit einer Low-hanging-Fruit zu beginnen, dann ein Thema aus dem hoher Nutzen hoher Aufwand Feld, dann wieder hoher Nutzen geringer Aufwand. Der Hintergrund ist der, dass wir so kontinuierlicheren Output liefern können, weil wir während wir eine einfache Sache umsetzen, eine andere komplexere Sache bereits vorbereiten, tief in den Refinements dafür stecken und Recherchen starten. Wenn unser einfaches Thema abgeschlossen ist, sind wir also schon mittendrin in der Umsetzung unserer komplexen Sache.
Mit welcher unserer Low-hanging-Fruits wir starten, ist völlig wurscht. Das können wir auch auswürfeln. Wir wissen, dass wir alle machen müssen. Sie sind alle gleich gewichtet. Sie sind alle ähnlich teuer bzw. billlig. Warum sollte ich jetzt noch diskutieren?
Kernaussagen: Es ist hilfreich, sich organisationsweit auf gemeinsame Priorisierungskriterien zu einigen. Die Priorisierung selber sollte nicht von einer einzelnen Person vorgenommen werden. Für die Durchführung bietet sich die Unterteilung in mehrere Abschnitte an.
