Agile Anforderungspriorisierung – „who comes first?“

Die Vielzahl an Anforderungen an die moderne IT führt dazu, dass eine Priorisierung im agilen Run & Change stattfinden muss. Klare Priorisierungsgrundsätze helfen, schnelle Entscheidungen zu treffen und Konflikte in der Organisation der Entwicklungskapazitäten auf ein Mindestmaß zu reduzieren. Im Folgenden werden die gängigsten Beispiele aus der zeb-Projekterfahrung jeweils mit ihren Vor- und Nachteilen vorgestellt.

Ausgangslage – „Requirements Funnel“ im agilen Run & Change

Die möglichen Herangehensweisen an die Anforderungspriorisierung, welche wir in diesem Artikel vorschlagen, orientieren sich an dem typischen Weg, den eine Anforderung nimmt – von der Idee bis zum Release eines Features. Diesen Weg bezeichnen wir als „Requirements Funnel“.

Aufgrund der aktuellen Relevanz, Anforderungen für die (Weiter-)Entwicklung der IT im agilen bzw. hybriden (Kombination aus klassischen und agilen Methoden) Projektvorgehen zu priorisieren, fokussieren wir uns auf agile Ansätze und nutzen entsprechende Begrifflichkeiten – es wird hierbei davon ausgegangen, dass die Leserschaft mit diesen grundsätzlich vertraut ist.

Eine Anforderung durchläuft innerhalb des „Requirements Funnel“ drei Filter:

Requirements Funnel: Agiler Run & Change
  • Im ersten Schritt wird über den Qualitätsfilter sichergestellt, dass alle Anforderungen anhand klarer Leitlinien für Umfang und Inhalt sowie unter Berücksichtigung thematischer und funktioneller Abhängigkeiten im Feature-Backlog gesammelt werden.

  • Im zweiten Schritt entscheidet der Product Owner (als Einzelperson oder im Gremium) über die Umsetzungswichtigkeit der Features (Priorisierungsfilter) und überträgt diese zur weiteren Bearbeitung in den Umsetzungs-Backlog.

  • Abschließend folgt der Kapazitätsfilter zur Abwägung zwischen Umsetzungswichtigkeit und verfügbarer Kapazität an Entwicklungsressourcen. Im nächsten Sprintzyklus umzusetzende Anforderungen werden hierüber in den Sprint-Backlog übernommen.

Dieser Artikel konzentriert sich im Folgenden auf den Priorisierungsfilter.

Analysen, Artikel, Interviews und News rund um Trends & Innovation im Banking alle zwei Wochen kompakt für ihr Postfach.

Priorisierungsansätze für den Umsetzungs-Backlog

Übergreifend hängt die Anwendbarkeit der vorgestellten Ansätze von vorhandenen Organisationsstrukturen und der vorherrschenden Unternehmenskultur ab.

Eine definierte Rollen- und Verantwortlichkeitsmatrix sowie ein abgestimmter Kriterienkatalog als Basis (z. B. Akzeptanzkriterien, Kurzbeschreibung, Abhängigkeiten etc.) unterstützen Transparenz und Akzeptanz der Priorisierungsentscheidungen.

Bei allen Ansätzen bestimmt eine unabhängige, objektive Product-Owner (im Folgenden PO)-Rolle (als Einzelperson oder im Gremium) die Priorisierung des Umsetzungs-Backlogs. Somit existieren eine klare Rollenzuweisung und Entscheidungsbefugnis für das agile Vorgehen.

Aus zeb-Erfahrung ergeben sich fünf in der Praxis zu beobachtende Priorisierungsansätze:

Die folgenden Abschnitte können Sie jeweils durch Anklicken erweitern.

Agiler Run & Change: Product Owner

Der erste Priorisierungsansatz beruht auf der am Markt bekanntesten und gängigsten Methodik – die Auswahl der Umsetzungsfeatures durch den PO. Der PO ordnet im Rahmen dieses Ansatzes den Features im Feature-Backlog eine Priorität zu, die sich im Umsetzungs-Backlog an Vorgesprächen mit den Stakeholder bzw. Fachbereichen orientieren kann.

