Warum dein Scrum Team nicht performt (und was du dagegen tun kannst)

Das Daily läuft. Das Sprint Planning findet statt. Jira ist gepflegt. Trotzdem werden Sprint-Ziele verfehlt, Aufgaben wandern von Sprint zu Sprint und Stakeholder verlieren Vertrauen. Wenn dein Scrum Team nicht performt, liegt die Ursache selten an einem einzelnen Teammitglied. Häufig bremsen fehlender Fokus, zu viele Abhängigkeiten, schwaches Product Ownership oder falsche Kennzahlen das gesamte System. Genau deshalb bringt es wenig, einfach „schneller“ arbeiten zu wollen. Wer die Leistung eines Scrum Teams verbessern will, muss zuerst verstehen, wo Wertfluss, Zusammenarbeit und Entscheidungsfähigkeit tatsächlich blockiert werden.

Ein leistungsfähiges Scrum Team erledigt nicht einfach möglichst viele Tickets.

Es erzeugt regelmäßig nutzbare Ergebnisse mit relevantem Wert und kann sich anhand neuer Erkenntnisse schnell anpassen.

Der Scrum Guide beschreibt ein Scrum Team als kleine, cross-funktionale und selbstmanagende Einheit, die auf ein gemeinsames Product Goal fokussiert ist. Das Team trägt gemeinsam Verantwortung dafür, in jedem Sprint ein wertvolles und nutzbares Increment zu erzeugen.

Teamperformance sollte deshalb mindestens vier Dimensionen umfassen:

Eine hohe Velocity allein beantwortet keine dieser Fragen vollständig.

Scrum.org weist ausdrücklich darauf hin, dass Velocity weder Geschwindigkeit noch Produktivität oder Business Value zuverlässig misst. Sie kann bei manchen Teams zur Prognose helfen, eignet sich aber nicht als allgemeiner Performance-Indikator.

Typische Symptome sind:

Diese Symptome sind wichtig.

Sie sind aber noch keine Diagnose.

Einer der größten Performance-Killer ist fehlender Fokus.

Ein Sprint enthält dann beispielsweise:

Jeder ist beschäftigt.

Aber das Team arbeitet nicht wirklich gemeinsam.

Der Sprint Goal soll genau dieses Problem verhindern. Laut Scrum Guide schafft er Kohärenz und Fokus und soll das Team dazu bringen, auf ein gemeinsames Ziel hinzuarbeiten statt auf voneinander getrennte Initiativen.

„Ticket 123, 126, 129 und 140 abschließen.“

Das ist eine Aufgabenliste.

„Bestandskunden können ihre Lieferadresse selbstständig ändern, ohne den Support kontaktieren zu müssen.“

Damit versteht das Team:

Erste Maßnahme: Prüfe die letzten fünf Sprint-Ziele.

Kann jemand außerhalb des Teams verstehen, welchen Nutzen sie erzeugen sollten?

Wenn nicht, beginnt die Performance-Verbesserung genau dort.

Viele Scrum Teams haben kein Geschwindigkeitsproblem.

Sie haben ein Work-in-Progress-Problem.

Fünf Entwickler starten fünf Backlog Items.

Danach entstehen Rückfragen.

Ein Test fehlt.

Ein Kollege wartet auf eine Schnittstelle.

Also beginnt er schon das nächste Thema.

Am Ende des Sprints sind zwölf Items begonnen und vier wirklich fertig.

Das erzeugt Aktivität.

Aber wenig Flow.

Scrum.org weist beim Thema Fokus ausdrücklich darauf hin, dass Personen, die gleichzeitig mehreren Teams oder Projekten zugeordnet werden, weniger effektiv arbeiten. Auch zusätzliche Meetings und Unterbrechungen reduzieren den Fokus auf das Sprint Goal.

Die entscheidende Frage im Daily lautet dann nicht:

„Was habe ich gestern gemacht?“

Sondern:

„Was verhindert gerade, dass wir unser Sprint-Ziel erreichen?“

Ein Team kann technisch hervorragend arbeiten und trotzdem wenig Wert erzeugen.

Das passiert, wenn der Product Owner nicht priorisiert.

Dann sieht das Product Backlog aus wie ein Sammelbecken:

Alles wichtig.

Alles dringend.

Der Scrum Guide ist eindeutig: Der Product Owner verantwortet die Maximierung des Produktwerts und die Reihenfolge des Product Backlogs. Die Organisation muss seine Entscheidungen respektieren.

