Was ist Scrum in einfachen Worten?
Scrum ist ein leichtgewichtiges Framework zur Entwicklung komplexer Produkte durch iterative Arbeitszyklen, sogenannte 'Sprints'. Alle 1-4 Wochen (meist 2) liefert ein kleines, funktionsübergreifendes Team ein funktionierendes Produktteil, erhält Feedback und passt sich an. Es verwendet eine einfache Struktur: 3 spezifische Rollen (Product Owner, Scrum Master, Entwickler), 5 zeitlich begrenzte Ereignisse (Sprint, Planung, Daily Scrum, Review, Retrospektive) und 3 Artefakte (Product Backlog, Sprint Backlog, Inkrement).
Scrum beantwortet die Frage: 'Wie liefern wir komplexe Produkte in einem vorhersehbaren Rhythmus und verbessern uns kontinuierlich?'
Die 3-5-3-Struktur: Scrums elegante Einfachheit
Scrum ist das beliebteste agile Framework, das laut dem State of Agile Report von etwa 66 % der agilen Teams verwendet wird. Es wurde Anfang der 1990er Jahre von Jeff Sutherland und Ken Schwaber entwickelt und bietet eine leichtgewichtige, aber leistungsstarke Struktur, die täuschend einfach ist: 3 Rollen, 5 Ereignisse und 3 Artefakte. Die Regeln passen auf wenige Seiten, aber Scrum zu meistern erfordert Übung – das Framework deckt Probleme auf, löst sie aber nicht für Sie.
Der Name 'Scrum' stammt aus dem Rugby, wo ein Scrum eine Formation ist, die es dem Team ermöglicht, zusammenzuarbeiten, um den Ball über das Feld zu bewegen. Wie im Rugby sind Scrum-Teams klein, selbstorganisierend und arbeiten in enger Koordination auf ein gemeinsames Ziel hin.
Die 3 Rollen (Das Scrum Team)
Ein Scrum Team besteht typischerweise aus 10 oder weniger Personen. Es gibt keine Unterteams oder Hierarchien. Jeder ist dafür verantwortlich, in jedem Sprint Wert zu liefern.
Product Owner
Das „Was“ – Wert maximieren
Besitzt das Product Backlog und ist dafür verantwortlich, den Wert des Produkts zu maximieren. Entscheidet, welche Funktionen in welcher Reihenfolge gebaut werden sollen. Repräsentiert die Stimme des Kunden, der Stakeholder und des Unternehmens. Trifft Abwägungsentscheidungen: 'Sollen wir Funktion A oder B zuerst bauen?' Eine Person, kein Komitee – klare Verantwortlichkeit. Muss befugt sein, Entscheidungen zu treffen, ohne ständig um Genehmigung bitten zu müssen.
Scrum Master
Der „Prozess“ – Effektivität ermöglichen
Ein Servant-Leader, der für die Effektivität des Scrum Teams verantwortlich ist. Stellt sicher, dass das Team die Scrum-Praktiken korrekt befolgt. Beseitigt Hindernisse (Blocker), die das Team verlangsamen. Schirmt das Team vor externen Ablenkungen ab. Coacht das Team und die Organisation bei der Scrum-Einführung. Verwaltet das Team NICHT – erleichtert es. Weist KEINE Aufgaben zu – das Team organisiert sich selbst.
Entwickler
Das „Wie“ – Das Inkrement liefern
Funktionsübergreifende Fachleute, die in jedem Sprint das Inkrement erstellen. Umfasst alle Fähigkeiten, die zur Lieferung erforderlich sind: Design, Entwicklung, Testen usw. (der Begriff 'Entwickler' bedeutet nicht nur Programmierer). Organisieren sich selbst, um zu entscheiden, wie Sprint-Ziele erreicht werden. Typischerweise 3-9 Personen (kleiner für bessere Kommunikation). Kollektiv verantwortlich für das Sprint Backlog und die Definition of Done.
Die 5 Ereignisse (Der Herzschlag von Scrum)
Alle Ereignisse sind zeitlich begrenzt (haben maximale Dauern), um verschwendete Zeit in Meetings zu minimieren. Jedes Ereignis ist eine Gelegenheit zur Überprüfung und Anpassung.
Der Sprint
Der Sprint ist der Container für alle anderen Ereignisse – der Herzschlag von Scrum. Es ist eine Iteration fester Länge, in der ein 'fertiges', nutzbares Inkrement erstellt wird. Sprints finden direkt hintereinander ohne Lücken statt. Während eines Sprints: keine Änderungen, die das Sprint-Ziel gefährden, Qualitätsstandards sinken nicht, und das Product Backlog wird bei Bedarf verfeinert. Ein neuer Sprint beginnt unmittelbar nach dem Ende des vorherigen.
Sprint Planning
Der Sprint beginnt mit dem Sprint Planning, bei dem das Team die Fragen beantwortet: 'Warum ist dieser Sprint wertvoll?' (Sprint-Ziel), 'Was kann geliefert werden?' (ausgewählte Product Backlog-Einträge) und 'Wie wird die Arbeit erledigt?' (Plan für die Lieferung). Das Ergebnis ist das Sprint Backlog. Der Product Owner schlägt Elemente vor; die Entwickler bestimmen, wie viel sie realistisch erreichen können.
Daily Scrum (Stand-up)
Ein tägliches 15-minütiges Ereignis für Entwickler, um sich zu synchronisieren und einen Plan für die nächsten 24 Stunden zu erstellen. Gleiche Zeit, gleicher Ort, jeden Arbeitstag. Kein Statusbericht an das Management – es ist für das Team, sich selbst zu organisieren. Klassisches Format: 'Was habe ich gestern gemacht? Was werde ich heute tun? Irgendwelche Blocker?' Moderne Teams konzentrieren sich oft auf den Fortschritt zum Sprint-Ziel anstatt auf individuelle Updates. Wenn Diskussionen entstehen, führen Sie diese offline.
Sprint Review
Am Ende des Sprints demonstriert das Team das Inkrement den Stakeholdern und bespricht den Fortschritt zum Produktziel. Dies ist KEIN Statusmeeting oder Genehmigungstor – es ist eine interaktive Arbeitssitzung. Stakeholder geben Feedback, das zu Änderungen im Product Backlog führen kann. Der Product Owner könnte Prioritäten basierend auf dem Gelernten anpassen. Feiern Sie das Erreichte.
Sprint Retrospective
Das letzte Ereignis des Sprints – das Team überprüft sich selbst und erstellt einen Plan zur Verbesserung. 'Was lief gut?' 'Was könnten wir verbessern?' 'Was werden wir im nächsten Sprint verbessern?' Dies ist der Motor der kontinuierlichen Verbesserung. Konzentrieren Sie sich auf Menschen, Prozesse und Tools. Identifizieren Sie die wirkungsvollsten Verbesserungen, die sofort umgesetzt werden sollen. Einige Teams verwenden Formate wie Start-Stop-Continue oder 4Ls (Liked, Learned, Lacked, Longed For).
Die 3 Artefakte (Transparenz der Arbeit)
Artefakte repräsentieren Arbeit oder Wert. Sie sind darauf ausgelegt, die Transparenz zu maximieren, damit jeder das gleiche Verständnis von der Arbeit und dem Fortschritt hat.
Product Backlog
Die einzige Quelle der Wahrheit für alle Arbeiten, die im Produkt benötigt werden könnten. Eine geordnete, emergente Liste von Funktionen, Fehlerbehebungen, Verbesserungen und technischer Arbeit. Exklusiv im Besitz des Product Owners. Elemente oben sind gut definiert und bereit zur Auswahl; Elemente weiter unten sind weniger detailliert. Ständig verfeinert – Elemente werden hinzugefügt, entfernt und neu priorisiert, wenn Erkenntnisse gewonnen werden. Das Commitment: Produktziel (das langfristige Ziel).
Sprint Backlog
Die für den Sprint ausgewählten Product Backlog-Elemente, plus der Plan des Teams, diese zu liefern und das Sprint-Ziel zu erreichen. Im Besitz der Entwickler – es ist ihr Commitment für den Sprint. Ein sehr sichtbares, Echtzeit-Bild der Arbeit, die das Team zu leisten plant. Wird während des Sprints aktualisiert, wenn Arbeit abgeschlossen und neue Arbeit entdeckt wird. Das Commitment: Sprint-Ziel (das einzige Ziel für den Sprint).
Inkrement
Die Summe aller abgeschlossenen Product Backlog-Elemente während des Sprints plus aller vorherigen Inkremente. Muss die Definition of Done erfüllen – eine formale Beschreibung der Qualitätsstandards. Ein Inkrement muss nutzbar und potenziell freigabefähig sein (auch wenn die Entscheidung ist, nicht freizugeben). Mehrere Inkremente können innerhalb eines Sprints geliefert werden. Das Commitment: Definition of Done (die Qualitätscheckliste).
Schlüsselmetriken in Scrum
Metriken helfen Teams, ihre Leistung zu überprüfen und zukünftige Arbeit zu prognostizieren. Der Schlüssel ist, sie zur Verbesserung und nicht zur Beurteilung zu verwenden.
Velocity
Misst, wie viel Arbeit (in Story Points oder anderen Einheiten) ein Team pro Sprint abschließt. Wird zur Prognose verwendet: 'Bei dieser Velocity werden wir das Backlog in X Sprints abschließen.' Wichtig: Vergleichen Sie niemals die Velocity zwischen Teams – sie ist spezifisch für den Schätzstil jedes Teams.
Sprint Burndown
Zeigt die verbleibende Arbeit im Sprint über die Zeit. Hilft dem Team zu sehen, ob es auf Kurs ist, sein Commitment zu erfüllen. Wird täglich aktualisiert.
Sprint Goal Success Rate
Prozentsatz der Sprints, in denen das Team das Sprint-Ziel erreicht hat. Ein Maß für Vorhersehbarkeit und Zuverlässigkeit des Commitments.
Vor- und Nachteile von Scrum
Vorteile
- Bietet Struktur und Vorhersehbarkeit mit regelmäßigem Sprint-Rhythmus
- Liefert häufig funktionierende Produktinkremente (früher Wert)
- Eingebaute kontinuierliche Verbesserung durch Retrospektiven
- Klare Rollen und Verantwortlichkeiten reduzieren Verwirrung
- Transparenz durch Artefakte hilft allen, auf einer Linie zu bleiben
- Einfach zu übernehmen – Framework passt auf wenige Seiten
Herausforderungen
- •Erfordert erhebliche organisatorische Veränderungen (befähigte Teams)
- •Sprint-Grenzen können für einige Arbeitsarten künstlich wirken
- •Risiko eines 'Mini-Waterfalls' innerhalb jedes Sprints
- •Meetings (Zeremonien) können für manche übermäßig wirken
- •Lässt sich ohne zusätzliche Frameworks (z.B. SAFe) nicht leicht skalieren
- •Die Rolle des Product Owners ist anspruchsvoll – Engpass, wenn nicht gut ausgeführt
Häufige Scrum-Fehler, die es zu vermeiden gilt
❌ Scrum Master als traditioneller Manager
✓ Der Scrum Master moderiert, coacht und beseitigt Blockaden. Er weist keine Aufgaben zu, mikromanagt nicht und trifft keine technischen Entscheidungen. Das Team organisiert sich selbst.
❌ Retrospektiven überspringen
✓ Retrospektiven sind der Motor der Verbesserung. Sie zu überspringen bedeutet, dass das Team seinen Prozess nie verbessert. Halten Sie sie immer ab, auch wenn sie kurz sind.
❌ Sprint Planning ohne Ziel
✓ Das Sprint-Ziel gibt der Arbeit einen Sinn. Ohne es wird der Sprint nur zu einer Liste von Aufgaben statt zu einer kohärenten Anstrengung auf ein Ziel hin.
❌ Den Daily Scrum als Statusmeeting behandeln
✓ Es ist für das Team, sich zu synchronisieren, nicht für die Berichterstattung an Manager. Halten Sie es auf 15 Minuten und konzentrieren Sie sich auf Zusammenarbeit, nicht auf Status-Updates.
❌ Arbeit mitten im Sprint ändern
✓ Schützen Sie das Sprint-Commitment. Wenn sich Prioritäten ständig verschieben, kann das Team niemals vorhersehbar liefern. Verwenden Sie das Product Backlog für dringende Änderungen.
Wichtige Erkenntnisse
- 1Scrum ist ein leichtgewichtiges Framework mit 3 Rollen, 5 Ereignissen und 3 Artefakten
- 2Sprints sind der Herzschlag – Iterationen fester Länge, die funktionierende Inkremente liefern
- 3Der Product Owner besitzt das 'Was', die Entwickler besitzen das 'Wie', der Scrum Master ermöglicht Effektivität
- 4Alle Ereignisse sind Gelegenheiten zur Überprüfung und Anpassung – Transparenz ist unerlässlich
- 5Velocity dient der Prognose, nicht dem Vergleich von Teams oder der Leistungsbeurteilung
- 6Retrospektiven treiben die kontinuierliche Verbesserung voran – überspringen Sie sie niemals
