Wie drei Jira-Spalten Release-Prognosen sabotieren – und wie Scrum Teams ihr Board reparieren

Дата публикации: 28-07-2026 06:00:00

Wenn Unternehmen mich anfragen, klingt das häufig so:„Teams sollen verlässlicher liefern. Termine müssen eingehalten werden. Releases müssen planbar werden.“Hinter jedem verpassten Termin stehen Budget, Marktchancen, Kundenvertrauen und strategische Entscheidungen.Eine Analyse von McKinsey und der University of Oxford hat mehr als 5400 große IT-Projekte ausgewertet und kommt zu einem ernüchternden Ergebnis: Große IT-Vorhaben überziehen ihr Budget im Schnitt um 45 Prozent, ihre Zeit um 7 Prozent und liefern dabei 56 Prozent weniger Wert als ursprünglich erwartet. Die CHAOS Reports der Standish Group ergänzen dieses Bild: Je nach Jahr und Definition gilt nur rund ein Drittel aller Softwareprojekte als erfolgreich. Im CHAOS Report 2020 werden 31 Prozent der Softwareprojekte als erfolgreich, 50 Prozent als „challenged“ und 19 Prozent als gescheitert eingeordnet. Das bedeutet: Rund zwei Drittel verfehlen Budget, Zeit, erwarteten Nutzen oder werden ganz abgebrochen.Die übliche Diagnose lautet: Die Teams müssen besser schätzen.Natürlich stammt diese Diagnose aus der Pre-Agile-Ära. Der Mythos, dass Komplexität sich durch bessere Planung beherrschen lässt, ist allerdings in den meisten Unternehmen auch im Jahr 2026 noch allgegenwärtig. Der Forscher Magne Jørgensen hat das nach jahrelanger unabhängiger Analyse auf den Punkt gebracht: Das Problem liegt nicht in der Schätzmethode, sondern darin, dass Entwickler Aufgaben systematisch unterschätzen. Egal ob in Story-Points oder Stunden. Wir können die Methode wechseln, so oft wir wollen. Das Grundproblem bleibt: Menschliche Intuition ist denkbar ungeeignet für präzise Vorhersagen der Zukunft.Wer die Liefertreue von Teams ernsthaft verbessern will, sollte umdenken.Das eigentliche Problem liegt woanders.Sobald wir einen Blick auf das Scrum-Board werfen, wird es offensichtlich:Ein Eintrag ist seit 50 Tagen in „Doing“.14 Einträge stehen gleichzeitig in „Doing“.In der „Done“-Spalte hängt ein Ticket, das nach zwei Stunden fertig war.Auf dieser Datengrundlage werden Lieferentscheidungen getroffen. Release-Termine zugesagt. Kapazitäten geplant. Prognosen an Kunden weitergegeben. Auf derselben Datengrundlage werden dann häufig sogar noch Aussagen über die Time-to-Market, die Wirksamkeit der agilen Transformation und den ROI des Teams getroffen.Das Board lügt nicht willentlich. Es zeigt nur ein Bild, das mit der echten Arbeit wenig zu tun hat, und niemand merkt es, weil niemand jemals etwas anderes gesehen hat.Jira ist nicht der Bösewicht.Wer ein neues Scrum-Projekt in Jira anlegt, bekommt ein Board mit drei Spalten:„To Do“„In Progress“„Done“Diese drei Spalten sind die Voreinstellung. Sie sind keine Empfehlung. Die Entwickler von Jira mussten einen Default setzen. Sie haben den simpelsten genommen, der überhaupt Sinn ergibt. Das Problem ist, was danach nicht passiert ist. Teams übernehmen diesen Standard, ohne ihn jemals zu hinterfragen.Aber diese drei Spalten sind doch kein Naturgesetz, oder?Warum Messungen versagen, obwohl sich Teams an den Standard haltenWer in der Agile-Community nach Lösungen für unzuverlässige Lieferung sucht, stößt schnell auf die Durchlaufzeit.Die Idee: Statt zu schätzen, einfach messen, wie lange Arbeit in der Vergangenheit gedauert hat, und daraus Vorhersagen ableiten. Aber sobald Teams das mit ihrem Default-Board versuchen, kommt fast immer dieselbe Reaktion:„Haben wir probiert. Funktioniert bei uns nicht. Unsere Arbeit ist zu unterschiedlich oder zu unvorhersagbar.“Die Reaktion ist verständlich, beruht allerdings auf einer falschen Annahme.Die Cycle-Time versagt in diesen Teams nicht, weil die Messgröße schlecht wäre. Sie versagt, weil das Board, auf dem gemessen wird, nichts misst, außer den Abstand zwischen dem Moment, in dem ein Eintrag angefangen wurde, und dem Moment, in dem ihn jemand als „fertig“ bezeichnet. Alles dazwischen verschwindet in der einen großen Spalte „In Progress“: die aktive Arbeit, die Wartezeit auf Reviews, die Wartezeit auf Freigaben, das unbemerkte Zusammenarbeits-Pingpong zwischen Teams, das Warten auf den IT-Support.Wenn ein Eintrag zwei Stunden braucht und ein anderer fünfzig Tage, beschreibt dies eben keinen stabilen Entwicklungsprozess.Wie Teams ihren echten Prozess sichtbar machenWenn ich Teams dann dabei unterstütze, ihren tatsächlichen Entwicklungsprozess auf dem Board abzubilden, fällt immer auf:Niemand im Team kann auf Anhieb beschreiben, wie die Arbeit wirklich verläuft. Was ist alles nötig, damit ein Eintrag aus dem Backlog wirklich fertig ist? Woran liegt es, dass manche Einträge länger brauchen als andere? Wie gehen wir damit um, wenn ein Eintrag nicht weiterentwickelt werden kann?Diese Ratlosigkeit ist die direkte Konsequenz der jahrelangen Arbeit mit den drei Default-Spalten.Hier mein schrittweises Vorgehen, wenn du deinem Scrum Team direkt helfen willst:Schritt 1: Definiere Anfang und Ende des Prozesses: Welchen Teil der Arbeit kann das Team wirklich überblicken und welchen Teil verantwortet es auch? Diese zwei Punkte bilden die äußeren Enden deines Entwicklungsprozesses. Alles dazwischen erarbeitet ihr gemeinsam.Schritt 2: Sammle die echten Zwischenstationen rückwärts: Startet am Ende und fragt euch: Was muss unmittelbar vorher passiert sein, damit dieser Eintrag als „fertig“ bezeichnet werden kann? Dann wieder: Was muss davor passiert sein? Dieser Rückwärtsgang deckt Schritte auf, die vorwärts gedacht gerne vergessen werden, zum Beispiel Deployment-Freigaben oder Abnahmen durch den Product-Owner.Schritt 3: Gib jedem Schritt einen Namen, der eine Aktivität beschreibt: Nicht „In Bearbeitung“, sondern konkrete Tätigkeiten. Was tut das Team hier: Problem entdecken, technischen Entwurf erstellen, programmieren, Code-Reviews durchführen, Unit-Tests entwickeln, Integrationstests durchführen, Build und Deployment ausführen oder mit Kunden validieren?Schritt 4: Trenne aktive Arbeit von Übergaben: Das ist der entscheidende Unterschied zu „To Do“, „Doing“ und „Done“. Wo endet die Arbeit eines Schritts? Und wartet der Eintrag dann auf den nächsten Schritt? Diese Übergaben werden zu eigenen Spalten: „Build Ready“, „Deploy Ready“, „Release Ready“. Wenn Übergaben unsichtbar in „Doing“ verschwinden, kann das Team nicht unterscheiden, ob ein Eintrag aktiv bearbeitet wird oder nur wartet. Ein Eintrag, der 14 Tage in „Doing“ hängt, könnte 13 Tage auf ein Code-Review gewartet haben, aber das sieht niemand.Schritt 5: Rekonstruiert den letzten Sprint: Nehmt fünf bis zehn Einträge des letzten Sprints und rekonstruiert rückwirkend, welche Spalten sie wann durchlaufen haben. Macht diese Analyse im gesamten Team und stellt euch die Frage, ob für die Fertigstellung dieser Einträge alle Aktivitäten auf dem Board ausreichend waren. Ziel ist es, zu prüfen, ob nicht ein Schritt vergessen wurde.