Vorteil dieser Methodik ist, dass der PO als Single Point of Contact agiert und damit die für die Priorisierung notwendige Effizienz und Geschwindigkeit besser umgesetzt werden kann. Zusätzlich hat der PO eine umfassende Übersicht über alle Features und kann so die Auswahl und Priorisierung der Themen mit Blick auf die Unternehmensziele optimal treffen.

Zu den Nachteilen zählt, dass der PO ein Verständnis für alle Fachbereiche und Anforderungen haben bzw. entwickeln muss. Zudem sind Entscheidungen des PO final und im Sinne der festgelegten Rollenkompetenzen von allen Beteiligten zu akzeptieren, was ein erhöhtes Risiko für Interventionen durch die Anforderungsgeber birgt. Außerdem bietet diese Methode die Gefahr einer möglichen Bevorzugung einzelner Features entsprechend der Agenda des PO, was nicht im ganzheitlichen Interesse aller Anforderungsgeber ist.

Agiler Run & Change: Priorisierungsgremium

Einen weiteren Priorisierungsansatz bildet das Priorisierungsgremium. Das Gremium setzt sich aus verschiedenen Vertreterinnen und Vertretern der anforderungsgebenden Fachbereiche zusammen und agiert wie ein einheitlicher PO. Im Gremium wird gemeinschaftlich diskutiert und in einem Konsensverfahren über die Priorität der Features für den Umsetzungs-Backlog abgestimmt.

Das Konsensverfahren ist ein wesentlicher Vorteil dieses Vorgehens – allen Anforderungsgebern bietet sich die Möglichkeit, ihr Anliegen zu begründen. Ein weiterer Vorteil ist, dass alle Stakeholder einen einheitlichen Wissensstand über Entwicklungstätigkeiten haben und Dritte als Expertinnen und Experten im Gremium (z. B. bei Detailentscheidungen) hinzugezogen werden können.

Nachteile birgt das Vorgehen insbesondere dadurch, dass stärkere Parteien im Priorisierungsgremium ihre Anforderungen häufiger durchsetzen können. Zusätzlich bedarf es eines hohen Personal- sowie Planungsaufwands für Vorbereitung und Durchführung der Gremiensitzungen. Darüber hinaus bietet dieser Ansatz die Basis für den möglichen Trend, dass Features mit niedrigeren Prioritäten und wenig politischer Aufmerksamkeit immer wieder zurückgestellt werden. Letztlich ist diese Methode relativ technokratisch und schwerfällig, da für alle Entscheidungen die Einbeziehung des Gremiums notwendig ist.

Agiler Run & Change: Backlogsplit

Bei diesem Priorisierungsansatz stehen Anforderungsgebern immer gleiche Anteile des Umsetzungs-Backlogs zur Verfügung, wobei die Anteile zwischen den jeweiligen Anforderungsgebern variieren können. Umzusetzende Features werden hierbei individuell durch die Anforderungsgeber priorisiert. Der PO entscheidet anschließend, welche der eingelieferten Features in den nächsten Sprint-Backlog aufgenommen werden – basierend auf einer Grobschätzung des Umsetzungsaufwands und unter Berücksichtigung der entsprechenden Entwicklungsanteile.

Der Backlog-Split hat den großen Vorteil, dass Anforderungsgeber immer auf die gleichen Entwicklungsressourcen zurückgreifen können und somit eine hohe Planungssicherheit haben. Die Aufteilung der Entwicklungsressourcen ist fair gestaltet, da sie auf zuvor vereinbarten Schlüsseln basiert, die über die Sprints hinweg konstant sind.

Nachteil dieses Ansatzes ist, dass durch die Gewichtung der Anforderungsquellen eine Priorisierung im Gesamtunternehmenskontext verloren geht. Änderungen an den zugeteilten Entwicklungsressourcen sind ggf. aufwendig. Generell bietet der Ansatz eine geringere Flexibilität als bei alternativen Vorgehensweisen. Außerdem wirkt sich negativ aus, dass Features, welche die zugeteilten Ressourcen übersteigen, über mehrere Sprints aufgeteilt werden müssen. Hinzu kommt, dass Feature-Anfragen von Dritten (ohne zugewiesene Entwicklungsanteile) nur schwer abgebildet werden können. Im Falle potenzieller Leerlaufzeiten sind weitere Vergabeprozesse für freie Entwicklungskapazitäten nötig.

