Warum Priorisierung in agilen Organisationen oft nicht funktioniert

Das Bild, das sich immer wieder zeigt

Backlog-Refinement beginnt. Vier Tickets sind bereits in Bearbeitung, sieben warten auf Klärung, zwei kommen direkt vom CEO. Der Product Owner fragt: „Was hat Priorität?“ Die Antwort aus drei verschiedenen Richtungen lautet: „Alles ist dringend.“

Dieses Muster ist nicht ungewöhnlich. Es wiederholt sich in Unternehmen jeder Größe, mit Scrum wie mit Kanban, mit erfahrenen wie mit unerfahrenen Teams. Es ist kein Zeichen von Inkompetenz — es ist ein Zeichen, dass das System falsch verdrahtet ist.

Die sichtbaren Symptome

Bevor man versteht, warum Priorisierung nicht funktioniert, lohnt es sich, die Symptome genau zu benennen:

• Der Backlog wächst schneller, als er abgearbeitet wird.
• Jeder Sprint enthält Arbeit aus mindestens drei verschiedenen Richtungen — Business, Tech, Compliance — ohne klare Gewichtung.
• Technische Schuld wird immer wieder nach hinten verschoben, weil es gerade wichtigere Anforderungen gibt.
• Der Product Owner schreibt Tickets um und formuliert Begründungen, aber ändert nichts an der tatsächlichen Reihenfolge.
• Führungskräfte fragen im Sprint Review: „Warum ist das noch nicht fertig?“ — obwohl sie selbst Aufgaben mit Vorrang eingesteuert haben.

Was wirklich dahintersteckt: Es ist kein Backlog-Problem

Das häufigste Missverständnis: Priorisierung scheitert, weil der Backlog unordentlich ist, die User Stories schlecht formuliert sind oder der Product Owner nicht genug Methoden kennt. Das ist selten der eigentliche Grund.

Der eigentliche Grund: Priorisierung setzt voraus, dass jemand in der Organisation das Mandat hat, Nein zu sagen. Wenn dieser Jemand fehlt — oder wenn das Mandat faktisch nicht ausgeübt werden kann, weil jede Ablehnung zu einem Eskalationsrisiko wird —, dann ist kein Priorisierungssystem der Welt stark genug, das auszugleichen.

Die Führungsdimension: Wer hat eigentlich das Mandat?

In den meisten Organisationen ist die Antwort auf diese Frage unklar. Formal liegt sie beim Product Owner. Faktisch konkurrieren mehrere Stakeholder darum, ihre Anforderungen im nächsten Sprint zu sehen — und der PO hat keine ausreichende Rückendeckung, um diese Konkurrenz strukturiert aufzulösen.

Führungskräfte, die das System verbessern wollen, stellen deshalb zunächst diese Frage: Wer hat das Mandat, Prioritäten zu setzen, und zwar so, dass diese Entscheidung für alle Stakeholder verbindlich ist? Solange diese Frage nicht beantwortet ist, bleibt Priorisierung ein lokales Problem des POs — obwohl es ein globales Problem der Führung ist.

Wie technische Schuld entsteht — und warum sie keine Überraschung ist

Technische Schuld ist oft die direkte Konsequenz fehlgeschlagener Priorisierung. Jedes Mal, wenn eine echte Priorisierungsentscheidung zugunsten einer kurzfristigen Business-Anforderung umgangen wird, verschieben sich Refactoring, Testabdeckung und Infrastruktur-Updates in die Zukunft.

Das ist keine bewusste Entscheidung — es ist das Ergebnis einer Struktur, in der kurzfristiger Stakeholder-Druck systematisch mehr Gewicht hat als langfristige Systemstabilität. Wenn keine Führungskraft das Gewicht auf die andere Seite der Waage legt, kippt die Waage immer in dieselbe Richtung.

Priorisierung ist eine Systemeigenschaft, keine persönliche Fähigkeit

Das ist der entscheidende Perspektivwechsel: Priorisierung ist keine Fähigkeit, die der Product Owner trainieren muss. Sie ist eine Eigenschaft des Systems — und das System besteht aus Entscheidungsstrukturen, Mandaten, Eskalationswegen und dem Verhalten von Führungskräften in Konfliktsituationen.

Ein gut priorisierendes System hat klare Antworten auf diese Fragen: Wer entscheidet, wenn Stakeholder verschiedener Gewichtung um denselben Slot konkurrieren? Was passiert, wenn Priorisierung eine wichtige Person enttäuscht? Wie wird technische Schuld gleichwertig sichtbar neben Business-Anforderungen?

Wenn diese Fragen nicht beantwortet sind, helfen Priorisierungs-Frameworks — MoSCoW, WSJF, RICE — nur dabei, das Chaos besser zu dokumentieren. Sie lösen das Problem nicht.

Erste Schritte: Was wirklich hilft

Der erste Schritt ist keine Methodeneinführung. Er ist eine ehrliche Diagnose: Wer hat in deiner Organisation faktisch das Mandat, Prioritäten durchzusetzen — auch wenn das bedeutet, dass ein wichtiger Stakeholder leer ausgeht?

Konkret bedeutet das:

• Klären, ob der PO ein echtes Entscheidungsmandat hat — und wenn nicht, wer es hat und wie es an den PO delegiert werden kann.
• Führungskräfte einbinden: Sie müssen das Priorisierungsergebnis aktiv stützen — nicht just formell zustimmen, sondern auch gegenüber Stakeholdern vertreten.
• Technische Schuld sichtbar machen: Sie gehört als explizite Kategorie in den Backlog — mit eigener Priorisierungslogik, nicht als Auffangbehälter für alles, was sich nicht anders einordnen lässt.
• Eskalationsweg vereinbaren: Was passiert, wenn ein Stakeholder die Priorisierungsentscheidung nicht akzeptiert? Wer entscheidet dann? Das muss vorab geklärt sein, nicht im Konfliktfall.

Die strukturierte Diagnose als Einstieg

Bevor man Priorisierungssysteme ändert, lohnt es sich, das Problem zu verstehen — in seiner konkreten Ausprägung in der eigenen Organisation. Woran liegt es wirklich? An fehlenden Mandaten? An einer Führungskultur, die Stakeholder-Druck in Sprint-Inhalt umwandelt? An Anforderungen, die beim Eingang bereits viel zu groß und vage sind?

Die Antworten sehen je nach Kontext sehr unterschiedlich aus. Deshalb beginnt wirksame Unterstützung immer mit einer strukturierten Analyse der tatsächlichen Situation — nicht mit einer vorgefertigten Methode.