Priorisierung von Product Backlogs in agilen Projekten

Motivation

Heutzutage werden besonders in der IT-Branche immer mehr Projekte agil und nicht mehr klassisch durchgeführt. Es entfällt die Rolle des Projektmanagers und Teams organisieren sich selbst. Das Entwicklungsteam muss wissen, warum es etwas tun soll und welche Vision dahintersteckt. 

Da die Produktverantwortlichen jedoch oftmals nicht diejenigen sind, die das voll umfängliche technische Verständnis für das entstehende Endprodukt besitzen, wird eine Methode benötigt, um das technische Know-how der Produktentwickler und das betriebswirtschaftliche Verständnis der Produktverantwortlichen zusammenzubringen. So kann herausgefunden werden, welche Arbeit in einem Projekt Vorrang gegenüber anderen Aufgaben hat. 

Um dieses Problem zu lösen, habe ich mich in meiner Bachelorarbeit damit beschäftigt, wie die Priorisierungsmethode Weighted Shortest Job First (WSJF) in Projekten eingesetzt werden kann die technisch voneinander abhängige Product Backlog Items (PBIs) besitzen.

Meine Bachelorarbeit trägt den Titel „Adaption der Priorisierungstechnik <> für agile Backlogs in das SCRUM Framework angewendet in der Softwareentwicklung.“

Die Motivation für das Thema wurde zum einen von Seiten der FH Westküste getrieben. Dort befasst sich Prof. Dr. Ingmar Georg Stauff, der Betreuer meiner Bachelorarbeit, intensiv mit der Lehre des agilen Projektmanagements. Zum anderen bestand ein Bedarf in einem Kundenprojekt, die Priorisierung des Product Backlogs besser zu strukturieren. So konnte ich ein Thema, welches mir sowohl privat als auch in der Hochschulausbildung sehr viel Freude bereitet bei der Arbeit einsetzen und daraus einen Mehrwert erzielen.

Thematische Einführung

Das agile Projektmanagement wurde ab dem Jahre 1990 in Teilbereichen der Softwareentwicklung erstmals angewendet. (Ziegler, 2018, S. 4) Teammitglieder sind für den Fortschritt im Projekt selbst verantwortlich und arbeiten i.d.R. in einer Bottom-Up-Projektorganisation. Dies bedeutet, dass die Organisation von der untersten Hierarchieebene hin zur Führungsspitze verläuft. Probleme können bei Bedarf zur nächst höheren Organisationseinheit getragen und mit erweiterten Kompetenzen gelöst werden. Durch Anregungen und neue Ideen beeinflussen alle Beteiligten den Verlauf des Projekts mit. Projektverantwortliche sind dafür zuständig, Aufgaben zu priorisieren und dem Entwicklungsteam mit den richtigen Aufgaben zur richtigen Zeit den Weg zum Erfolg zu ermöglichen. Dafür weist der Projektverantwortliche Aufgabenpakete zu, welche vom Entwicklungsteam umgesetzt werden. Innerhalb dieser Aufgabenpakete organisiert sich das Team ausschließlich selbst. Nur wie kann ein Projektverantwortlicher sinnvoll bestimmen, welches die nächsten wichtigen Aufgaben sind, wenn noch gar nicht alle Aufgaben definiert sind bzw. eventuell noch viel wichtigere Aufgaben im Verlauf des Projekts hinzukommen? Das Product Backlog ist der Ideenspeicher des gesamten Projekts. Projektverantwortliche halten hier die wichtigen Aufgaben an oberster Stelle und sortieren meist mit einem absteigenden Detaillierungsgrad die Aufgaben nach der Wichtigkeit. Diese Aufgaben lassen sich oft in sogenannten Epics als Überkategorie zusammenfassen. Ist ein Epic vollständig bearbeitet, ist ein Teilbereich des Projekts abgeschlossen. Somit tragen Epics mit all ihren Unteraufgaben wesentlich zur Verbesserung des entstehenden Produkts bei. Im Product Backlog werden PBIs üblicher Weise jedoch nicht nach Epics geordnet dargestellt, da Epics keine zeitliche Abfolge definieren, sondern eine Bündelung von Funktionalitäten.

