Neulich in einer Session mit Claude: Wir arbeiten an einem Thema, ich habe eine Idee für eine neue Anforderung, und mir fällt sofort auf, dass ich genau das schon mal erlebt habe. In einem früheren Projekt stand genau diese Anforderung auf dem Tisch, hat Zustimmung bekommen, und wurde dann zurückgestellt. Zu komplex, zu unscharf, zu viel Risiko. Das kennt jeder, der schon mal in einem Backlog-Grooming gesessen hat.

Aber diesmal war mein erster Gedanke: Wir haben jetzt KI. KI ist schnell. Und KI kann auch komplex. Also, warum nicht einfach machen?

Wer schon mal in einem Backlog-Grooming gesessen hat, kennt den anderen Satz auch: Jemand wirft eine Idee in die Runde, alle finden sie gut, und dann kommt „Wäre schön, aber das ist uns gerade zu aufwendig.“ Das Issue landet im Backlog, wandert irgendwann nach unten, und irgendwann fragt keiner mehr danach.

Das war lange ein strukturelles Problem in der Softwareentwicklung. Anforderungen entstehen oft schneller als sie umgesetzt werden können, also wird priorisiert. Und das bedeutet meistens: Die einfachen Dinge kommen durch, die komplexen bleiben liegen.

Mit KI im Entwicklungsprozess verschiebt sich dieses Verhältnis.

Das Bottleneck war nie das Schreiben von Code

Wenn ich ehrlich bin, war das Schreiben von Code selten das eigentliche Problem. Klar, es hat Zeit gekostet, aber die meisten Verzögerungen lagen woanders: in der Abstimmung, im Hin-und-Her über Details, im „Ich muss das erst noch verstehen, bevor ich loslegen kann.“

Mit KI-gestützter Entwicklung wird der eigentliche Coding-Teil deutlich schneller. Ich kann ein Feature implementieren, das ich früher zwei Tage Einarbeitung gekostet hätte, jetzt an einem Nachmittag ausprobieren. Das klingt nach einem quantitativen Unterschied, ist aber in der Praxis ein qualitativer.

Denn plötzlich lohnt es sich, Dinge auszuprobieren, die vorher zu riskant oder zu aufwendig gewesen wären.

Die Sandbox als neues Planungswerkzeug

Ein Gedanke, der mir dabei immer wichtiger wird: die Sandbox.

Früher hat man Features im Kopf oder auf dem Papier durchgespielt, bevor man angefangen hat zu bauen. Heute kann ich innerhalb weniger Stunden eine funktionierende Prototyp-Implementierung haben, an der ich wirklich sehen kann, ob eine Idee trägt. Nicht im Diagramm, sondern im laufenden Code.

Das verändert, wie man über Anforderungen nachdenkt. Statt endlos zu diskutieren, ob ein Feature sinnvoll ist, kann ich es einfach bauen und ausprobieren. Wenn es nicht funktioniert, war der Aufwand überschaubar. Wenn es funktioniert, hat man auf einmal eine Grundlage für eine echte Anforderung, die auf realen Erfahrungen basiert.

Diese Art von „bauen, um zu verstehen“ war vorher zu teuer. Jetzt ist sie ein legitimes Werkzeug in der Produktentwicklung.

Was das für das Anforderungsmanagement bedeutet

Das klassische Backlog-Grooming geht davon aus, dass Entwicklungskapazität die knappe Ressource ist. Also wird priorisiert, was in die Kapazität passt. Komplexe Features verlieren dabei fast immer, weil das Risiko zu hoch und der Aufwand zu unscharf ist.

Wenn Entwicklungsgeschwindigkeit steigt, kehrt sich das um. Plötzlich wird Klarheit zur knappen Ressource. Die Frage ist nicht mehr „Haben wir die Kapazität?“, sondern „Wissen wir genau genug, was wir wollen?“

Das bedeutet, dass gutes Anforderungsmanagement heute anders aussehen muss. Weniger Diskussion über hypothetische Aufwände, mehr schnelle Iterationen mit echtem Code. Weniger „Wäre schön, aber zu komplex“, mehr „Lass uns das in einer Sandbox ausprobieren und dann entscheiden.“

Die Ideen, die im Backlog geblieben sind

Ich denke dabei konkret an Dinge, die ich selbst schon erlebt habe. Features, die in einer Ideen-Session aufgetaucht sind und sofort Zustimmung bekommen haben, aber dann doch zurückgestellt wurden, weil sie „zu aufwendig“ waren. In einigen Fällen war das berechtigt. In anderen war es einfach eine Einschätzung auf Basis von Erfahrungswerten, die mit KI-gestützter Entwicklung nicht mehr stimmen.

Das heißt, es lohnt sich, den eigenen Backlog mit neuen Augen anzuschauen. Was damals zu komplex war, ist heute vielleicht ein Nachmittags-Projekt.

Und das ist, finde ich, einer der spannendsten Aspekte von KI in der Entwicklung. Nicht, dass sie bestehende Arbeit schneller macht. Sondern dass sie Arbeit möglich macht, die vorher gar nicht erst angefangen wurde.

Wo das hinführt

Ich glaube nicht, dass KI das Anforderungsmanagement überflüssig macht. Gutes Denken darüber, was ein Produkt leisten soll und für wen, bleibt wichtig. Aber die Gewichte verschieben sich.

Der Engpass ist nicht mehr der Code. Er ist die Klarheit darüber, was man eigentlich will. Und das ist, ehrlich gesagt, die interessantere Frage.

Also: Wenn du das nächste Mal in einem Grooming sitzt und jemand sagt „Wäre schön, aber zu komplex“, lohnt es sich, kurz nachzufragen, ob das wirklich noch stimmt.

Vielleicht ist es inzwischen ein Sandbox-Nachmittag.