| Autor: Florian Kittel
Im ersten Teil haben wir die strukturellen Spannungen zwischen klassischem Scrum und KI beleuchtet. Jetzt geht es um die entscheidende Frage:
Was können Teams heute konkret tun – ohne ihr gesamtes Organisationsmodell zu zerlegen?
Die Antwort ist banal – und genau deshalb wird sie in den meisten Organisationen systematisch übersehen: Scrum muss nicht ersetzt werden. Es muss präzise erweitert werden.
Zwei Stunden Meeting. Kaum belastbare Erkenntnis. Typischerweise dauert ein Planning so lange; der Großteil entfällt auf Schätzungen ohne belastbare Basis. Die Zeit fließt in Zerlegung und Aufwandsbewertung – beides basiert auf implizitem Wissen und Bauchgefühl. Abhängigkeiten bleiben unscharf, technische Risiken werden zu spät sichtbar.
Genau hier setzt KI an: Sie übernimmt die mechanische Zerlegung und macht Risiken früh sichtbar.
KI übernimmt einen Großteil der mechanischen Denkarbeit: Sie leitet technische Task-Strukturen aus User Stories ab, macht Abhängigkeiten sichtbar, schlägt Akzeptanzkriterien vor und analysiert historische Muster aus Jira-Daten. Daraus entstehen belastbare Hinweise darauf, wo ein Sprint kippen kann.
Story Points verlieren an Bedeutung. Risiko übernimmt. Wo fehlt Kontext? Wo entstehen regulatorische Risiken? Welche Abhängigkeit gefährdet den Sprint?
Das Meeting kippt: weg von Verwaltung, hin zu Risikoentscheidungen.
Der Entwickler ist kein Implementierer mehr. Er ist Orchestrator.
Früher: linear. Heute: parallel und überlappend – Implementierung, Tests, Refactoring und Dokumentation entstehen gleichzeitig. Code-Vorschläge, Unit-Tests, Edge Cases sowie Architektur- und Security-Hinweise laufen in einem durchgehenden Fluss.
Der Engpass ist nicht mehr Code. Er ist Urteilskraft in der Validierung.
Entscheidend ist nicht, wie schnell Code entsteht, sondern wie präzise Kontext formuliert, Ergebnisse geprüft und Domänenlogik modelliert werden. Architektur-Konsistenz wird zur zentralen Disziplin. Wer hier nur Effizienz sieht, hat das Modell nicht verstanden – und wird es falsch einsetzen. Es ist ein klares Skill-Upgrade.
Testing bricht Sprints. Im klassischen Scrum ist es ein nachgelagerter Engpass: Tests werden in die letzten Sprint-Tage gedrückt, manuelle Testfälle kosten Zeit, Regression wird teuer. Dieser Flaschenhals verschwindet. Vorausgesetzt, KI wird konsequent genutzt.
Tests entstehen parallel zur Implementierung: Unit- und Integrationstests werden generiert, Edge- und Negativfälle ergänzt, Testlücken sichtbar gemacht und bestehende Tests kontinuierlich modernisiert.
Qualität ist kein Sprint-Ende mehr. Sie ist permanent.
Gerade in regulierten Umfeldern wird das zum Vorteil: Die Audit-Fähigkeit steigt, weil Tests reproduzierbar generiert und sauber dokumentiert werden.
Reviews sind oft Show statt Substanz – und jeder im Raum weiß es, Retrospektiven emotional statt analytisch – und jeder im Raum weiß es. Entscheidungen basieren auf Wahrnehmung, nicht auf belastbaren Daten.
KI macht sichtbar, wo Arbeit tatsächlich stecken bleibt.
Commit-Frequenzen, Durchlaufzeiten, Ticket-Stagnation oder wiederkehrende Blocker werden analysiert und verdichtet. Die Diskussion kippt: weg vom Gefühl, hin zu klaren Mustern. Wenn 30 % der Stories regelmäßig in der Review-Phase hängen, ist das kein Zufall, sondern ein systemisches Problem.
Scrum wird messbar – ohne in Kontrolle umzuschlagen, weil Muster sichtbar werden und nicht einzelne Personen überwacht werden.
Der größte ungenutzte Hebel liegt in Jira und Confluence selbst. Heute verwaltet Jira Arbeit und Confluence dokumentiert Wissen – dazwischen geht Kontext verloren.
KI verknüpft beide Systeme so, dass Informationen nicht mehr verloren gehen.
Stories werden automatisch angereichert, Abhängigkeiten sichtbar gemacht, Entscheidungsprotokolle verdichtet und Wissen systematisch verknüpft. Entscheidend ist die Ausgangsqualität: KI verstärkt, was da ist. Schlechte Backlogs werden nicht besser – nur schneller schlimmer.
Kein Re-Org, kein neues Framework, keine Ausreden. Die meisten Hebel erfordern keinen Organisationsumbau, sondern eine saubere Arbeitsroutine.
Backlog-Refinement (pro Story):
Ergebnis: Aus einer vagen Story wird ein prüfbarer Auftrag mit konkreten Fragen (z. B. ausländische Adressen, Pflichtfelder, betroffene Systeme).
Umsetzung im Sprint (pro Task):
Beispiel: Aus „IBAN muss korrekt sein“ entstehen sofort Positiv-, Negativ- und Grenzfalltests statt einer offenen To-do-Notiz.
Retro & Architektur-Checks (pro Sprint):
Beispiel: Neue Logik wird automatisch gegen Schichtentrennung gespiegelt und mögliche Kopplung sichtbar gemacht.
So wird KI im Alltag nutzbar: als feste Schablone pro Arbeitsschritt – nicht als Zusatzspielzeug.
Das Ergebnis: kürzere Planings, weniger technische Schulden, schnellere Feedback-Loops, höhere Code-Qualität und geringere Koordinationskosten.
Scrum bleibt. Aber es wird ein anderes System.
Die Gefahr ist nicht KI. Wird KI als Autocomplete verstanden, bleibt das System unverändert – es produziert nur schneller.
Die Folgen sind absehbar:
KI ist kein Ersatz für Produktdenken.
Das ist keine Theorie mehr. AI-Augmented Scrum ist umsetzbar – nicht als Revolution, sondern als strukturelle Effizienzsteigerung.
Und genau hier beginnt sie.
Die eigentliche Transformation:
Nicht mehr „Wie verbessert KI Scrum?“
Sondern:
„Wie sieht ein Organisationsmodell aus, das von Anfang an mit KI gedacht ist?“
Diese war Artikel 2 einer Serie bestehend aus 3 Artikeln.
Copyright © Florian Kittel. Alle Rechte vorbehalten. Impressum & Datenschutz
Alle verwendete Firmen-, Markennamen und Warenzeich en sind Eigentum der jeweiligen Inhaber und dienen lediglich zur Identifikation und Beschreibung der Produkte und Dienstleistungen.