Agiler Run & Change: Priorisierungstoken

In diesem Priorisierungsansatz steht den Anforderungsgebern ein Vorrat an Priorisierungstokens zur Verfügung, welche sie unabhängig auf ihre jeweiligen Anforderungen im Feature-Backlog verteilen können. Bei der Überführung in den Umsetzungs-Backlog werden die Features entsprechend der Anzahl zugeordneter Priorisierungstokens in eine Rangordnung einsortiert. Der verantwortliche PO befüllt, basierend auf einer Grobschätzung des Entwicklungsaufwands, den Umsetzungs-Backlog entsprechend der Priorisierung so, dass eine hohe Auslastung der Entwicklungskapazitäten sichergestellt ist. Der Tokenvorrat jedes Anforderungsgebers wird nach unterschiedlichen Faktoren bzw. vereinbarten Verteilungsschlüsseln ermittelt (z. B. Tokens in jedem Sprint, nicht umgesetzte Tokens aus vorangegangen Sprints, Finanzierung der Entwicklungskapazitäten etc.).

Ein klarer Vorteil dieses Ansatzes ist die nachvollziehbare und transparente Aufteilung der Priorisierungsmacht. Gleichzeitig ist es Anforderungsgebern mit einer vergleichsweise niedrigen Priorisierungsmacht immer möglich, durch Akkumulation ihrer Tokens einer dedizierten Anforderung eine sehr hohe Priorität zuzuordnen.

Als Nachteil sind die Notwendigkeit einer starken Governance sowie einer ausgedehnten Toolunterstützung zur Vermeidung eines bürokratischen Overhead zu nennen. Auch lassen sich Feature-Anfragen von Dritten – ohne zugewiesenen Tokenvorrat – nur schwer abbilden. Des Weiteren orientiert sich die Priorisierung vorwiegend an Einzelinteressen der Anforderungsgeber, wodurch die übergreifenden und strategischen Ausrichtungen des Unternehmens bei der Priorisierung nur nachrangige Berücksichtigung finden.

Agiler Run & Change: Round Robin

Einen letzten möglichen Priorisierungsansatz stellt das „Round Robin“-Prinzip dar. Dabei wechseln die Verantwortlichkeit und das Management des Umsetzungs-Backlogs von Sprint zu Sprint zwischen den Anforderungsgebern. Jeder Anforderungsgeber kann in dem ihm zugeordneten Sprint alleine nach seinen eigenen Wünschen und Prioritäten Umsetzungsschwerpunkte setzen. Dabei übernimmt der jeweilige Anforderungsgeber für den nächsten Sprint die Rolle des PO. Umsetzungswünsche anderer Anforderungsgeber können dabei in Betracht gezogen werden.

Dieser Priorisierungsansatz bietet den Vorteil der Planungssicherheit. Anforderungsgeber wissen stets, wann ihnen die Entwicklungsressourcen zur Verfügung stehen. Dieser Ansatz gewährleistet klare Zuständigkeiten je Durchlauf des Requirements Funnel und vermindert einen möglichen Overhead in der Priorisierung von Features für die Sprint-Backlog-Priorisierung. Außerdem besteht für Anforderungsgeber die Möglichkeit spezifischer Releases nach jedem Sprintdurchlauf.

Nachteil bei diesem Ansatz ist, dass alle Anforderungsgeber in der Nutzung der Entwicklungsressourcen gleichgestellt sind, Stakeholder mit sporadischen Umsetzungsbedarfen jedoch nur schwer eingebunden werden können. Hervorzuheben sind außerdem die potenziell langen Wartezeit eines jeden Anforderungsgebers bis zur Umsetzung seiner eigenen Features. Deswegen eignet sich dieser Ansatz primär für eine geringe Anzahl an Anforderungsgebern (maximal vier).