Fehlt dieses Mandat, kann das Team nicht wirklich performen.

Es optimiert lediglich die Abarbeitung fremder Wünsche.

Kann der Product Owner diese Fragen nicht beantworten, liegt das Performance-Problem wahrscheinlich nicht im Development Team.

Auf dem Organigramm existiert ein Scrum Team.

In der Realität benötigt es für fast jeden Schritt jemand anderen.

Zum Beispiel:

Jede Abhängigkeit erzeugt Wartezeit.

Der Scrum Guide verlangt deshalb bewusst Cross-Funktionalität. Die Teammitglieder sollen gemeinsam über die Fähigkeiten verfügen, die sie benötigen, um innerhalb eines Sprints Wert zu erzeugen.

Natürlich kann nicht jedes Spezialwissen dauerhaft in jedem Team vorhanden sein.

Aber wiederkehrende Abhängigkeiten müssen sichtbar werden.

Notiere für die vergangenen drei Sprints:

Eine Abhängigkeit, die jeden Sprint entsteht, ist kein Ausnahmeproblem mehr.

Sie gehört organisatorisch gelöst.

Ein Team meldet acht Stories als fertig.

Danach folgen:

Dann waren die acht Stories nicht wirklich fertig.

Der Scrum Guide definiert die Definition of Done als formale Beschreibung des Zustands, den ein Increment erreichen muss, um die erforderlichen Qualitätsmaßnahmen zu erfüllen. Arbeit, die diesen Zustand nicht erreicht, gehört nicht zum Increment.

Eine schwache Definition of Done erzeugt Scheingeschwindigkeit.

Heute wird schnell geliefert.

Morgen kommt die Nacharbeit.

Enthält eure Definition of Done beispielsweise:

Je mehr Arbeit regelmäßig nach „Done“ folgt, desto weniger aussagekräftig ist eure tatsächliche Lieferperformance.

Scrum braucht Transparenz.

Transparenz braucht Offenheit.

Und Offenheit funktioniert schlecht, wenn Menschen Nachteile befürchten.

Ein Entwickler erkennt einen Architekturfehler.

Sagt aber nichts.

Ein Teammitglied hält das Sprint Goal für unrealistisch.

Schweigt.

Eine Annahme des Product Owners ist vermutlich falsch.

Niemand widerspricht.

Die Ampel bleibt grün.

Bis das Problem nicht mehr verborgen werden kann.

Forschung von Google zu Teamwirksamkeit identifizierte psychologische Sicherheit als besonders wichtigen Faktor für leistungsfähige Teams. DORA-Forschung verbindet eine entsprechende Kultur zudem mit besserer Software-Delivery-Performance und organisationaler Leistung.

Scrum.org hebt psychologische Sicherheit ebenfalls als wichtige Grundlage wirksamer Scrum Teams hervor.

Ein Team kann unter solchen Bedingungen Prozesse einhalten.

Empirie funktioniert trotzdem kaum.

Montag beginnt der Sprint.

Mittwoch kommt eine „dringende“ Managementanforderung.

Donnerstag benötigt ein anderer Bereich Unterstützung.

In der folgenden Woche folgt ein Produktionsproblem.

Formal arbeitet das Team weiterhin in Sprints.

Praktisch besitzt es keinen stabilen Fokus.

Die DORA-Forschung von 2024 zeigt, dass instabile Prioritäten selbst in ansonsten gut geführten Entwicklungsumgebungen die Leistung beeinträchtigen können. Eine stabile, unterstützende Umgebung ist dagegen ein wichtiger Faktor für gute Ergebnisse.

Der Scrum Guide schützt deshalb das Sprint Goal: Während des Sprints dürfen keine Änderungen vorgenommen werden, die dieses Ziel gefährden. Scope darf angepasst werden, wenn neue Erkenntnisse entstehen. Das Ziel selbst gibt jedoch Orientierung.

Nicht jede dringende Anfrage darf direkt ins Team.

Definiere einen klaren Umgang mit:

„Der Vorstand möchte das schnell“ ist noch kein Prozess.

Viele Teams führen gute Retrospektiven durch.

Das Board ist voller Erkenntnisse.

Drei Wochen später besteht dasselbe Problem weiterhin.

Dann sinkt die Beteiligung.

Warum sollte jemand offen über Probleme sprechen, wenn sich ohnehin nichts verändert?