Mithilfe der Cost-of-Delay-Betrachtung kann die Wichtigkeit der PBIs bestimmt werden. Wird eine Aufgabe nicht rechtzeitig oder gar nicht fertiggestellt, entstehen oft zusätzliche Kosten für das betreffende Unternehmen. Durch eine gute Priorisierung werden Verzögerungen minimiert und somit etwaig entstehende Mehrkosten durch schlechte Organisation der Arbeitsreihenfolge vermieden. Übliche Bewertungskriterien zur Bestimmung der Cost of Delay sind: Business Value, Time Criticality und Risk Reduction. Um die entstehenden Kosten in der Produktentwicklung zu minimieren, gibt es Ansätze wie zum Beispiel „High Delay Cost First“ oder „Shortest Job First“. 

Die Betrachtung der Verzögerungskosten kann darüber hinaus noch in das Verhältnis zur Aufgabengröße gesetzt werden. Diese Bewertungsmethode nennt sich „Weighted Shortest Job First“ und betrachtet den erzeugten Nutzen bzw. die entstehenden Verzögerungskosten eines PBIs in der Relation zum entstehenden Aufwand.

Diese bereits weit verbreiteten Methoden zur Priorisierung von Product Backlogs betrachten jedoch keine Abhängigkeiten zwischen PBIs in Projekten.

Daher wird im folgenden Abschnitt eine Formel auf Basis der Methode WSJF vorgestellt, welche durch ihre Flexibilität der Einzigartigkeit von Projekten Rechnung trägt und unter Berücksichtigung der relevanten Faktoren eine höhere Planungssicherheit im Projekt ermöglichen soll. Durch die Berücksichtigung von Epics, Abhängigkeiten, Risiken im Projektteam und der Bewertung der Aufgabengröße, kann eine nachvollziehbare Bewertung des Product Backlogs durchgeführt werden.

Analyse

Folgende Formel (Formel 1) wurde abgeleitet, um bei agil durchgeführten Projekten drei Ebenen des Projektmanagements zu betrachten und bei der Durchführung mit einzubeziehen.

Die erste Ebene bezieht sich auf die verschiedenen Teilaufgaben im Projekt. Diese werden bei agilen Projekten in Epics gegliedert und können gebündelt priorisiert werden.

Wenn sich PBIs im Projekt gegenseitig beeinflussen und es Abhängigkeiten gibt, werden diese auf der zweiten Ebene betrachtet.

Die dritte Ebene berücksichtigt vor allem die Standartwerte des Cost-of-Delay-Ansatzes. Sie befindet sich auf der innersten Ebene, da hier nicht funktional priorisiert wird. Eine fehlerhafte Bewertung an dieser Stelle kann zwar negative Folgen haben, das Projekt als solches kann jedoch mit den nächsten Aufgaben fortgeführt werden.

Da sich die drei Ebenen der Bewertung von innen heraus beeinflussen, erfolgt auch die Gewichtung ausgehend von der innersten Ebene. Die Anzahl und der maximal mögliche Wert der Kriterien entscheiden über den Faktor, mit dem die zweite Ebene multipliziert wird, um ein K.-o.-Kriterium darzustellen. Aus den Maximalwerten der Ebenen zwei und drei ergibt sich der Faktor für die erste Ebene. Dies verdeutlicht Abbildung 1.

Aus diesem Modell der drei Ebenen ergibt sich die folgende Formel:

Alle Variablen werden mithilfe der Fibonacci-Folge im Bereich von 1 bis 21 bewertet. Diese mathematische Zahlenfolge wird üblicherweise bei Schätzungen im Rahmen agiler Methoden verwendet. Bei der Fibonacci-Folge wird mit zunehmendem Zahlenwert der Abstand zu Vorgängern größer. Dies entspricht einer wichtigen Voraussetzung bei Schätzungen, wo mit zunehmender Komplexität auch die Schätzungsunsicherheit zunimmt. (Wiechmann, o. J.) Als Maximalwert der Skala wurde hier die 21 gewählt, da an dieser Stelle häufig schon eine Komplexität auftritt, welche sich nicht in einer einzelnen Iteration der inkrementellen Produktentwicklung unterbringen lässt (Domin, 2019).

Formel 1 berücksichtigt zum einen die Vision des entstehenden Produkts und die zur Realisierung notwendige Product Roadmap. Ein weiterer Aspekt ist die Einbeziehung von PBIs, welche innerhalb ihres Epics Abhängigkeiten zu anderen PBIs haben. Diese gilt es im Idealfall schnellstmöglich aufzulösen. So sollten PBIs, die nachfolgende Product Backlog Items blockieren, möglichst schnell durchgeführt werden, um Warteschlangen im Projekt zu vermeiden. Die dritte Ebene, die diese Formel berücksichtigt, bezieht sich auf die Substitution der Standardplanungsfaktoren in einem agilen Projekt. Wenn bei Projekten die Bestandteile von Cost of Delay für Teilaspekte oder auch für das gesamte Projekt nicht definiert werden können, so zeigt diese Formel, welche Aspekte in der Bewertung von Prioritäten bei Projekten sinnvoll berücksichtigt werden können. So werden die Abläufe in der Produktentwicklung enorm unterstützt.