Zusammenspiel im agilen Run mit der Entwicklung

Die vorgestellten Vorgehensmodelle fokussieren sich auf die Priorisierung der Anforderungen unter Berücksichtigung der Entwicklungskapazitäten.

Zentrales Ergebnis aller fünf hier dargestellten Priorisierungsansätze ist ein Umsetzungs-Backlog mit einer Feature-Priorisierung, die von allen Anforderungsgebern mitgetragen wird.

Zusätzlich zu diesen Features fließen in den Umsetzungs-Backlog aufgeworfene Probleme aus den Tests sowie Systemfehler aus dem Livebetrieb ein.

Auf Basis von Erfahrungen aus vergangenen Sprints, der für den bevorstehenden Sprint durchgeführten Kapazitätsplanung sowie der Definition of Done (DoD) wählt das Umsetzungsteam schließlich die priorisierten und umzusetzenden Features sowie aktuelle, zu behebende Systemfehler für den Sprint aus.

Zusätzlich kann es sinnvoll sein, einen Teil der Entwicklungskapazitäten für hochpriorisierte Ad-hoc-Themen zu reservieren.

Auswahl des passenden Priorisierungsansatzes

Die Auswahl des passenden agilen Priorisierungsansatzes hängt von verschiedenen Faktoren ab:

Agiler Run: Übersicht der Priorisierungsansätze

Bestehende Strukturen im Unternehmen sowie der Grad der Etablierung agiler Entwicklungsmethoden stellen dabei den Ausgangspunkt für die Weiterentwicklung bzw. Neugestaltung des Priorisierungsvorgehens dar.

Die Finanzierung der Entwicklungsressourcen ist ein weiterer Faktor, der bei der Gestaltung des Priorisierungsvorgehens zu berücksichtigen ist. So können die Anteile im Backlog-Split oder der Token-Verteilungsschlüssel auf den Finanzierungsanteilen beruhen.

Bei einer zentralen Finanzierung der Entwicklung bieten sich der klassische Product Owner oder ein Priorisierungsgremium an. Auch andere Finanzierungsmodelle sind denkbar (z. B. individuelle Bepreisung einzelner Features) und müssen institutsspezifisch entwickelt werden.

Eine dedizierte Analyse der aktuellen Situation, unter anderem unter Berücksichtigung der Fähigkeiten und Bereitschaft der Belegschaft, muss berücksichtig werden, wenn ein Priorisierungsansatz neu eingeführt oder auch weiterentwickelt werden soll.

zeb kann hier basierend auf einem breiten Erfahrungspool aus vorherigen Projekten unterstützen – von der Analyse der aktuellen Organisationsstruktur und -kultur hinsichtlich der Eignung der unterschiedlichen Priorisierungsmöglichkeiten über die individuelle Entwicklung und Konfiguration von Priorisierungsansätzen bis hin zur Einführung des Priorisierungsvorgehens und begleitender Governance.

Welchen agilen Ansatz setzen Sie in Ihrem Umfeld aktuell ein bzw. können Sie sich vorstellen einzusetzen?

Gerne stehen wir für weiterführende Gespräche und Diskussionen zur Verfügung.

Kontaktieren Sie uns jetzt!

Welchen agilen Ansatz setzen Sie in Ihrem Umfeld aktuell ein?

Sprechen Sie uns gerne an!

Autor Antje Axmann / BankingHub

Antje Axmann

Managerin Office Hamburg
Malte Ritzenhoff / Autor BankingHub

Malte Ritzenhoff

Manager Office Hamburg
Autor Lukas Genßler / BankingHub

Lukas Genßler

Consultant Office Wien

Analysen, Artikel, Interviews und News rund um Trends & Innovation im Banking alle zwei Wochen kompakt für ihr Postfach.

Kommentare

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht.

Abonnieren Sie unseren Newsletter

Erhalten Sie alle 2 Wochen die neuesten Analysen und Berichte unserer Banking-Experten.

Send this to a friend