Der Scrum Guide beschreibt den Zweck der Retrospektive klar: Das Team soll konkrete Möglichkeiten identifizieren, Qualität und Effektivität zu erhöhen. Besonders wirksame Verbesserungen sollen schnell angegangen werden.

Nimm nicht zehn Maßnahmen mit.

Nimm eine.

Aber setze sie wirklich um.

Beispiel:

Problem: Stories werden regelmäßig zu groß geplant.

Maßnahme:

In den kommenden drei Sprints darf kein Backlog Item ins Planning, das voraussichtlich mehr als drei Arbeitstage benötigt, ohne vorher gemeinsam geschnitten zu werden.

Danach messen.

Hat sich der Spillover reduziert?

Dann war die Retrospektive ein Verbesserungsinstrument.

Ein Managementziel wie:

„Velocity um 20 Prozent erhöhen“

klingt datengetrieben.

Es ist meistens das Gegenteil.

Wenn eine Kennzahl zum Ziel wird, verändert sich das Verhalten.

Teams können:

Die Kennzahl steigt.

Der Produktwert möglicherweise nicht.

Scrum.org beschreibt Velocity deshalb als Ergebnis beziehungsweise mögliches Prognoseinstrument, nicht als Produktivitätsziel. Teams mit höherer Velocity sind nicht automatisch leistungsfähiger als Teams mit niedrigerer Velocity.

Es gibt keine einzelne perfekte Kennzahl.

Kombiniere mehrere Perspektiven.

Das Evidence-Based Management Framework von Scrum.org unterscheidet bewusst zwischen Inputs, Aktivitäten, Outputs, Outcomes und Impacts. Mehr Stunden oder mehr Features bedeuten demnach nicht automatisch bessere Kundenergebnisse.

Ein dokumentiertes Beispiel aus einem internationalen Handelsunternehmen zeigt das Problem gut.

Mehr als 40 Teams arbeiteten in einer großen IT-Transformation.

Die Organisation nutzte Scrum.

Trotzdem war die Delivery schwer vorhersehbar. Bei einem Teil der Organisation wurden rund 70 Prozent der begonnenen Arbeiten in nachfolgende Zeiträume übertragen.

Statt einfach mehr Druck auf die Velocity auszuüben, setzte die Organisation stärker auf Flow Metrics.

Im Mittelpunkt standen unter anderem:

Dadurch konnten Teams Blockaden und Überlastung wesentlich konkreter diskutieren. Die Organisation berichtet, dass Lieferfähigkeit und Vertrauen in die Prognosen innerhalb weniger Monate deutlich verbessert wurden.

Die wichtige Erkenntnis:

Das Team musste nicht lernen, härter zu arbeiten. Es musste lernen, seinen Arbeitsfluss besser zu verstehen.

Ein weiteres dokumentiertes Beispiel zeigt, warum Teamperformance nicht isoliert betrachtet werden darf.

Ein Unternehmen wollte ein neues Produkt entwickeln.

Vor dem eigentlichen Scrum-Start veränderte es bewusst seine Struktur:

Nach drei Monaten zeigte das neue Team nach Angaben des dokumentierten Erfahrungsberichts eine deutlich bessere Leistungsfähigkeit. Nach sechs Monaten brachte das Unternehmen das Produkt in einen stark umkämpften asiatischen Markt.

Der entscheidende Punkt:

Man versuchte nicht, ein schlecht geschnittenes Organisationsmodell mit Scrum-Events zu reparieren.

Man änderte die Rahmenbedingungen.

Wenn dein Team aktuell nicht performt, solltest du nicht zehn Veränderungen gleichzeitig starten.

Gehe systematisch vor.

Analysiere die letzten fünf Sprints.

Erfasse:

Noch keine Lösungen.

Erst verstehen.

Nicht jedes Problem gleichzeitig angehen.

Frage:

Was begrenzt aktuell am stärksten unsere Fähigkeit, Wert zu liefern?

Beispielsweise:

Beispiel:

Problem: zu viel parallele Arbeit.

Experiment:

Maximal drei Backlog Items gleichzeitig in Bearbeitung.

Messgröße:

Hat sich die Situation verbessert?

Dann beibehalten oder weiterentwickeln.

Keine Wirkung?

Hypothese anpassen.

So funktioniert empirische Verbesserung.

Ein ausgelastetes Team wird durch höhere Zielvorgaben selten leistungsfähiger.

Teamperformance entsteht im System.

Nicht allein beim Scrum Master oder bei einzelnen Entwicklern.

