Feature-Backlog wächst jeden Monat? So bringst du die Lieferung wieder in Schwung – ohne Neueinstellung

Wenn das Geschäft auf die IT wartet

Die meisten Führungsteams bemerken das Problem auf die gleiche Weise: Eine Anfrage geht im Januar in die Warteschlange, ist im April immer noch offen, und niemand auf der Geschäftsseite kann sagen, warum. Ein Feature-Backlog, der jeden Monat wächst, ist selten ein Zeichen dafür, dass das Entwicklungsteam faul oder nachlässig ist. Fast immer ist es ein Zeichen dafür, dass die Nachfrage nach Änderungen die verfügbaren Stunden überholt hat - und niemand hat sich die Zeit genommen, herauszufinden, welche Anfragen wirklich zuerst bearbeitet werden müssen.

Der Reflex an diesem Punkt ist meist, einzustellen. Eine Stelle für einen Entwickler ausschreiben, sechs bis zehn Wochen auf den richtigen Kandidaten warten, noch ein bis zwei Monate investieren, bis er produktiv ist, und hoffen, dass der Backlog schrumpft, sobald er eingearbeitet ist. Dieser Weg funktioniert irgendwann, aber er ist langsam, und er bindet das Unternehmen an fixe Kosten, bevor überhaupt bestätigt wurde, dass eine Festanstellung tatsächlich das ist, was das Problem braucht. Es gibt oft einen schnelleren Weg, die Lieferung wieder in Gang zu bringen, und er beginnt mit Triage statt mit Recruiting.

Warum Backlogs wachsen, selbst wenn das Team hart arbeitet

Ein Backlog, der stetig wächst, statt um ein einzelnes schlechtes Quartal herum auszuschlagen, deutet meist auf eine strukturelle Fehlpassung hin statt auf eine einmalige Krise. Drei Muster treten immer wieder in Unternehmen auf, die mit einem Software-Backlog zu kämpfen haben, der mit der aktuellen Kapazität nicht abzuarbeiten ist.

Die Warteschlange hat keine echte Priorisierung, sodass alles als gleich dringend behandelt wird. Wenn Vertrieb, Support und Product Owner alle Tickets hinzufügen können, ohne dass jemand sie gegeneinander einordnet, endet das Entwicklungsteam damit, zwischen einem Dutzend halbfertiger Stränge hin- und herzuwechseln, statt irgendetwas vollständig zu liefern.

Die Codebasis ist schwerer zu ändern geworden. Features, die früher zwei Tage brauchten, dauern jetzt eine Woche - nicht weil das Team langsamer geworden ist, sondern weil Jahre voller Abkürzungen und undokumentierter Workarounds jede Änderung riskanter und jede Schätzung unzuverlässiger gemacht haben. Das ist ein verdeckter Entwicklungskapazitätsmangel: Die aufgewendeten Stunden sind gleich geblieben, aber ein viel größerer Teil davon fließt ins Umschiffen des bestehenden Codes statt in den Bau des Neuen.

Und das Team trägt Arbeit, die überhaupt keinen Entwickler braucht. Konfigurationsänderungen, Content-Updates und einfache Bug-Triage sitzen oft in derselben Warteschlange wie wirklich komplexe Engineering-Arbeit und konkurrieren um dieselben Stunden, weil niemand die beiden Kategorien getrennt hat.

Triage, bevor du Personal aufbaust

Bevor du entscheidest, dass die Antwort eine Neueinstellung ist, lohnt es sich, eine Woche damit zu verbringen, den Backlog in Kategorien zu sortieren, die wirklich etwas aussagen.

Teile die Tickets zunächst in drei Gruppen auf: Arbeit, die Umsatz oder eine zugesagte Kundenfrist blockiert, Arbeit, die wertvoll, aber nicht dringend ist, und Arbeit, die vor allem existiert, weil es einfach war, sie auf eine Liste zu setzen. In den meisten Backlogs, die wir uns ansehen, ist die dritte Gruppe größer, als irgendjemand auf der Geschäftsseite erwartet - oft ein Drittel der offenen Tickets.

Trenne die Tickets anschließend danach, ob sie wirklich einen Entwickler brauchen oder von jemandem mit weniger spezialisierten Fähigkeiten erledigt werden könnten: einem technischen Projektmanager, einem Teilzeit-Freelancer oder in manchen Fällen einem Power-User auf der Geschäftsseite mit einfachem Admin-Zugang. Nicht jedes offene Ticket ist ein Coding-Problem.

Schließlich: Schau dir das Alter an. Ein Ticket, das seit vier Monaten unberührt liegt, ohne dass jemand danach gefragt hat, ist schon für sich ein nützliches Signal. Entweder war es nie wirklich wichtig - dann sollte es geschlossen werden - oder es blockiert still etwas, das dem Geschäft wichtig ist, und niemand hat es eskaliert. Beides lohnt sich zu wissen, bevor du Budget für die Lösung eines Einstellungsproblems bindest, das in Wirklichkeit ein Priorisierungsproblem sein könnte.

Genau hier zahlt sich auch ein kurzes externes Code-Quality-Consulting-Engagement schnell aus: Jemand ohne Eigeninteresse an der Geschichte des Backlogs kann sich die Warteschlange und die Codebasis gemeinsam ansehen und dir ehrlich sagen, ob der Flaschenhals Kapazität, Codequalität oder Prozess ist.