Zuerst wird die oberste Ebene der Formel betrachtet. Die Epic-Priorität beschreibt die äußerste Schicht der Formel. Sie wird im Projekt- bzw. Managementkreis durch die Erarbeitung der Product Roadmap definiert. Die dazugehörigen Aufgaben können beispielsweise durch eine User Story Map visualisiert werden. Product Backlog Items, deren Epic eine aktuell hohe Dringlichkeit im Projekt hat, werden gegenüber PBIs, die im Projekt erst deutlich später relevant sind, vorgezogen.

In der Formelerläuterung 1 wird die Epic-Priorität deutlich. Sie wird mit dem Wert 924 multipliziert. Dieser Wert setzt sich aus den Maximalwerten der Risikoreduzierung (RR), der Product Owner Priorität (PP) und der Anzahl der Folgetasks (FT) zusammen. Da diese Werte alle den Maximalwert 21 für eine Bewertung tragen, benötigen wir den Wert 924, um ein Übergewicht zu erzeugen.

Durch den Faktor 924 erhält die Epic-Priorität eine höhere Priorität als alle weiteren Bewertungsfaktoren. Die Produktvision und die daraus abgeleitete Product Roadmap sind also richtungsweisend und bilden eines der stärksten Steuerungselemente in der Produktentwicklung ab. Daher ist es an dieser Stelle besonders wichtig, sich über Vision und Product Roadmap intensiv Gedanken zu machen und diese explizit zu definieren.

An zweiter Stelle steht die Betrachtung von Abhängigkeiten innerhalb der Epics. Product Backlog Items, die andere beeinflussen, die also in einer Ende-Anfang-Beziehung stehen, sollten bei der Planung der Produktentwicklung berücksichtigt und entsprechend vorgezogen werden. Dies führt zum einen dazu, dass das Backlog schnell eine unabhängige Struktur aufweist. Zum anderen werden Aufgaben detaillierter geplant und mit dem Entwicklungsteam besprochen. So können Abhängigkeiten aufgedeckt werden, die in der Kollaboration von Produktverantwortlichen und Produktentwicklern entstanden sind. Damit die Folgetasks Vorrang gegenüber etwaigen Projektrisiken oder auch der rein intuitiven Priorität des Product Owners bekommen, wird ihre Anzahl festgelegt, anhand einer Umrechnung auf Fibonacci-Werte übertragen und mit dem addierten Maximalwert von PP und RR multipliziert. So bekommen Tasks aufgrund ihrer Abhängigkeiten zu nachfolgenden Tasks eine höhere Priorität gegenüber den Bewertungen durch die Priorität des Product Owners und der Risikobewertung. Wichtig ist hierbei, dass bei der Betrachtung der Folgetasks stets alle Folgetasks, auch die der Unteraufgaben, mit einbezogen werden. Es kann also nicht vorkommen, dass PBI 1 vor PBI 2 fertig sein muss und PBI 2 dabei mehr Folgetasks ermöglicht als PBI 1. Nach jeder abgeschlossenen Iteration in der Produktentwicklung müssen Abhängigkeiten neu betrachtet und die Bewertung der Folgetasks bei betroffenen PBIs angepasst werden. Anhand der nachstehenden Formel wird dies verdeutlicht:

Bei zwei PBIs, die in einer Ende-Anfang-Beziehung stehen, kann der Fall eintreten, dass durch die Gewichtung, die durch starke Abweichungen bei der Dauer entsteht, eine falsche Priorisierung errechnet wird. Daher wird in der Formel die Dauer um den Wert AVT erweitert (siehe Formelerläuterung 3). Dieser Faktor beschreibt den Aufwand von Vorgängertasks. Er beschreibt die kumulierte Dauer von PBI´s, die vor der Durchführung des betrachteten Product Backlog Items abgeschlossen sein müssen. 