Image


 Ab diesem Punkt beginnt das Scrum-Board zum ersten Mal, den tatsächlichen Entwicklungsprozess sichtbar zu machen.Die Versuchung der Blocked-Spalte und warum sie Lieferprognosen sabotiertNachdem Teams ihren Prozess sichtbar gemacht haben, kommen sie immer auf dieselbe Idee:„Wir brauchen eine Spalte für blockierte Einträge.“Das klingt zunächst sinnvoll. Probleme sichtbar zu machen, klingt richtig. Kurzfristig entsteht durch eine „Blocked“-Spalte tatsächlich mehr Transparenz.Langfristig passiert das Gegenteil.Sobald ein Eintrag in „Blocked“ verschoben wird, geschieht psychologisch etwas Bemerkenswertes: Das Team betrachtet den Eintrag nicht mehr als aktive Arbeit. Er ist irgendwie „weg“. Er ist „bei anderen“. Aus den Augen, aus dem Sinn. Die Verantwortung wandert leise von „Problem lösen“ zu „Problem dokumentieren“.Genau dadurch altern Einträge immer weiter. Ein Eintrag in „Blocked“ kann wochenlang dort liegen, ohne dass jemand zuckt, weil das Team das Gefühl hat, es habe schließlich seinen Teil getan.Scrum Teams, die ohne eine Blocked-Spalte auskommen und stattdessen visuelle Markierungen am betroffenen Eintrag anbringen, etwa eine farbliche Hervorhebung oder einen expliziten Blocker-Hinweis mit Begründung („Warten auf Lieferung Payment-Team“), verhalten sich anders. Der Eintrag bleibt im Arbeitsfluss sichtbar. Die Blockade bleibt eine Aufgabe. Das Team, besonders der Scrum Master, spürt weiterhin den Druck, das Hindernis aktiv zu beseitigen.Was sich in der täglichen Arbeit der Scrum Teams verändertIn Scrum Teams, die ihr Scrum-Board so umgebaut haben, fallen mir bisher immer drei Gewohnheiten auf, die vorher nicht da waren.Das tägliche Daily verschiebt seinen Fokus: Statt der Frage: „Was hast du gestern gemacht?“, steht plötzlich die Frage im Raum: „Was ist hier am ältesten?“ Das Alter eines Eintrags, wie lange er bereits in einer Spalte wartet oder bearbeitet wird, wird zum besten Frühindikator für drohende Probleme. Wer Alter beobachtet, erkennt Blockaden, bevor sie zu gerissenen Terminen werden.WIP-Limits tauchen von selbst auf. Nicht als formale Regel, die ich als Coach von außen verordne, sondern als praktische Frage, die sich das Team selbst stellt: „Wie viele Einträge können wir hier gleichzeitig bearbeiten?“ Eine grobe Faustregel, die sich in vielen Teams bewährt hat: Teamgröße geteilt durch zwei. Sieben Personen bedeuten drei bis vier parallele Einträge pro aktiver Spalte, nicht vierzehn.Der Prozess auf dem Scrum-Board wird als verhandelbar verstanden: Teams, die einmal verstanden haben, dass die drei Default-Spalten kein Naturgesetz waren, behandeln auch ihr neues Board nicht mehr als unveränderlich. In Sprint-Retrospektiven wird häufig die Frage gestellt, ob das Scrum-Board noch die Realität abbildet oder ob es neue Übergaben gibt.Erst jetzt wird die Lieferfähigkeit wirklich beeinflussbar.Bisher war das Scrum-Board lediglich eine Aufgabenliste.Jetzt bildet es den tatsächlichen Arbeitsfluss des Teams ab. Und genau dadurch werden drei Metriken plötzlich aussagekräftig:Work in Progress: wie viel Arbeit gleichzeitig begonnen wurde.Cycle-Time: wie lange ein Eintrag tatsächlich für den Prozess benötigt.Durchsatz: wie viele Einträge das Team in einem Zeitraum abschließt.Diese drei Größen hängen mathematisch zusammen über Little’s Law:Cycle Time = WIP ÷ Throughput.



