Von eCube GmbH
Feature Priorisierung vs. Business-Value

Im IT-Projektmanagement gibt es viele spannende Rollen für jemanden wie mich. Entwickler-Background, Wissenskommunikation irgendwann mal studiert und wie verrückt an Organisationsmethodik interessiert.
Dadurch machen mir so ziemlich alle Rollen in diesem Umfeld riesigen Spaß – vom Agile Coach, bis zum Projektmanager im klassisch-sequentiellen Umfeld. Der Spaß bleibt aber nur so lange erhalten, wie ich das Wichtigste im Griff behalte: Meine Stakeholderinnen auf dem Laufenden zu halten. Das bedeutet vor allem, dass ich es schaffe, dass sich ihre Erwartungen und ihr Know-How parallel zum Projekt mit entwickeln. Das geht nicht von allein und ist als Projektmanager oder Product Owner selbstverständlich zu 100% meine Verantwortung.
Für ein gesundes Erwartungs- und Wissensmanagement in IT-Projekten ist es meiner Meinung nach am aller wichtigsten, dass die Prioritäten in meinen Projekten transparent und verständlich sind. Allen muss klar sein, woran gearbeitet wird bzw. woran nicht gearbeitet wird. Es muss auch klar sein, warum. Und damit bin ich mitten im Thema.
Ob Review im Scrum-Kontext oder Statusmeeting im Lenkungsausschuss, wenn meine Kolleginnen nicht nachvollziehen können, warum das Eine vor dem Anderen erledigt wird, werde ich über kurz oder lang Frust kreieren. Das ist vor allem dann der Fall, wenn iterativ entwickelt wird und ich Stakeholderinnen mit unterschiedlichen Interessen habe. Sprich: Ihre Anforderungen konkurrieren miteinander und wollen von meinem Team umgesetzt werden.
Das führt früher oder später zu einer Situation, die Sie sicher kennen: Sie sprechen mit Ihrer Sponsorin und diese fragt Sie, weshalb Ihr Team Feature A zuerst umgesetzt hat, wo doch klar kommuniziert worden war, dass Feature B das erste sein sollte. Sie hatten gute Gründe für den Wechsel der Prioritäten aber in dieser Situation ist das Kind bereits in den Brunnen gefallen. Wie Sie diesen Case vermeiden können, lesen Sie im kommenden Absatz.
Was ich niemals mache, ist, Features zu dokumentieren und anhand welcher Kriterien auch immer in einer Liste zu priorisieren. Das geht, je nach Ansicht Ihrer Stakeholderinnen, in die Hose. Denn auch eine Beurteilung von Features aus nackter monetärer Sicht kann über Strategie-Gedanken, operative Kosten auf Zeitebene oder irgendeine andere Art und Weise umgedreht werden. Es kommt halt darauf an…
Software-Features werden häufig in strukturierten Anforderungen formuliert und priorisiert. Sie stellen die zu entwickelnden Funktionen einer Software aus technisch-funktionaler Sicht dar. Alternativ können Softwareentwickler auch mit User Stories arbeiten, die ebenfalls Anforderungen einer Software sind, aber auf Basis von Nutzerbedürfnissen verfasst werden.
Stattdessen formuliere ich die Anforderungen meiner zu entwickelnden Softwareprodukte in User Stories und lasse diese auf neutrale Weise gegen einander antreten. Sie werden auf zwei Arten miteinander verglichen:
Business-Value: Eine abstrakte Messgröße, die den Geschäftswert einer Anforderung bestimmt. Abstrakt, um verschiedene Werte wie Kostenersparnisse oder strategischen Wert vergleichbar zu machen.
Story-Points: Eine weitere abstrakte Messgröße, die den Aufwand oder die Komplexität der Umsetzung einer Anforderung angibt.
Im Folgenden werden beide Werte beispielhaft angewendet.
Je höher der Business-Value, desto wertvoller ist die User Story, also die Anforderung. Je niedriger die Story-Points sind, desto leichter ist sie umzusetzen. Wenn ich beide Werte miteinander korreliere, versetzt mich das schließlich in die Lage, ganz neutral entscheiden zu können, was jetzt umgesetzt wird und was nicht. Damit jeder immer in der Lage ist, diese Einschätzung nachzuvollziehen, mache ich das für alle Projektteilnehmenden und -interessierte mittels Aufwand-Nutzen-Matrix transparent. Einfach jeder hat Zugriff. Wie das aussieht, sehen Sie hier:
Im Beispiel sehen Sie ganz deutlich die logische Reihenfolge, der umzusetzenden Anforderungen. Diejenigen, die wertvoll sind und mit wenig Aufwand umsetzbar (im grünen Bereich), werden zuerst eingeplant. Was sich im roten Bereich befindet, hat schlechte Karten. So sieht die Reihenfolge in der Matrix in Reihe aus, wenn sich in den kommenden Wochen nichts daran ändert:
Story-Points sind ein abstrakter Wert, der vom Entwicklungsteam vergeben wird. Das Team schätzt (in der Regel mithilfe eines Planning-Pokers) die Komplexität oder den Aufwand der Anforderungen ein und vergibt Story-Points, die durch Fibonacci-Zahlen repräsentiert werden:
Das Verwenden vom Fibonacci-Zahlen soll davor schützen, dass sich Ihr Team darüber streitet, ob eine Anforderung eher eine 55 oder eine 57 ist. Denn das Ziel der Story-Points ist, die Anforderungen in Größenordnungen einzuteilen, nicht sie kleinteilig miteinander zu challengen.
Auch den Business-Value kann man mithilfe einer Pokerrunde, dem sogenannten Business-Value-Poker, durch Stakeholderinnen ermitteln lassen. Das hat die Vorteile, dass es schnell geht und durch alle relevanten Stakeholderinnen abgesegnet wird. Zudem lernen alle Beteiligten ungemein viel über die Anforderungen anderer Stakeholderinnen. Ein Nachteil ist, dass die Runde vollständig sein muss, damit es später keinen Ärger über zu gering oder zu groß geschätzte Anforderungen gibt. Zudem können Bias die Schätzungen beeinflussen und unrealistisch machen.
Ich versuche gerne den Business-Value der Anforderungen meiner Stakeholderinnen so gut wie möglich auszurechnen, damit sie neutral und ohne subjektive Schätzungen miteinander verglichen werden können. Meine Stakeholderinnen helfen mir in der Regel dabei. Dazu sind allerdings Referenz-Anforderungen beziehungsweise Referenz-Values notwendig. Sie ermöglichen eine Vergleichbarkeit der unterschiedlichen möglichen Outcomes von Anforderungen. Denn manche Anforderungen sind wertvoll, weil sie Prozesse verschlanken. Andere stärken das Marketing und damit die Kundenakquise. Diese miteinander auf Basis ihres Wertes zu vergleichen ist schwierig. Wie dieses Dilemma mithilfe von Referenz-Values gelöst werden kann, zeigt das folgende Beispiel:
Ein Unternehmen verkauft direkt in seinem Content Management System über einen Composable Commerce Ansatz verschiedene Produkte. Um den Verkauf zu steigern, müssen noch eine Reihe von User Stories durch das Entwicklungsteam umgesetzt werden. Diese Stories haben folgende unterschiedliche Outcomes:
Diese Werte muss der Business-Value miteinander vergleichbar machen. Das kann er über Referenz-Values. Folgendermaßen kann das in diesem Beispiel gestaltet werden:
Ein Business-Value von 5 wird repräsentiert durch:
Egal, welches Outcome nun in welcher Höhe von der Product Ownerin ausgerechnet werden muss. Über den Referenz-Value 5, also den Beispiel-Outcomes, die den Business-Value 5 haben, wird man die User Stories miteinander vergleichen und so neutral priorisieren können.
Mein Tipp an Sie ist: Verwenden Sie Business-Values, um Ihre Anforderungen miteinander neutral vergleichbar zu machen. Nehmen Sie Story-Points zur Hilfe, um eine aussagekräftige Matrix aufbauen zu können, die den Wert und den Aufwand zeigt. Machen Sie Ihre Priorisierung damit transparent und verzichten Sie lieber auf Feature-Listen, die von Ihren Stakeholderinnen falsch interpretiert werden können.
So machen Sie vollständig und ganz neutral nachvollziehbar, was wann warum an der Reihe ist. Ihre Stakeholderinnen werden es Ihnen danken und mit den richtigen Erwartungen in die Planung gehen. Das Beste daran: Sie haben – so wie auch ich – Spaß im IT-Projektmanagement!
Passend dazu: Plattformwechsel im E-Commerce erfolgreich managen (Teil 1)