Von Abhay Talreja
28.12.2025
Mein neuester Artikel - Empirical Process Control - The Key to Agile Success
Scrum-Wert Fokus
Fokus in Scrum bedeutet, dass sich das Scrum Team auf die Arbeit des Sprints und die Ziele des Scrum Teams konzentriert - nicht verstreut über mehrere konkurrierende Prioritäten. Der Scrum Guide (opens in a new tab) besagt, dass Teams "ihre Aufmerksamkeit auf die Arbeit des Sprints und die Ziele des Scrum Teams richten" und anerkennt, dass die Aufteilung der Aufmerksamkeit die Transparenz, Überprüfung und Anpassung untergräbt, die für die empirische Prozesskontrolle wesentlich sind.
Wenn Teams den Fokus beibehalten, vervollständigen sie Arbeit gemäß der Definition of Done, anstatt alles nur teilweise fertig zu lassen. Wenn der Fokus zusammenbricht, jonglieren Teams mit zu vielen Prioritäten gleichzeitig, Kontextwechsel erodieren die Produktivität und Sprints enden mit nichts wirklich Abgeschlossenem - was wie geschäftige Aktivität aussieht, liefert tatsächlich minimalen Wert.
Dieser umfassende Leitfaden untersucht, wie sich Fokus über Scrum-Rollen und Scrum-Events manifestiert, plus praktische Strategien zur Aufrechterhaltung des Fokus in Organisationen, die Teams gewohnheitsmäßig mit dringenden Anfragen unterbrechen.
| Aspekt | Fokus in Scrum |
|---|---|
| Definition | Scrum Team Mitglieder konzentrieren sich auf die Arbeit des Sprints und die Ziele des Scrum Teams |
| Hauptmechanismus | Sprint-Ziele, die Kohärenz und einheitlichen Teameinsatz auf ein einzelnes Ziel schaffen |
| Hauptvorteil | Höherer Durchsatz durch reduzierten Kontextwechsel und kollaborative Fertigstellung |
| Unterstützt durch | Zeitlich begrenzte Sprints, Definition of Done, WIP-Limits, Daily Scrum Überprüfungs-Anpassungszyklus |
| Häufiger Fehler | Hohe Work-in-Progress, bei der das Team viele Elemente beginnt, aber wenige abschließt |
| Erfolgsindikator | Sprint-Ziele werden konsequent mit stabiler Velocity und niedrigem WIP erreicht |
Fokus ist einer der fünf Kern-Scrum-Werte (Commitment, Fokus, Offenheit, Respekt und Mut), die die Grundlage für erfolgreiche empirische Prozesskontrolle bilden. Während andere Frameworks möglicherweise Produktivität oder Effizienz betonen, schätzt Scrum Fokus speziell, weil komplexe Produktentwicklung konzentrierte Aufmerksamkeit erfordert, um Unsicherheit effektiv zu navigieren.
Der Scrum Guide erklärt, dass Fokus bedeutet, sich auf das zu konzentrieren, was derzeit am wichtigsten ist, und Arbeit zur Fertigstellung zu bringen, anstatt die Aufmerksamkeit über mehrere konkurrierende Prioritäten zu verteilen, die alle marginalen Fortschritt machen, aber keine wirklich abgeschlossen werden.
Forschung von Gerald Weinberg demonstriert die verheerenden Kosten des Multitaskings:
Dies schafft das sogenannte Produktivitätsparadoxon: Beschäftigt zu erscheinen, indem man gleichzeitig an zehn Elementen arbeitet, fühlt sich produktiv an, liefert aber tatsächlich weniger Wert als sich auf die sequenzielle Fertigstellung von zwei Elementen zu konzentrieren. Die verlorenen 20-40% Effizienz gehen in den Kontextwechsel-Overhead, nicht in produktive Arbeit.
Die Fokus-Falle: Organisationen verwechseln oft Aktivität mit Fortschritt. Ein Team mit 15 Elementen "in Arbeit" erscheint beschäftigter als ein Team mit 3 Elementen in Arbeit, aber das fokussierte Team mit niedrigem WIP schließt typischerweise mehr Arbeit pro Sprint ab, weil sie Kontextwechsel-Overhead vermeiden und effektiv zusammenarbeiten.
Fokus unterstützt direkt Scrums drei Säulen:
Ohne Fokus durchlaufen Teams Scrum-Bewegungen, verpassen aber das empirische Lernen, das Scrum in komplexen Umgebungen effektiv macht.
Scrums Framework enthält mehrere eingebaute Mechanismen, die Fokus verstärken:
Jeder Sprint sollte ein Sprint-Ziel haben - ein einzelnes Ziel, das beschreibt, warum der Sprint für Stakeholder wichtig ist. Das Sprint-Ziel:
Beispiel für ein starkes Sprint-Ziel: "Ermögliche Kunden, den Checkout abzuschließen, ohne ein Konto zu erstellen, und reduziere so den Warenkorb-Abbruch." Dies gibt allen Sprint Backlog Elementen Kohärenz (Gast-Checkout-Flow, Zahlungsabwicklung, Bestellbestätigung usw.) als vielfältige Mittel zu einem einzigen Ziel.
Sprint-Ziele vs. Aufgabenlisten: Ein Sprint-Ziel von "Ausgewählte Elemente im Sprint Planning abschließen" ist eigentlich kein Ziel - es ist nur eine Liste. Effektive Sprint- Ziele beschreiben Wert oder Ergebnis, das Entscheidungshilfe bietet, wenn die Realität nicht dem Plan entspricht.
Alle Scrum Events sind zeitlich begrenzt, was Dringlichkeit schafft, die Fokus unterstützt:
Der psychologische Effekt nahender Fristen erhöht natürlich die Konzentration und reduziert Ablenkungen - die Timebox nutzt dies zum Teamvorteil.
Die Definition of Done schafft eine Qualitätsschwelle, die Arbeit erfüllen muss, um als abgeschlossen zu gelten. Dies verhindert das Fokus-Anti-Pattern, bei dem Teams viele Elemente beginnen, aber wenige abschließen, weil "fertig" mehrdeutig ist.
Mit klarer DoD konzentrieren sich Teams darauf, Elemente in Releasequalität abzuschließen, anstatt viele Elemente in den Status "fast fertig" zu versetzen, der keinen Wert für Benutzer oder Stakeholder bietet.
Jede Scrum-Rolle demonstriert Fokus unterschiedlich:
Der Product Owner fokussiert das Team durch:
Häufiger Product Owner Fokus-Fehler: Alles als "hohe Priorität" zu deklarieren, was null tatsächliche Priorisierung bietet. Wenn alles Priorität eins ist, ist nichts Priorität eins.
Fokus-Praxis: "Wir konzentrieren uns im Q1 auf Conversion-Optimierung, weil die Analytik 60% Warenkorb-Abbruch zeigt. Bindungsfunktionen werden Q2-Fokus sein." Klarer Fokus ermöglicht Stakeholder-Ausrichtung und Teamkonzentration.
Der Scrum Master unterstützt Fokus durch:
Beispiel: Der Scrum Master beobachtet drei Teammitglieder, die zwischen zwei Teams aufgeteilt sind und an den Zeremonien beider Teams teilnehmen. Sie verfolgen Daten, die zeigen, dass diese Personen signifikant längere Durchlaufzeiten haben als dedizierte Teammitglieder, und präsentieren dann Daten an die Führung, um für dedizierte Teamzuweisungen zu plädieren und empirisch eine Durchsatzverbesserung zu demonstrieren.
Entwickler erhalten Fokus durch:
Beispiel technischer Praxis: Anwendung von YAGNI (You Aren't Gonna Need It) durch Bauen nur dessen, was der Sprint erfordert, nicht spekulativer zukünftiger Funktionen, reduziert Code-Komplexität und Kontextwechsel-Overhead.
Fokus manifestiert sich unterschiedlich in Scrums fünf Events:
Sprint Planning etabliert Sprint-Fokus durch:
Anti-Pattern: 20 unzusammenhängende Product Backlog Elemente auswählen, weil "wir zehn Leute haben." Dies schafft zehn separate Mini-Projekte anstatt einheitlicher Teamanstrengung.
Besserer Ansatz: Sprint-Ziel "Serverkosten um 30% reduzieren" mit Elementen, die speziell ausgewählt wurden, um dieses Ziel zu unterstützen (Datenbankabfrage-Optimierung, Caching-Implementierung, Infrastruktur-Rightsizing).
Das Daily Scrum erhält Fokus durch:
Die 15-Minuten-Timebox erzwingt Fokus - keine Zeit für tangentiale technische Diskussionen oder Statusberichte um des Berichtens willen.
Sprint Review validiert, dass sich der Fokus ausgezahlt hat durch:
Teams, die Fokus beibehalten haben, präsentieren abgeschlossene wertvolle Arbeit. Teams, die Aufmerksamkeit zerstreut haben, präsentieren teilweisen Fortschritt über viele Elemente ohne etwas Versandfertiges.
Sprint Retrospective verbessert Fokus durch:
Beispiel Retrospektive-Aktion: "Nächster Sprint, WIP auf 4 Elemente für 6-Personen-Team begrenzen (statt aktuell 9), Durchlaufzeit-Auswirkung messen."
Während Scrum keine expliziten WIP-Limits wie Kanban vorschreibt, adoptieren fokusorientierte Teams sie oft:
Typische WIP-Richtlinie: Anzahl der Elemente in Arbeit ≤ halbe Teamgröße. Für ein 6-Personen-Team streben Sie 3-4 Elemente gleichzeitig in Arbeit an.
Vorteile der WIP-Begrenzung:
Implementierung: WIP auf dem Sprint Board sichtbar machen. Wenn das Limit erreicht ist und das nächste Element von einer externen Abhängigkeit blockiert wird, schwärmt das Team, um zu entblockieren, anstatt neue Arbeit zu starten, die das WIP-Limit überschreiten würde.
Problem: Organisation deklariert jede Initiative als kritisch oder hohe Priorität, was null tatsächliche Priorisierung schafft und Teams zwingt, ständig den Kontext zu wechseln.
Warum problematisch: Wenn alles Priorität eins ist, ist nichts Priorität eins. Das Team kann sich nicht fokussieren, weil jeder Stakeholder sofortige Aufmerksamkeit fordert.
Lösung: Product Owner bildet Stakeholder aus, dass echte Priorisierung Ordnen bedeutet, nicht alles als hoch zu kennzeichnen. Macht Priorität real durch Sprint-Ziele, die sich auf einzelne Ziele konzentrieren, nicht auf zehn Ziele.
Prävention: Produkt-Ziel-Klarheit und transparente Product Backlog-Ordnung etablieren. Stakeholder über die Bedeutung von Sprint-Commitment aufklären.
Problem: Team arbeitet gleichzeitig an zehn Elementen, um "Auslastung zu maximieren", erscheint beschäftigt, liefert aber weniger als fokussierter Ansatz.
Warum problematisch: Kontextwechsel schafft erheblichen Produktivitätsverlust, teilweise abgeschlossene Arbeit bietet keinen Wert bis zur Fertigstellung, hoher WIP erhöht die Durchlaufzeit erheblich.
Lösung: WIP-Limits implementieren. Durchlaufzeit verfolgen, die eine inverse Beziehung zwischen WIP und Liefergeschwindigkeit demonstriert. Mit Experiment beginnen: ein Sprint mit striktem WIP-Limit vs. normaler Ansatz, Durchsatzunterschied messen.
Prävention: WIP auf dem Board sichtbar machen. Fertigstellungen mehr feiern als Starts.
Problem: Stakeholder fügen "schnelle Fünf-Minuten-Änderungen" mid-Sprint hinzu, was den Fokus auf das Sprint-Ziel stört.
Warum problematisch: Jede Ergänzung, unabhängig von der Größe, schafft Kontextwechsel-Kosten. Akkumulierte "kleine" Unterbrechungen zerstören Sprint-Kohärenz.
Lösung: Product Owner praktiziert "Ja, und wir werden es für die nächste Sprint Planning priorisieren" anstatt "Ja, wir werden den aktuellen Sprint unterbrechen." Für echte Notfälle (Produktion down, Sicherheitslücke) transparent über Sprint-Scope-Reduzierung verhandeln.
Prävention: Stakeholder über Sprint-Commitment aufklären. Sprint-Ziel und Grenze sichtbar machen.
Problem: Einzelne Teammitglieder sind über mehrere Teams oder Projekte aufgeteilt und nehmen an mehreren Daily Scrums, Sprint Plannings usw. teil.
Warum problematisch: Kontextwechsel zwischen Teams schafft enormen Overhead. Forschung zeigt, dass aufgeteilte Teammitglieder erheblich längere Durchlaufzeiten haben als dedizierte Mitglieder.
Lösung: Für dedizierte Teamzuweisungen plädieren. Daten empirisch präsentieren, die Durchsatzverbesserung durch Dedikation zeigen. Wenn aufgeteilte Zuweisungen unvermeidbar sind, Beteiligung klar zeitlich begrenzen.
Prävention: Organisationsdesign, das stabile, dedizierte Teams gegenüber Ressourcenpooling bevorzugt.
Problem: Sprint-Ziel besagt "Während Sprint Planning ausgewählte Elemente abschließen" oder es existiert kein explizites Ziel.
Warum problematisch: Ohne kohärentes Ziel arbeitet das Team an unzusammenhängenden Elementen, die keine Synergie bieten. Sprint wird zur Aufgabenabschluss-Übung anstatt fokussierter Wertlieferung.
Lösung: Zeit im Sprint Planning investieren, um Ziel zu gestalten, das beschreibt, warum der Sprint für Stakeholder wichtig ist. Guter Test: Könnte das Team das Sprint-Ziel erreichen, ohne jedes Sprint Backlog Element abzuschließen? Wenn ja, ist es ein echtes Ziel, das Orientierung bietet.
Prävention: Scrum Master coacht Product Owner zur effektiven Sprint-Ziel-Erstellung. Team übt Zielgestaltungsfähigkeiten.
Problem: Arbeit gilt als "fertig", wenn der Entwickler denkt, dass sie fertig ist, was inkonsistente Qualität und teilweise Fertigstellungen schafft.
Warum problematisch: Ohne klare Fertigstellungsschwelle beginnen Teams viele Elemente, schließen aber wenige ab, weil "fast fertig" zu einem akzeptablen Zustand wird.
Lösung: Klare Definition of Done etablieren, die Qualitätskriterien spezifiziert, die alle Arbeiten erfüllen müssen. Fertigstellung sichtbar und binär machen - Arbeit erfüllt entweder DoD oder nicht.
Prävention: DoD regelmäßig überprüfen und anpassen. Qualitätsstandards einbeziehen, die Fokus unterstützen (automatisierte Tests, Peer Review, Dokumentation).
Fokus-Herausforderung: Druck, Funktionen zu entwickeln, Leistung zu verbessern, Infrastruktur zu warten und Support gleichzeitig zu handhaben.
Sprint-Ziel Beispiel: "P1-Vorfall-Reaktionszeit auf unter 1 Stunde reduzieren"
DoD-Ergänzungen:
Fokus-Herausforderung: Balance zwischen HIPAA-Compliance, PHI-Sicherheit, Funktionsentwicklung und regulatorischen Berichten.
Sprint-Ziel Beispiel: "Sichere Patientenportal-Anmeldung mit MFA ermöglichen"
DoD-Ergänzungen:
Fokus-Herausforderung: Betrugserkennung, Zahlungsabwicklung, Compliance-Berichte und neue Finanzprodukte konkurrieren um Aufmerksamkeit.
Sprint-Ziel Beispiel: "Falsch-Positive bei Kreditkartenbetrug-Erkennung um 20% reduzieren"
DoD-Ergänzungen:
Fokus-Herausforderung: Acht Wochen vor Black Friday, Druck für neue Empfehlungsmaschine, Geschenkefinder, Leistungsverbesserungen und Design-Updates gleichzeitig.
Fokus-Strategie: Product Owner analysiert, dass Leistung entscheidend ist - Funktionen spielen keine Rolle, wenn die Website abstürzt. Fokussiert drei Sprints ausschließlich auf Leistung: Caching, Datenbankoptimierung, Lasttests. Widersteht Funktionsdruck: "Website-Zuverlässigkeit ermöglicht Umsatz; neue Funktionen spielen keine Rolle, wenn nicht verfügbar." Verschiebt Design-Updates und Empfehlungsmaschine auf nach den Feiertagen.
Ergebnis: Black Friday bewältigt deutlich höheren Traffic ohne Ausfallzeiten, Umsatz deutlich über Prognose. Fokussierte Wette auf Zuverlässigkeit über Funktionen zahlt massive Dividenden.
Fokus-Herausforderung: iOS- und Android-Parallententwicklungsdruck, der Plattform-Kontextwechsel schafft.
Fokus-Strategie: Eine Plattform gleichzeitig pro Funktion. Sprint-Ziel: "Messaging-Funktion für iOS zur App Store-Einreichung abschließen." Gesamtes Team fokussiert iOS-Implementierung (einschließlich Android-Entwickler, die iOS lernen). Folgender Sprint: Messaging auf Android portieren unter Anwendung des iOS-Lernens.
Ergebnis: Funktionen auf beiden Plattformen schneller abgeschlossen als bei paralleler Entwicklung, weil kein Kontextwechsel zwischen Plattformen mid-Feature. Lernen von der ersten Plattform verbessert die Implementierung der zweiten Plattform.
Fokus-Herausforderung: Infrastrukturautomatisierung, Sicherheitspatches, Kostenoptimierung und Plattformmigrationen konkurrieren.
Sprint-Ziel Beispiel: "AWS-Kosten um 25% durch Rightsizing und Reserved Instances reduzieren"
DoD-Ergänzungen:
Fokus-Herausforderung: FERPA-Compliance, Schülerdatenschutz, Funktionsentwicklung, Barrierefreiheitsanforderungen.
Sprint-Ziel Beispiel: "WCAG 2.1 AA-Compliance für Schüler-Aufgabenabgabe erreichen"
DoD-Ergänzungen:
Fokus-Herausforderung: 508-Barrierefreiheit, FISMA-Compliance, öffentliche Aufzeichnungsanforderungen, bürgernahe Funktionen.
Sprint-Ziel Beispiel: "Bürgern ermöglichen, FOIA-Anfragen elektronisch mit 508-Compliance einzureichen"
DoD-Ergänzungen:
Zeitrahmen: Sprints 1-6
Merkmale:
Typisches Sprint-Ziel: "Während Sprint Planning ausgewählte Elemente abschließen" (kein echtes Ziel)
Verbesserungsmaßnahmen:
Zeitrahmen: Sprints 7-15
Merkmale:
Typisches Sprint-Ziel: "Kunden-Onboarding-Erfahrung verbessern" (richtungsweisend aber nicht messbar)
Verbesserungsmaßnahmen:
Zeitrahmen: Sprints 16-30
Merkmale:
Typisches Sprint-Ziel: "Warenkorb-Abbruch von 60% auf 45% reduzieren durch Implementierung von Gast-Checkout" (spezifisch, messbar)
Fokus-Indikatoren:
Zeitrahmen: Sprint 30+
Merkmale:
Typisches Sprint-Ziel: "API-Versionierungsmigration abschließen, die Deprecation von v1-Endpunkten bis Q1-Ende ermöglicht" (strategische Ausrichtung)
Fortgeschrittene Praktiken:
Fokus kann durch mehrere objektive Metriken gemessen werden:
Work-in-Progress (WIP):
Durchlaufzeit:
Sprint-Ziel-Erreichungsrate:
Durchsatz:
Scope-Stabilität:
Flow-Effizienz:
Velocity-Konsistenz:
Messungs-Vorsicht: Metriken nicht für individuelle Bewertung instrumentalisieren. Team-Metriken für Verbesserungsgespräche in Retrospektiven verwenden, nicht Leistungsmanagement. Fokus ist Team-Fähigkeit, nicht individuelles Attribut.
Der Scrum-Wert Fokus ist essentiell für die Navigation von Komplexität und Wertlieferung in unsicheren Umgebungen. Fokus bedeutet, die Aufmerksamkeit des Scrum Teams auf die Arbeit des Sprints und die Ziele des Scrum Teams zu konzentrieren - nicht verstreut über mehrere konkurrierende Prioritäten, die geschäftigen Anschein, aber minimale Fertigstellung schaffen.
Wichtige Erkenntnisse zur Aufrechterhaltung des Fokus:
Starten Sie dort, wo Sie sind: Wenn Ihr Team derzeit hohen WIP hat, experimentieren Sie mit der Reduzierung im nächsten Sprint und messen Sie die Auswirkung auf die Durchlaufzeit. Wenn Sprint-Ziele vage sind, investieren Sie mehr Sprint Planning Zeit in die Gestaltung spezifischer ergebnisorientierter Ziele. Wenn Mid-Sprint-Ergänzungen den Fokus stören, üben Sie "Ja, und wir werden es für den nächsten Sprint priorisieren" Antworten.
Fokus bedeutet nicht starre Inflexibilität - es bedeutet, Aufmerksamkeit lange genug zu konzentrieren, um wertvolle Arbeit abzuschließen, anstatt ständig zu starten, aber nie zu beenden. Teams, die Fokus meistern, liefern mehr Wert schneller mit höherer Qualität als Teams, die Aufmerksamkeit über zu viele Prioritäten gleichzeitig zerstreuen.
Wie unterscheidet sich Fokus in Scrum von Fokus in Kanban?
Wie können geografisch verteilte Teams Fokus über Zeitzonen hinweg aufrechterhalten?
Was, wenn die Organisationskultur 'Beschäftigtsein' über Wertlieferung belohnt und Druck schafft, ständige Aktivität zu zeigen?
Wie funktioniert Fokus, wenn das Team neue Funktionsentwicklung mit Produktionssupport balancieren muss?
Kann Fokus zu eng sein und dazu führen, dass Teams wichtige Signale oder Chancen verpassen?
Wie baut man Fokus in Teams auf, die von Waterfall umsteigen, wo Multitasking die Norm war?
Wie interagiert Fokus mit technischen Spikes oder Forschungsarbeit, die keine versandfertigen Increments produziert?
Was, wenn der Product Owner unerfahren ist und keine klaren Prioritäten setzen kann?
Wie gelten Fokus-Prinzipien für kleine Teams (2-3 Personen) im Vergleich zu großen Teams (8-9 Personen)?
Wie kann Fokus während organisatorischer Veränderungen, Entlassungen oder Umstrukturierungen aufrechterhalten werden?
Wie verhält sich Fokus in Scrum Teams im Vergleich zu Fokus in Startups, die Shape Up oder andere Frameworks verwenden?
Was, wenn Stakeholder Fortschrittstransparenz fordern, die Berichtsaufwand schafft, der Fokus untergräbt?
Wie gelten Fokus-Prinzipien, wenn das Team mehrere Produkte oder Produktlinien warten muss?
Kann Fokus objektiv gemessen werden, und welche Metriken zeigen verbesserten Fokus an?
Wie funktioniert Fokus in innovationslastigen Umgebungen, wo Experimentieren und Exploration notwendig sind?