Montagmorgen, 9:15 Uhr. Drei Projektmanager schreiben mir gleichzeitig. Kunde A will seinen Prototyp bis Donnerstag. Kunde B hat eine 'kleine Änderung' (Spoiler: die gibt es nie wirklich). Kunde C droht, die nächste Zahlung zu blockieren, wenn ein vor sechs Wochen versprochenes Feature nicht geliefert wird. Und das Backlog hat 74 Tickets, die seit dem letzten Sprint Planning niemand angerührt hat. Das ist die Realität von 90% der Digitalagenturen. Keine saubere Agile-Theorie aus Konferenzfolien.
Warum Ihr Backlog Wie Eine Mülldeponie Aussieht
Das Problem ist nicht das Arbeitsvolumen. Es fehlt ein gemeinsam getragenes Priorisierungskriterium. Jeder PM verteidigt sein Projekt, jeder Kunde schreit Feuer, und der Lead-Entwickler navigiert nach dem, was am stärksten blutet. Aufgaben mit hohem Impact aber ohne dringende Deadline sinken auf ewig ans Ende des Backlogs.
Methoden, Die Wirklich Funktionieren
MoSCoW: Einfach, Aber Fast Immer Falsch Angewendet
Must have, Should have, Could have, Won't have. Alle kennen es. Kaum jemand wendet es richtig an. Die klassische Falle: Kunden setzen alles auf Must have, weil sie nicht verstehen, dass das Ihre Sprint-Kapazität bindet. Die Lösung: MoSCoW mit einem Punktebudget validieren. Sie haben 40 Punkte pro Sprint. Jedes Must have kostet Punkte. Der Kunde entscheidet selbst, wenn das Budget ausgeschöpft ist. Das verändert die Dynamik grundlegend.
RICE: Das Framework, Das Ich Früher Hätte Kennen Wollen
RICE steht für Reach x Impact x Confidence / Effort. Ein numerischer Score pro Ticket. Das klingt kühl, eliminiert aber Ego-Debatten in Meetings. Sie müssen dem Gründer nicht mehr erklären, dass sein 'geniales' Feature eigentlich ein Could have ist. Der Score entscheidet. Ich habe ein Team erlebt, das das Sprint Planning von 2,5 Stunden auf 45 Minuten in drei Sprints reduziert hat, nachdem RICE eingeführt wurde.
Wir haben aufgehört, uns in Meetings zu streiten, als wir entschieden haben, dass RICE-Scores entscheiden, nicht die lauteste Stimme im Raum. Unsere Burn Rate sank in zwei Monaten um 22%. -- Produktionsleiter, E-Commerce-Agentur, Lyon, 2025.
Reale Kapazität: Die Zahl, Die Niemand Berechnet
Agenturen planen mit theoretischer Kapazität. 5 Entwickler x 5 Tage x 8h = 200 Sprint-Stunden. In der Realität, nach Standups, Code-Reviews und ungeplanten Kundengesprächen, sind es 120 bis 140 produktive Stunden. Das sind 30 bis 40% Verlust. Die reale Velocity über sechs rollende Sprints zu berechnen ist nicht optional. Clynt ermöglicht es, erfasste Stunden pro Projekt mit geplanter Kapazität zu vergleichen, um eine ehrliche Lageeinschätzung zu erhalten.
Priorisierung Zwischen Projekten: Die Echte Herausforderung
Wenn die Antwort auf 'Wer entscheidet?' lautet 'der, der am häufigsten anruft', haben Sie ein Governance-Problem, kein Methodenproblem. Eine praktische Regel: Gewichtung nach Bruttomargin x Churn-Risiko. Projekte mit niedriger Marge und volatilen Kunden rutschen nach unten. Strategische Accounts mit hoher Marge steigen. Das ist am Anfang unbequem, aber es bringt operative Entscheidungen in Einklang mit der echten Strategie.
- Bruttomargin pro Projekt wöchentlich berechnen, nicht quartalsweise
- Jedem aktiven Kundenkonto einen Churn-Risiko-Score (1-5) vergeben
- Beide multiplizieren, um einen projektübergreifenden Prioritätsindex zu erhalten
- Diesen Index alle zwei Wochen im Leitungsgremium überprüfen
FAQ
Welche Priorisierungsmethode eignet sich am besten für kleine Agenturen unter 10 Personen?
MoSCoW mit Punktebudget ist für kleine Teams am zugänglichsten. Es braucht kein spezielles Tool und lässt sich in Notion oder einer Tabellenkalkulation umsetzen. Entscheidend ist, die Spielregeln bereits beim Projekt-Kickoff mit dem Kunden festzulegen.
Wie überzeugen Sie einen Kunden, dass seine dringende Anfrage keine Priorität hat?
Zeigen Sie ihm das priorisierte Backlog mit bezifferten Business-Auswirkungen. Ein rationaler Kunde versteht, dass ein Feature für 3 Nutzer hinter einem Fix wartet, der 800 tägliche Bestellungen betrifft. Wenn Ihr Vertrag klare SLA-Stufen für Dringlichkeitsstufen enthält, ist es noch einfacher.
Sollte das interne Backlog der Agentur wirklich vom Kunden-Backlog getrennt werden?
Absolut. Das Vermischen beider erzeugt eine implizite Hierarchie, bei der Kundenarbeit immer gewinnt. Interne Verbesserungsaufgaben bekommen keinen Raum, wenn sie direkt gegen Kundenanforderungen konkurrieren. Zwei getrennte Bereiche, zwei getrennte Rituale.
Wie lässt sich die reale Velocity eines Teams in einer Multi-Projekt-Agentur messen?
Vergleichen Sie die tatsächlich erfassten Stunden für gelieferte Tickets mit der geplanten Kapazität über sechs rollende Sprints. Tools wie Clynt visualisieren diese Lücke nach Projekt und Profil, was belastbare Planung statt Bauchgefühl ermöglicht.