Image


Bedeutet:Wer mehr Arbeit gleichzeitig beginnt, verlängert die Durchlaufzeit.Wer weniger parallel startet, wird schneller fertig.Wer den Durchsatz erhöht, reduziert Wartezeiten im gesamten System.Aber Little’s Law hat eine Voraussetzung, die fast immer übersehen wird: Der Entwicklungsprozess muss einigermaßen stabil sein. Im Default-Scrum-Board war er das nicht. Wenn ein Eintrag zwei Stunden braucht und ein anderer fünfzig Tage, ist die Streuung einfach zu groß. Diese Cycle-Time ist für belastbare Vorhersagen unbrauchbar.Drei Spalten und ihre Auswirkung aufs ganze UnternehmenEin transparentes Scrum-Board ist ein Fundament für gute Entscheidungen.Es hilft dem Team, zu erkennen, ob es seine Liefertermine halten kann, und gibt damit Auskunft über die Time-to-Market des Unternehmens.Time-to-Market klingt nach einer soliden Kennzahl. Tatsächlich ist sie nur so belastbar, wie der Entwicklungsprozess dahinter stabil ist. Solange das Scrum-Board nicht zeigt, was wirklich passiert, gleicht jede Entscheidung darauf einem Spiel im Casino. Ein Scrum-Board so anzupassen, dass es belastbare Aussagen erlaubt, ist mehr Arbeit, als die meisten erwarten.Vielleicht bleiben viele Unternehmen am Ende deshalb doch lieber bei Schätzungen und Bauchgefühl und treffen auf dieser Basis ihre strategischen Entscheidungen. 🤷‍♂️P.S. Hast du das Gefühl, dass Entscheidungen in deinem Unternehmen auf zu dünner Datengrundlage getroffen werden? In meinen Trainings zu Evidence-Based Management arbeiten wir genau daran, das zu ändern.

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Warum Aufwandsschätzungen in der Softwareentwicklung gleichzeitig sinnvoll und gefährlich sind	0	6.5	28-07-2026
2	Scrum Isn't for Stormtroopers	0	15.26	28-07-2026
3	Vibe-Coding für Anforderungen – geht das? Wie Prototypen das Refinement retten, bevor es peinlich wird	0	8.6	21-07-2026
4	Der heimliche Feind jedes Product-Owners: 5 Mythen, die Karrieren ruinieren	0	15.23	27-07-2026
5	Your Team Isn't Bad at Estimating. Planning Is Just Harder Than We Admit	0	11.64	14-07-2026
6	Incremental Delivery and the Need for Speed	0	15.1	14-07-2026
7	Flow Metrics in Python: 3 Scripts for Ensuring Transparency	0	14.98	23-07-2026
8	Cognitive Trap: Velocity Misinterpretation	0	7.37	20-07-2026
9	You Can Ignore the Flow Data. It Still Decides When You Ship.	0	13.6	12-07-2026
10	The Project Manager Isn't Dead. It Was Disassembled on Purpose!	0	16.43	27-07-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 11.71. Источник: www.scrum.org.