Durch diese künstliche Erhöhung des Aufwands soll vermieden werden, dass in der Produktentwicklung Aufgaben angegangen werden, für die Grundvoraussetzungen noch nicht erfüllt sind. Sind berücksichtigte Vorgängeraufgaben abgeschlossen, vermindert sich der AVT-Wert bei den folgenden Aufgaben entsprechend. Der zu beachtende Aufwand von Vorgängertasks ist unabhängig von der Anzahl der Folgetasks, die ein PBI nach Abschluss ermöglicht. Beispielsweise könnte das letzte Item in einer Kette abhängiger Tasks darauf angewiesen sein, dass vorherige Aufgaben abgeschlossen wurden, was sich in einem entsprechenden AVT-Wert widerspiegeln würde. Jedoch ist kein weiteres PBI von diesem abhängig. Somit fiele der FT-Wert weg. Die innerste Ebene, die mit der Formel betrachtet wird, ist die Substitution der Standardplanungsfaktoren der Bewertungsmethode Cost of Delay. Business Value, zeitliche Abhängigkeiten oder auch interne sowie externe Projektrisiken können nicht immer so detailliert beschrieben werden, dass sie auf jedes Product Backlog Item im Projekt heruntergebrochen werden können. In solchen Fällen ist es nicht sinnvoll, künstlich einen Business Value oder fiktive Liefertermine für Deadlines herzuleiten. Diese beziehen sich letztlich allein auf die Intuition des Product Owners oder auf das Know-how der Person, die diese Planung erstellt. Somit kann diese Intuition bzw. der Erfahrungswert der planenden Person besser von Anfang an in einem Faktor zur Priorisierung festgehalten werden. Dies verdeutlicht die Priorität des Product Owners (PP) (siehe Formelerläuterung 4). 

Zeitliche Fertigstellungstermine wurden in der Formel durch die Anzahl der Abhängigkeiten innerhalb eines Epics ersetzt. Somit entsteht wie in der Beschreibung zur zweiten Ebene der Formel ein mit der Zeit stets unabhängiger werdendes Backlog, welches eine sachlich logische Reihenfolge der Projektplanung berücksichtigt. 

Auch die Bewertung interner oder externer Projektrisiken lässt sich oftmals schwer auf einzelne PBIs übertragen. Es fehlt für den Vergleich mit Mitbewerbern die nötige Transparenz am Markt oder interne Abteilungen geben nicht genügend Vergleichswerte zum Benchmarking her. Daher betrachtet die Risikoreduzierung (siehe Formelerläuterung 5) in dieser Formel lediglich die Eintrittswahrscheinlichkeit, dass ein PBI nicht abgeschlossen werden kann. Je nach Know-how und Erfahrung des Entwicklungsteams wird dieser Faktor, entsprechend einer vorher definierten Skala, hoch oder niedrig bewertet. Aufgaben, die durch eine hohe Eintrittswahrscheinlichkeit eine hohe Risikobewertung bekommen, werden im Projekt höher priorisiert als PBIs mit niedriger Risikowahrscheinlichkeit. Hoch bewertete PBIs gilt es, möglichst frühzeitig abzuschließen, um Wissenslücken im Projekt schon am Anfang zu füllen. Auf dieses Wissen kann im späteren Projektverlauf aufgebaut werden. Mit dem Wert der Risikominimierung werden hier keine externen Projektrisiken betrachtet, sondern die Fähigkeiten der Organisation bewertet.

Die gesamten Werte der Formel stehen im Verhältnis zur Dauer (D). Aufgrund des unterschiedlichen Aufwands der PBIs kann es daher vorkommen, dass ein PBI mit der aktuell nicht höchsten Epic-Priorität einer Aufgabe vorgezogen wird, die durch die aktuelle Planung der Product Roadmap die höchste Einstufung der Epic-Priorität besitzt. Es handelt sich also stets um eine Gewichtung zwischen Aufwand, der in dem Projekt entsteht und Nutzen, der für das Projekt und somit auch für den Kunden gewonnen wird (siehe Formelerläuterung 6). Gleichzeitig sorgt dieses Verhalten dafür, dass verschiedene Epics im Projekt weiterhin parallel bearbeitet werden können und nicht die Epics anhand der Anzahl der enthaltenen Abhängigkeiten angegangen werden. 

Ergebnisse

