Agile Anforderungspriorisierung – „who comes first?“

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.

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.

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.

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.

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).