Eine Kennzahl ist keine Verbesserung.

Damit steigt oft nur die Menge unfertiger Arbeit.

Auslastung steigt.

Fokus sinkt.

Wenige konsequent umgesetzte Veränderungen wirken stärker.

Jira, Azure DevOps oder andere Werkzeuge lösen keine organisatorischen Probleme.

Nicht jedes Performance-Problem sollte durch „besseres Scrum“ gelöst werden.

Scrum passt schlecht, wenn beispielsweise:

Dann kann etwa ein Flow-basierter Ansatz mit Kanban geeigneter sein.

Auch die aktuelle agile Praxis bewegt sich stärker in Richtung kontextabhängiger Arbeitsmodelle. Der 18. State of Agile Report von 2025 zeigt eine deutliche Nutzung hybrider und individuell angepasster Delivery-Modelle. Gleichzeitig nennen Organisationen stärkere Outcome-Orientierung und bessere Leadership-Ausrichtung als wichtige Entwicklungsfelder.

Das Ziel ist nicht Scrum.

Das Ziel ist eine Arbeitsweise, mit der die Organisation verlässlich Wert erzeugt und lernen kann.

Wenn du die wichtigsten Punkte auf eine Checkliste reduzieren willst, beginne hier:

Erst danach lohnt sich die Diskussion über Feinheiten der Scrum-Mechanik.

Häufig liegt es nicht an mangelndem Einsatz. Ursachen können zu viel parallele Arbeit, externe Abhängigkeiten, große Backlog Items, häufige Unterbrechungen oder lange Entscheidungswege sein.

Nicht mit einer einzelnen Kennzahl. Sinnvoll ist eine Kombination aus Business Outcomes, Flow-Kennzahlen, Qualität, Sprint-Goal-Erreichung und Time-to-Market.

Nein, nicht als allgemeiner Performance-KPI. Velocity kann teamintern für Prognosen nützlich sein, sollte aber nicht als Produktivitätsziel oder zum Vergleich verschiedener Teams verwendet werden.

Zuerst sollte der größte Engpass ermittelt werden. Häufig helfen kleinere Backlog Items, ein klares Sprint Goal, weniger parallele Arbeit und konsequentes Entfernen von Blockaden.

Ein leistungsfähiges Team besitzt ein gemeinsames Ziel, ausreichende Entscheidungsfreiheit, die notwendigen Fähigkeiten, psychologische Sicherheit und einen stabilen Arbeitsfluss. Es liefert nicht nur viel Output, sondern regelmäßig relevante Ergebnisse.

Der Scrum Master ist laut Scrum Guide für die Effektivität des Scrum Teams mitverantwortlich. Er unterstützt Selbstmanagement, Cross-Funktionalität, Fokus und die Beseitigung von Hindernissen. Seine Aufgabe geht damit deutlich über die Moderation der Scrum Events hinaus.

Wenn ein Scrum Team nicht performt, lautet die falsche erste Frage:

„Wie bekommen wir mehr Arbeit aus dem Team?“

Die bessere Frage lautet:

„Was verhindert aktuell, dass dieses Team regelmäßig Wert erzeugen kann?“

Vielleicht fehlt Fokus.

Vielleicht beginnt das Team zu viel gleichzeitig.

Vielleicht hat der Product Owner keine echten Entscheidungsrechte.

Vielleicht wird Qualität erst nach dem Sprint hergestellt.

Vielleicht sind externe Abhängigkeiten so groß, dass das Team kaum selbst etwas fertigstellen kann.

Oder die Organisation verändert Prioritäten schneller, als das Team liefern kann.

Dann löst zusätzlicher Leistungsdruck das Problem nicht.

Er verschärft es.

Ein leistungsfähiges Scrum Team entsteht dort, wo klare Ziele, Fokus, Qualität, Entscheidungsfreiheit und kontinuierliches Lernen zusammenkommen.

Performance bedeutet deshalb nicht:

mehr Story Points.

Performance bedeutet:

häufiger relevante Ergebnisse erzeugen, schneller aus echten Daten lernen und Hindernisse systematisch aus dem Arbeitsfluss entfernen.

PURE Consultant unterstützt Unternehmen dabei, Scrum Teams, Product Ownership und agile Strukturen gezielt zu analysieren und weiterzuentwickeln. Der Fokus liegt dabei nicht auf zusätzlichen Ritualen, sondern auf den organisatorischen Bedingungen, die Teams benötigen, um nachhaltig Wert zu liefern.