TL;DR: Ein Software-Unternehmer mit kleinem Entwicklerteam saß bei knapp 20 Meeting-Stunden pro Woche — und trotzdem wurden Features seit über einem Jahr nicht fertig. Die Ursache: Es gab keine echte Sprintplanung, nur permanente Abstimmung als Kompensation. Nach Einführung eines konkreten Sprint-Zyklus mit 30-Minuten-Daily verdoppelte das Team die Story Points pro Sprint.
20 Stunden Meetings, null Überblick
Ein Software-Unternehmer, seit über 20 Jahren am Markt, übernahm Ende 2023 selbst die Entwicklungsleitung. Was er vorfand: Sein Entwicklerteam verbrachte knapp 20 Stunden pro Woche in Meetings. 10 bis 15 Termine — Entwicklermeetings, Ticket Reviews, nochmal Entwicklermeetings. Features, die seit über einem Jahr offen waren, wurden trotzdem nicht fertig. Und ein Backend-Entwickler arbeitete losgelöst vom Rest des Teams vor sich hin.
Warum mehr Meetings das Problem verschärften
Der Inhaber ist Betriebswirt, kein Entwickler. Er vermutete zunächst, das Problem sei mangelnde Geschwindigkeit oder fehlende Disziplin. Im Coaching mit anne&thorsten. wurde sichtbar, was er selbst nicht benennen konnte: Es gab keine echte Sprintplanung. Kein gemeinsames Commitment auf konkrete Arbeitspakete. Keinen Mechanismus, der sichtbar machte, was in einer Iteration geschafft wurde — und warum der Rest liegen blieb.
Die 20 Meeting-Stunden pro Woche waren das Symptom. Das Team kompensierte fehlende Planung durch permanente Abstimmung. Jeder arbeitete an dem, was gerade dringend schien. Niemand konnte sagen, ob eine Woche erfolgreich war, weil es keinen Maßstab gab. Als Betriebswirt fehlte dem Inhaber die Sprache, um das Problem zu greifen: „Manchmal ist das wie Rauschen für mich gewesen."
Die Veränderung bestand aus drei konkreten Eingriffen: Ein Planungsmeeting alle drei Wochen, in dem Anforderungen und eigene Ideen mit konkretem Aufwand beplant werden. Ein 30-Minuten-Daily, das die bisherigen 10 bis 15 Meetings ersetzte — gestern, heute, Blocker. Und eine Sprint-Nachanalyse: Was haben wir geschafft? Was blieb liegen? Woran lag es? Die schwierigste Umstellung war, den Backend-Entwickler in den gemeinsamen Sprint zu holen — weg vom isolierten Vor-sich-hin-Arbeiten, rein in ein gemeinsames Commitment.
Warum Planung den Hebel hat — und Tempo nur das Ergebnis ist
Entwicklungseffizienz verdoppeln heißt für die meisten Inhaber: schneller coden, mehr Leute einstellen, bessere Tools einführen. Dieser Fall zeigt das Gegenteil. Die Geschwindigkeit des Teams war nie das Problem. Das Problem war, dass niemand wusste, woran gemessen wird.
Wenn ein Entwicklerteam ohne Sprint-Commitment arbeitet, passiert etwas Vorhersagbares: Jeder zieht sich das Ticket, das gerade am lautesten schreit. Halbfertige Features bleiben liegen, weil das nächste Dringliche dazwischenkommt. Und weil es keinen Abschluss-Rhythmus gibt, fehlt das Signal „fertig" — für das Team und für den Inhaber.
Die Meeting-Explosion ist die logische Folge. Wo kein Plan existiert, muss ständig abgestimmt werden. Jedes ungeplante Ticket erzeugt eine Rückfrage, jede Rückfrage ein Meeting, jedes Meeting eine Unterbrechung. Das Team arbeitet den ganzen Tag und geht trotzdem nicht voran. Das ist ein Strukturproblem, kein Motivationsproblem.
Der Sprint-Zyklus löst genau diesen Kreislauf auf. Ein gemeinsames Planungsmeeting erzeugt Verbindlichkeit — das Team weiß, was in den nächsten drei Wochen geschafft werden soll. Das kurze Daily ersetzt die permanente Ad-hoc-Abstimmung. Und die Nachanalyse macht sichtbar, wo der Engpass sitzt — ob ein Ticket zu groß geschätzt war, ob Abhängigkeiten blockiert haben oder ob die Anforderung unklar war. Innerhalb von sechs Monaten verdoppelte sich die Teamleistung, ohne einen einzigen neuen Entwickler.
Was Du diese Woche messen kannst
Zähl die Meeting-Stunden Deines Entwicklerteams in einer normalen Woche. Alles zusammen — Dailys, Reviews, Plannings, Ad-hoc-Abstimmungen, Slack-Huddles. Wenn die Zahl über 10 Stunden pro Entwickler liegt und Du gleichzeitig das Gefühl hast, dass Features zu langsam fertig werden: Das ist wahrscheinlich kein Tempo-Problem. Du kompensierst fehlende Planung mit Koordination.
Wenn Du schauen willst, wo bei Dir gerade der größte Hebel liegt — wir machen das in 60 Minuten, kostenlos.
Lieber erstmal selbst durcharbeiten? Der 12-Wochen-Kurs hat die komplette Methode als Online-Modul. Einmalzahlung 199 €, dauerhaft verfügbar.
Häufige Fragen
Wie lange dauert es, bis eine neue Sprintplanung die Entwickler-Effizienz spürbar steigert?
Im beschriebenen Fall dauerte es etwa sechs Monate, bis der Sprint-Zyklus stabil lief und die Story Points pro Sprint sich verdoppelt hatten. Die ersten Verbesserungen — weniger Meetings, klarere Priorisierung — zeigen sich innerhalb der ersten zwei bis drei Sprints.
Funktioniert das auch, wenn der Inhaber keinen technischen Hintergrund hat?
Gerade dann. Der Inhaber in diesem Fall ist Betriebswirt. Die Sprintplanung gibt ihm einen Überblick über den Fortschritt, ohne jeden Pull Request verstehen zu müssen. Er kann Ergebnisse messen — Story Points pro Sprint sind ein Maßstab, der keine Code-Kenntnisse voraussetzt.
Mein Team hat schon Sprints, aber die Story Points stagnieren. Wo liegt der Hebel?
Prüfe, ob es ein echtes Sprint-Commitment gibt oder ob der Sprint nur ein Zeitfenster ist, in dem jeder an seinen eigenen Prioritäten arbeitet. Der zweite Check: Gibt es eine Nachanalyse, die sichtbar macht, warum Tickets liegen geblieben sind? Ohne dieses Feedback fehlt dem Team die Information, um besser zu planen.
Brauche ich neue Tools, um die Story Points pro Sprint zu steigern?
Selten. Die meisten Teams haben Jira, Azure DevOps oder ein vergleichbares Board. Das Problem sitzt im Prozess — fehlende Planung, fehlende Nachanalyse, fehlende Verbindlichkeit. Ein neues Tool auf einen kaputten Prozess draufzusetzen beschleunigt das Chaos.