Was ein externer Entwickler zuerst übernehmen kann

Bestätigt die Triage, dass das Team tatsächlich nicht genug Stunden hat, lässt sich externe Kapazität meist schneller organisieren als eine Festanstellung und leichter wieder zurückfahren, falls die Nachfrage sinkt. Die Frage ist, was zuerst übergeben wird.

Der sicherste Startpunkt sind die Backlog-Einträge, die du bereits als wertvoll, aber nicht dringend markiert hast - die Tickets, die seit Wochen liegen, weil das Kernteam zwischen den ständigen Brandherden nie dazu kommt. Diese zu übergeben erfordert kein tiefes institutionelles Wissen und gibt einem externen Entwickler eine risikoarme Möglichkeit zu beweisen, dass er deine Codebasis versteht, bevor du ihm etwas Kundenkritisches anvertraust.

Von dort aus sind Bugfixes und kleinere, klar definierte Features ein natürlicher zweiter Schritt. Sie haben klare Abnahmekriterien, was es leicht macht zu prüfen, ob die Arbeit tatsächlich gut gemacht wurde, und sie bauen eine Erfolgsbilanz auf, ohne dass der externe Entwickler die gesamte Produkt-Roadmap verstehen muss.

Größere Stücke der Webanwendungsentwicklung, die zentrale Workflows betreffen oder echtes architektonisches Urteilsvermögen verlangen, sollten in der Regel zurückgehalten werden, bis der externe Entwickler eine Handvoll kleinerer Punkte geliefert hat und dein eigenes Team seinem Urteil vertraut. Diese Reihenfolge schützt dich vor der schlimmsten Version dieser Konstellation, in der jemand, der das System nicht kennt, in seiner ersten Woche eine riskante Änderung an etwas Wichtigem vornimmt.

Fortschritt gegenüber dem Management innerhalb von 30 Tagen zeigen

Ein Grund, warum Unternehmen standardmäßig auf Einstellungen setzen, ist, dass es sich leicht gegenüber der Führung erklären lässt: "Wir haben jemanden eingestellt, er wird gerade eingearbeitet." Stattdessen flexible externe Kapazität hereinzuholen erfordert etwas bewusstere Kommunikation, aber es ist durchaus möglich, innerhalb eines Monats echten, sichtbaren Fortschritt zu zeigen.

In Woche eins veröffentlichst du die Triage-Ergebnisse. Eine einfache Aufschlüsselung, wie viele Tickets wirklich Umsatz blockieren, wie viele "nice to have" sind und wie viele abgestanden genug waren, um sie zu schließen, gibt der Führung ein konkretes Bild der tatsächlichen Form des Backlogs - oft zum ersten Mal.

In den Wochen zwei und drei lieferst du die erste Charge kleinerer Punkte aus der Gruppe "wertvoll, aber nicht dringend" aus. Diese werden gezielt ausgewählt, weil sie für das Geschäft sichtbar sind: ein Reporting-Fix, nach dem seit Monaten jemand fragt, ein Workflow, der ständig Support-Tickets erzeugt. Eine Handvoll davon innerhalb von zwei Wochen abzuschließen, ist ein weit überzeugenderes Signal für das Management als eine Stellenanforderung, die bei der Personalabteilung liegt.

Bis Woche vier solltest du eine Kurzliste dessen haben, was jetzt nicht mehr blockiert ist, und ein klares Bild davon, ob die zusätzliche Kapazität weiterlaufen, ausgebaut oder zurückgefahren werden muss. Diese Entscheidung, getroffen auf Basis echter Liefer-Daten statt einer Einstellungs-Vermutung, ist eine weit stärkere Position, als sich auf ein Gehalt festzulegen, bevor überhaupt bestätigt wurde, was das Problem eigentlich war.

Wenn eine Einstellung trotzdem die richtige Entscheidung ist

Nichts davon ist ein Argument dagegen, jemals einzustellen. Zeigt die Triage anhaltende, wachsende Nachfrage über alle Kategorien hinweg, und braucht die Arbeit wirklich jemanden, der langfristig fest im Produkt und im Team verankert ist, ist eine Festanstellung die richtige Antwort - und externe Kapazität ist die Brücke dorthin, damit sich der Backlog während des Recruitings nicht weiter verschlechtert.

Es geht um die richtige Reihenfolge. Den Backlog zu diagnostizieren und externe Kapazität an Arbeit mit geringerem Risiko zu testen, dauert ein paar Wochen und sagt dir mit echten Belegen, welche Art von Kapazitätsproblem du hast. Sich aufgrund einer Vermutung auf eine sechsstellige Einstellung festzulegen, tut das nicht. Diese Reihenfolge richtig zu treffen, macht meist den Unterschied zwischen einem Backlog, der ein weiteres Jahr wächst, und einem, der innerhalb eines Monats sichtbar zu schrumpfen beginnt.

Wenn dein Feature-Backlog schon länger wächst und niemand Zeit hatte, ihn richtig zu triagieren, melde dich unter hello@wolf-tech.io oder besuche wolf-tech.io. Eine kurze Einschätzung reicht oft aus, um zu sagen, ob die Lösung Kapazität, Priorisierung oder die Codebasis selbst ist.