Scrum ist ein leichtes Rahmenwerk, mit dem Teams unter Unsicherheit schneller lernen und verlässlicher liefern. Für viele wachsende kleine Unternehmen ist Scrum nicht deshalb interessant, weil es „agil" klingt, sondern weil es Reibung im Alltag spürbar reduziert.
Die offizielle Grundlage ist der Scrum Guide von November 2020. Gegenüber älteren Fassungen wurde der Kern dort geschärft: weniger Vorschriften, präzisere Verantwortlichkeiten, und jede der drei Stellen, an denen die Arbeit des Teams ablesbar ist, trägt seither eine verbindliche Zusage.
Herausgegeben wird er von Ken Schwaber und Jeff Sutherland, die Scrum 1995 formalisiert haben. Das 2025 erschienene „Scrum Guide Expansion Pack" ergänzt die Fassung von 2020 unverbindlich und ersetzt sie nicht.
Das Wichtigste in Kürze
- Iteratives Arbeiten: Scrum teilt Arbeit in kurze Sprints von 1–4 Wochen auf; nach jedem Sprint entsteht ein nutzbares Zwischenergebnis, das den Plan anpassbar hält.
- Drei Verantwortlichkeiten: Product Owner priorisiert den Wert, Scrum Master schützt das System, Developers verantworten gemeinsam die Umsetzung. Verteilte Verantwortung ersetzt die klassische Weisungskette.
- Commitments pro Artefakt: Artefakt heißt in Scrum ein Arbeitsstand, an dem jeder sehen kann, wo das Team steht. Product Backlog, Sprint Backlog und Increment tragen jeweils ein verbindliches Commitment, das Arbeit an Ziel und Qualität bindet.
- Fünf feste Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review und Retrospektive bilden einen geschlossenen Lernzyklus ohne zusätzlichen Overhead.
- Fit-Kriterium: Scrum wirkt als Takt- und Priorisierungsprinzip überall dort, wo Anforderungen unsicher sind und schnelles Lernen zum Lieferergebnis gehört.
Scrum vs. klassisches Projektmanagement
Im klassischen Wasserfall-Modell wird ein Vorhaben einmal vorab geplant und dann sequenziell abgearbeitet, Anforderungen, Design, Umsetzung, Test, Übergabe. Das funktioniert, solange sich Anforderungen nicht ändern und das Endergebnis vorhersehbar ist.
Scrum geht den umgekehrten Weg. Geplant wird jeweils nur der nächste Zyklus; danach zeigt ein nutzbares Zwischenergebnis, ob der Plan getragen hat, und er wird daran angepasst.
Der Preis dafür ist ein Endtermin, den niemand vorab nennen kann. Wer im Januar wissen muss, was im Oktober fertig ist, bekommt von Scrum nach jedem Sprint einen belastbaren Zwischenstand und kein Datum. Für Vorhaben mit fester Abnahme und stabilem Umfang bleibt die klassische Planung die bessere Wahl.
Sobald ein Unternehmen wächst, steigen gleichzeitig:
- die Zahl der Stakeholder,
- die Zahl der parallelen Aufgaben,
- die Zahl der Zielkonflikte.
Ohne klaren Takt kippt der Alltag in Reaktionsmodus. Teams sind beschäftigt, aber Fortschritt wird unscharf. Entscheidungen stauen sich oben. Hier setzt Scrum an, mit einem festen Sprint-Rhythmus und einem geordneten Backlog, dessen Reihenfolge jemand verantwortet.
Die drei Accountabilities (Rollen)
Scrum kennt drei verbindliche Verantwortlichkeiten:
- Product Owner: verantwortet Produktwert und Priorisierung. Entscheidet, was im Backlog steht und in welcher Reihenfolge gearbeitet wird.
- Scrum Master: verantwortet die Wirksamkeit des Systems. Räumt Hindernisse aus, schützt den Sprint und stärkt die Selbstorganisation des Teams.
- Developers: verantworten gemeinsam die Umsetzung im Sprint. „Developers" meint in der aktuellen Fassung alle umsetzenden Rollen, auch außerhalb der Softwareentwicklung.
Diese drei Verantwortungen bilden zusammen das Scrum-Team. Sie stehen auf einer Ebene: Keine der drei weist den anderen Arbeit zu.
Für eine bestehende Teamleitung ist das die unbequemste Stelle des Modells. Ihre Aufgabe wechselt den Ort. Wer heute Arbeit zuteilt, entscheidet künftig über Reihenfolge und Wert und trägt damit die Verantwortung des Product Owners. Bleibt die alte Zuteilung daneben bestehen, hat das Team zwei Steuerungen und folgt der lauteren.
Die fünf Events
Scrum hat genau fünf Events. Jedes hat einen definierten Zweck:
- Sprint: der zeitlich begrenzte Arbeitszyklus (1–4 Wochen), der Container für alle anderen Events.
- Sprint Planning: Ziel und Plan für den Sprint werden gemeinsam festgelegt.
- Daily Scrum: täglicher Fokusabgleich (15 Minuten, reine Abstimmung im Team).
- Sprint Review: das Ergebnis kommt auf den Tisch, Stakeholder reagieren darauf, das Backlog wird angepasst. Thema ist das Produkt.
- Sprint Retrospective: das Team schaut auf seine eigene Arbeitsweise und nimmt sich ein bis drei Verbesserungen vor. Thema ist die Zusammenarbeit.
Die letzten beiden werden im Alltag gern zusammengelegt, und damit fällt der Lernzyklus in sich zusammen. Im Review antwortet das Team auf das, was andere gesehen haben; in der Retrospektive auf das, was nur es selbst sieht.
Die drei Artefakte und ihre Commitments
Die drei Artefakte — Product Backlog, Sprint Backlog und Increment — machen sichtbar, was geplant ist, was im Sprint erarbeitet wird und was davon fertig ist. Das Increment ist das greifbarste: Es zeigt, was tatsächlich die Done-Schwelle erreicht hat.
Ein wichtiger Unterschied zum klassischen Projektmanagement: Das Increment ist kein Abschlussergebnis, das am Ende steht, sondern ein laufend wachsendes Gesamtprodukt. Es entsteht Sprint für Sprint, und jeder Sprint erhöht den nutzbaren Stand.
Außerhalb der Softwareentwicklung ist das Increment das, was nach dem Sprint benutzbar ist. In einem Marketing-Team die fertige Landingpage mit ihren Texten, im Service die überarbeitete Reklamationsstrecke, die ab sofort so läuft. Ein Entwurf, den noch jemand freigeben muss, zählt nicht dazu.
Mit dem Scrum Guide 2020 wurde jedes Artefakt um ein Commitment ergänzt, das ist die wichtigste praktische Neuerung:
| Artefakt | Commitment | Funktion |
|---|---|---|
Product Backlog | Product Goal | Was wollen wir mittelfristig erreichen? |
Sprint Backlog | Sprint Goal | Was leisten wir konkret in diesem Sprint? |
Increment | Definition of Done | Wann gilt ein Ergebnis als fertig? |
Eine Zeile in einer Tabelle verhindert das Abarbeiten nicht. Wirksam wird ein Commitment erst, wenn ein verfehltes Sprint Goal im Review auch so benannt wird und nicht als „fast fertig" durchgeht.
Die fünf Scrum-Werte
Strukturen alleine machen Scrum nicht wirksam. Sichtbar wird das an den Stellen, an denen eine Haltung etwas kostet. In der Retrospektive auszusprechen, dass die Sprintplanung seit vier Wochen zu voll ist, kostet Überwindung. Einen Sprint ohne fertiges Increment zu beenden und das im Review offenzulegen ebenfalls. Und am Mittwochnachmittag, wenn die Geschäftsführung eine Zwischenanfrage schickt, entscheidet sich, ob das Sprintziel trägt.
Im Scrum Guide heißen diese drei Haltungen Mut, Offenheit und Fokus; dazu kommen Engagement und Respekt. Als Liste sind das Plakatworte. Kann keine der beschriebenen Situationen bei Ihnen eintreten, ändert eine Werteliste an der Arbeit nichts.
Externer Inhalt
Scrum Values, Scrum Foundations eLearning Series
Zum Anzeigen wird eine Verbindung zu Google Ireland Limited hergestellt. Erst nach Ihrer Freigabe wird der Inhalt geladen.
Fit und No-Fit für kleine und mittlere Unternehmen (KMU)
Scrum passt gut, wenn:
- sich Anforderungen im Verlauf ändern,
- Feedback aus Markt oder Betrieb schnell eingeholt werden muss,
- mehrere Rollen an einem gemeinsamen Ziel arbeiten.
Scrum passt schlecht, wenn:
- die Arbeit fast vollständig standardisiert und vorhersehbar ist,
- es keinen Product-Owner-ähnlichen Entscheidungsanker gibt,
- Führung Tempo fordert, ohne Priorisierungsentscheidungen zu treffen.
Zwei Fragen kommen an dieser Stelle regelmäßig, und beide haben eine kurze Antwort. Zur Größe nennt der Scrum Guide zehn Personen oder weniger; ein Team von fünf bis neun liegt komfortabel darin. Und Software ist keine Voraussetzung, der Takt trägt im Marketing wie im Service, sobald Ergebnisse in kurzen Abständen vorzeigbar sind.
Pragmatische Regel: Scrum ist sinnvoll, wenn Sie Lernen und Anpassung als Teil der Leistung verstehen, nicht als Störung.
Woche 1
- Product Goal schärfen.
- Backlog bereinigen.
- Sprintlänge festlegen.
Woche 2
- Erstes Sprint Planning durchführen.
- Definition of Done auf Minimalniveau etablieren.
- Daily Scrum sauber aufsetzen (15 Minuten, fester Takt).
Woche 3
- Erstes Sprint Review mit relevanten Stakeholdern.
- Backlog auf Basis der Rückmeldungen anpassen.
Woche 4
- Retrospektive mit 1–3 verbindlichen Verbesserungen.
- Verantwortungen und Messpunkte klären.
Starten Sie schlank. Ein kleines, diszipliniert gelebtes Scrum schlägt ein komplexes Prozess-Design, das niemand im Alltag mitträgt.
Häufige Fehler bei der Einführung
Fehler 1: Daily Scrum als Statusmeeting.
Das Daily ist ein Fokusabgleich des Teams. Es dient nicht dem Reporting an die Führung; wenn die Geschäftsführung mithört, kippt das Daily fast immer.
Fehler 2: Product Owner und Scrum Master in einer Person.
Beide Rollen haben gegensätzliche Anreize (Wert maximieren vs. System schützen). Die Doppelrolle führt regelmäßig zu Zielkonflikten.
Fehler 3: Sprints, ohne den Sprint zu schützen.
Sobald Stakeholder mitten im Sprint Prioritäten umwerfen, verliert der Takt seine Wirkung. Änderungen gehören in den nächsten Sprint, nicht in den laufenden.
Fehler 4: Definition of Done als Pflichtübung.
Eine DoD, die nicht im Review angewandt wird, hat keinen Wert. Lieber drei harte Kriterien als zwanzig formale.
Fehler 5: Scrum als Tool-Frage behandeln.
Jira oder Asana lösen kein Fokusproblem. Erst Verantwortlichkeiten und Takt klären, dann Tooling wählen.
Messpunkte für Wirkung
Wenn Scrum wirkt, sehen Sie das innerhalb weniger Wochen:
- kürzere Entscheidungsdauer,
- weniger Prioritätswechsel im laufenden Sprint,
- höherer Anteil abgeschlossener, nutzbarer Ergebnisse,
- klarere Stakeholder-Erwartungen im Review.
Wenn Sie das in Zahlen fassen wollen, genügen zwei Werte pro Sprint. Wie viel von dem Begonnenen wurde abgeschlossen, und wie viel musste nach dem Review noch einmal angefasst werden? Beides sagt mehr als jede Aktivitätsmetrik.
Strategiegespräch
Wenn Scrum bei Ihnen ins Stocken gerät
Wenn Sie prüfen wollen, ob Scrum in Ihrem aktuellen Setup passt, zeigt eine kurze Diagnose für Team-Takt, Priorisierung und Entscheidungsfluss, wo gerade Reibung entsteht, bevor Sie ein großes Transformationsprojekt aufsetzen.
Strategiegespräch vereinbarenHäufige Fragen zu Scrum
Ist Scrum nur für Software?
Nein. Scrum stammt aus der Produktentwicklung und wird heute in Marketing, HR, Service-Operations und Beratung eingesetzt, überall dort, wo Anforderungen unsicher sind und schnelles Lernen Wert schafft.
Brauche ich einen zertifizierten Scrum Master?
Nicht zwingend. Wichtiger als das Zertifikat ist, dass jemand die Rolle als Schutz des Systems versteht und nicht als Projektleitung in neuem Gewand.
Wie unterscheidet sich Scrum von Kanban?
Scrum arbeitet in festen Zeitboxen (Sprints) mit festen Rollen und Events. Kanban ist ein kontinuierlicher Fluss ohne feste Iterationen, mit Fokus auf Limits für laufende Arbeit (WIP-Limits). Beide ergänzen sich gut.
Wie groß sollte ein Scrum-Team sein?
Der Scrum Guide nennt 10 Personen oder weniger. Optimal sind 5–9, klein genug für direkte Abstimmung, groß genug für die nötige Bandbreite.
Wie lange dauert ein Sprint?
1–4 Wochen, einheitlich pro Team. In kleinen Unternehmen sind 2 Wochen ein guter Startpunkt: lang genug für ein nutzbares Increment, kurz genug für schnelles Lernen.
Weiterführend
Agile Methoden
Daily Scrum richtig nutzen: kurz, klar, wirksam
Daily Scrum ohne Statusmeeting-Falle: So richtet das Team den Tag aufs Sprint-Ziel aus, deckt Blocker früh auf und passt den Plan für die nächsten 24 Stunden an.
Agile Methoden
User Stories in Scrum: Klar priorisieren, besser liefern
Wie User Stories in Scrum zu klaren Prioritäten und besseren Ergebnissen führen. Mit Template, INVEST, Akzeptanzkriterien und Beispielen für Teams in KMU.
Agile Methoden
Sprint-Retrospektive: Von Erkenntnis zu Umsetzung
Sprint-Retrospektive praxisnah: Aufbau, Methodenwahl mit Auswahlhilfe und ein verbindliches Format, das Erkenntnisse in konkrete Verbesserungen überführt.