Die hier beschriebene Formel bewertet das Product Backlog auf drei Ebenen. Zuerst wird die Wichtigkeit der Epics zueinander untersucht. Diese spiegeln die Product Roadmap wider und zeigen den zeitlichen Ablauf der zu erreichenden Meilensteine im Projekt (vgl. rote Werte Formelerläuterung 7). Auf der zweiten Ebene werden Abhängigkeiten innerhalb der Epics aufgedeckt. Diese gilt es, möglichst schnell aus dem Projekt zu entfernen, um ein möglichst unabhängiges Product Backlog zu bekommen (vgl. grüne Werte Formelerläuterung 7). Insbesondere bei technischen Projekten ist ein Vorgehen unter der Berücksichtigung bestimmter Abhängigen jedoch unabdingbar. Zu beachten ist hier, dass agile Vorgehensmodelle bei Projektstart kein vollständiges Lastenheft der zukünftigen Aufgaben vorsehen. Die Betrachtung der Abhängigkeiten beschränkt sich im agilen Projektmanagement also auf das zur Zeit der Planung vorhanden Wissen der Entwickler sowie Wissen, welches aus Dialogen von Mitarbeitern bei der Planung entsteht. Die dritte Ebene betrachtet die individuelle Priorisierung des Product Owners aufgrund seiner Erfahrung und der Bewertung des Projektumfeldes. Als möglicher Rückschluss kann hier eine Aussage über die Leistungs- und Teamfähigkeit des Projektteams getroffen werden (vgl. blaue Werte Formelerläuterung 7). Alle Ebenen der Bewertung stehen in Relation zum jeweiligen Aufwand der Aufgabe (vgl. schwarze Werte Formelerläuterung 7).

Diskussion

Anwendung kann diese Art der Priorisierung von Product Backlog Items in jedem Projekt finden. 

Besonders wenn die agile Vorgehensweise in einem Unternehmen oder auch Projektteam noch nicht routiniert ist, kann es sehr hilfreich sein, Bezugsgrößen zu benennen, die die Basis für Entscheidungen bilden. Vergangene Entscheidungen können so retrospektiv nachvollzogen werden und künftig zu treffende Entscheidungen werden besser eingeordnet. 

Die erste Ebene der Formel kann in jedem Projekt angewendet werden, da jedes Projekt Teilaufgaben besitzt, welche zu unterschiedlichen Zeitpunkten unterschiedlich wichtig sind.

Ebene zwei der Formel findet Anwendung, sobald sich Teilaufgaben in Projekten gegenseitig beeinflussen. Ist dies nicht der Fall, kann die Wichtigkeit künftiger Aufgaben für jedes PBI einzeln bewertet werden. Sind im Product Backlog alle Items unabhängig, so fallen bei der Bewertung die Faktoren FT und AVT weg und es wird die dritte Ebene der Formel verstärkt betrachtet.

Dort kann je nach Art des Projektsettings und Wunsch der Projektverantwortlichen ein Maßstab zur Bewertung der Wichtigkeit von Product Backlog Items festgelegt werden. Hier kann eine Bewertung nach der Methode Cost of Delay stattfinden. Möglich ist es auch, die Wichtigkeit der PBIs mithilfe von Teilaspekten von Cost of Delay zu bewerten. Es kann jedoch, wie im Kapitel 3 beschrieben, auch auf reine Wünsche und intuitive Bewertungen der Projektverantwortlichen zurückgegriffen werden.

Durch die Gewichtung der Bewertungsfaktoren auf Ebene drei, können je nach Bedürfnis der Projektverantwortlichen andere Eigenschaften definiert werden, welche die Wichtigkeit der Product Backlog Items lenken.

Zusammenfassung

Auf den Punkt gebracht zeigt diese Formel eine Erweiterung der Möglichkeiten im agilen Projektmanagement Backlogs zu organisieren. Backlogs werden nicht nur nach Kosten, Terminen, Risiken und Aufwand geordnet, sondern können auch Projektbesonderheiten wie beispielsweise unauflösbare Abhängigkeiten berücksichtigen.

Ob technische Abhängigkeiten, stetig wechselnde Mitarbeiterstrukturen oder auch zwischendurch anfallende Aufgaben aus der nebenherlaufenden Linienorganisation – egal welche Umstände sich auf die Durchführung des Projektes auswirken: Die Formel hilft dabei, eine Grundlage zu definieren, die Sicherheit und Struktur in die Planung sowie Durchführung des Projekts bringen kann.

References

Domin, A. (2019) Scrum: Was ist eigentlich Planning-Poker? [Online]. Available at https://“‹t3n.de“‹/“‹news/“‹scrum-„‹planning-„‹poker-„‹1138385/“‹ (Accessed 28 January 2020).

Wiechmann, R. (o. J.) Fibonacci Sequenz [Online]. Available at https://“‹scrum-in-der-praxis.de“‹/“‹glossary/“‹fibonacci (Accessed 17 January 2020).

Ziegler, M. (2018) Agiles Projektmanagement mit Scrum für Einsteiger: Agiles Projektmanagement jetzt im Berufsalltag erfolgreich einsetzen, München, Prima Media.