Scrum ist ein agiles Rahmenwerk für die Entwicklung komplexer Produkte. Es kennt drei Verantwortlichkeiten (Product Owner, Scrum Master, Developers), fünf Events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) und drei Artefakte (Product Backlog, Sprint Backlog, Increment). Gearbeitet wird in Sprints von höchstens einem Monat, an deren Ende ein nutzbares Inkrement steht.
Was Scrum ist — und was nicht
Scrum ist ein leichtgewichtiges Rahmenwerk, mit dem Teams komplexe Probleme iterativ lösen. Es ist bewusst keine vollständige Methode und keine Schritt-für-Schritt-Anleitung, sondern ein Gerüst aus Rollen, Events und Artefakten, das ein Team mit eigener Praxis füllt. Genau diese Offenheit ist Stärke und Herausforderung zugleich.
Der Ursprung von Scrum liegt in der Softwareentwicklung, doch das Rahmenwerk wird heute weit darüber hinaus eingesetzt — überall, wo unter Unsicherheit gearbeitet wird und früher, regelmässiger Fortschritt zählt. Scrum beruht auf empirischer Prozesskontrolle: Entscheidungen basieren auf Beobachtung und Erfahrung, nicht auf einem starren Plan, der zu Beginn festgelegt wurde.
Drei Säulen tragen diesen empirischen Ansatz: Transparenz, Überprüfung und Anpassung. Alles Relevante wird sichtbar gemacht, regelmässig überprüft und bei Bedarf angepasst. Diese Schleife wiederholt sich in festem Rhythmus und ist der eigentliche Motor von Scrum.
Bedeutung und Herkunft
Der Begriff Scrum stammt aus dem Rugby und bezeichnet dort das Gedränge, in dem ein Team gemeinsam den Ball erobert. Übertragen auf Produktentwicklung wurde er 1986 in einem Artikel von Hirotaka Takeuchi und Ikujiro Nonaka. Ken Schwaber und Jeff Sutherland formten daraus in den 1990er-Jahren das heutige Rahmenwerk und beschreiben es im Scrum Guide, dessen aktuelle Fassung von 2020 stammt. Der Guide ist kurz und kostenlos verfügbar — Scrum ist also kein proprietäres Verfahren, sondern ein offen beschriebenes Rahmenwerk.
Scrum ist bewusst leicht gehalten: Es legt nur wenige Rollen, Events und Artefakte fest und lässt offen, mit welchen Techniken ein Team arbeitet. Diese Lücke ist Absicht. Teams ergänzen Scrum um Praktiken, die zu ihrer Arbeit passen — etwa User Stories, Schätzverfahren oder Kanban-Boards.
Die drei Säulen: Transparenz, Überprüfung, Anpassung
Scrum beruht auf empirischer Prozesssteuerung: Entscheidungen werden auf Basis dessen getroffen, was tatsächlich beobachtet wird, nicht auf Basis eines vorab vollständigen Plans. Dafür braucht es drei Säulen.
- Transparenz: Arbeit, Fortschritt und Probleme sind für alle Beteiligten sichtbar — über Backlogs, Boards und das Inkrement.
- Überprüfung: In festen Abständen wird geprüft, ob das Team auf dem richtigen Weg ist — in Daily Scrum, Sprint Review und Retrospektive.
- Anpassung: Zeigt die Überprüfung eine Abweichung, wird sofort nachgesteuert — am Plan, am Produkt oder an der Arbeitsweise.
Die fünf Scrum-Werte
Der Scrum Guide nennt fünf Werte, die das Rahmenwerk tragen. Ohne sie bleiben Rollen und Events leere Rituale.
| Wert | Bedeutung im Alltag |
|---|---|
| Commitment | Das Team verpflichtet sich auf seine Ziele und unterstützt sich gegenseitig. |
| Fokus | Die Arbeit konzentriert sich auf das Sprint-Ziel statt auf viele parallele Themen. |
| Offenheit | Fortschritt, Schwierigkeiten und Fehler werden offen angesprochen. |
| Respekt | Die Beteiligten respektieren sich als fähige, eigenständige Menschen. |
| Mut | Das Team spricht schwierige Themen an und trifft auch unbequeme Entscheidungen. |
Die drei Rollen
Scrum kennt drei Verantwortlichkeiten, die zusammen das Scrum-Team bilden:
- Product Owner — verantwortet den Wert des Produkts, pflegt und priorisiert das Product Backlog und entscheidet, was gebaut wird.
- Scrum Master — sorgt für das Verständnis und die Wirksamkeit von Scrum, beseitigt Hindernisse und schützt das Team vor Störungen.
- Entwickler — das Team, das in jedem Sprint ein nutzbares Inkrement liefert und selbst organisiert, wie die Arbeit erledigt wird.
Wichtig ist die Trennung von Verantwortung: Der Product Owner entscheidet über das Was, das Entwicklungsteam über das Wie. Vermischen sich diese Rollen, leidet entweder die Priorisierung oder die Selbstorganisation.
Die Events
Scrum strukturiert die Arbeit in Sprints — festen Zeiträumen von meist zwei bis vier Wochen. Innerhalb eines Sprints finden vier Events statt, die für Rhythmus und Transparenz sorgen:
- 01Sprint PlanningZu Beginn legt das Team fest, welches Ziel der Sprint verfolgt und welche Backlog-Einträge dafür umgesetzt werden.
- 02Daily ScrumEin kurzes tägliches Treffen, in dem sich das Team synchronisiert und Hindernisse benennt.
- 03Sprint ReviewAm Ende wird das Inkrement den Stakeholdern gezeigt und Feedback eingeholt.
- 04Sprint RetrospectiveDas Team reflektiert die Zusammenarbeit und beschliesst konkrete Verbesserungen.
Diese Events sind keine Bürokratie, sondern die Überprüfungs- und Anpassungspunkte des empirischen Prozesses. Wer sie streicht, höhlt Scrum aus — übrig bleibt dann oft nur ein umbenannter Wasserfall mit Sprint-Etikett.
Die Artefakte
Drei Artefakte machen die Arbeit transparent:
- Product Backlog — die geordnete, nie vollständig fertige Liste aller bekannten Anforderungen, verantwortet vom Product Owner.
- Sprint Backlog — die für den aktuellen Sprint ausgewählte Arbeit plus Plan zur Umsetzung.
- Inkrement — das nutzbare, potenziell auslieferbare Ergebnis am Ende des Sprints.
Jedem Artefakt ist ein Commitment zugeordnet: dem Product Backlog das Produktziel, dem Sprint Backlog das Sprintziel, dem Inkrement die Definition of Done. Diese Commitments schaffen Fokus und eine gemeinsame Vorstellung davon, was „fertig“ bedeutet.
Unsicher, ob Scrum zu Ihrem Vorhaben passt? Der Methoden-Finder ordnet Ihr Projekt anhand von vier Fragen zwischen klassisch, agil und hybrid ein.
Wann Scrum passt — und wann nicht
Scrum entfaltet seinen Wert bei unklaren oder sich wandelnden Anforderungen, bei denen früher, regelmässiger Output und kontinuierliche Anpassung zählen. Produktentwicklung unter Unsicherheit ist der klassische Anwendungsfall.
Weniger geeignet ist Scrum für Vorhaben mit fixem Umfang, festen Terminen und stabilen Anforderungen — dort schafft ein plangetriebener Ansatz mehr Klarheit. Auch für reine Fliessarbeit ohne natürliche Iterationen, etwa im Support oder Betrieb, ist Kanban oft die bessere Wahl.
Häufige Stolpersteine
Scrum scheitert selten an der Methode, sondern an halber Umsetzung. Typische Muster:
- Events werden gestrichen oder zur reinen Statusrunde degradiert.
- Der Product Owner priorisiert nicht wirklich, sodass das Team alles gleichzeitig bearbeitet.
- Retrospektiven bleiben folgenlos, weil beschlossene Verbesserungen nie umgesetzt werden.
- Die Definition of Done ist unklar, sodass „fertig“ für jeden etwas anderes bedeutet.
Scrum wirkt nur, wenn die Rückkopplungsschleifen ernst genommen werden. Das Rahmenwerk ist absichtlich minimal — es zeigt Probleme auf, löst sie aber nicht von selbst. Diese Sichtbarkeit ist der eigentliche Wert: Scrum macht Dysfunktionen sichtbar, damit ein Team sie angehen kann.
Ein Sprint im Ablauf: ein Beispiel
Angenommen, ein Team arbeitet in Sprints von zwei Wochen. Am ersten Tag findet das Sprint Planning statt: Der Product Owner stellt die wichtigsten Backlog-Einträge vor, das Team formuliert ein Sprint-Ziel und wählt die Einträge aus, die es dafür umsetzen kann. Danach trifft sich das Team jeden Morgen für höchstens 15 Minuten zum Daily Scrum, um den Fortschritt Richtung Ziel abzugleichen und Hindernisse sichtbar zu machen.
Am Ende der zwei Wochen zeigt das Team im Sprint Review das Ergebnis den Stakeholdern und sammelt Rückmeldungen, die in das Product Backlog einfliessen. In der anschliessenden Retrospektive betrachtet das Team seine Zusammenarbeit und vereinbart eine oder zwei konkrete Verbesserungen. Am nächsten Tag beginnt der neue Sprint — ohne Pause dazwischen.
Schätzen und Planen in Scrum
Der Scrum Guide schreibt keine Schätzmethode vor. In der Praxis schätzen viele Teams Backlog-Einträge relativ zueinander in Story Points, häufig mit Planning Poker. Aus den abgeschlossenen Punkten mehrerer Sprints ergibt sich die Velocity, mit der sich grob abschätzen lässt, wie viel in künftigen Sprints möglich ist. Wichtig: Velocity ist ein Planungswerkzeug für das Team, kein Leistungsvergleich zwischen Teams.
Scrum in der Schweiz: mit HERMES kombinieren
In der Schweizer Verwaltung und bei bundesnahen Betrieben wird Scrum häufig innerhalb von HERMES eingesetzt. HERMES regelt dann Steuerung, Rollen, Ergebnisse und Meilenstein-Entscheide, während das Entwicklungsteam innerhalb dieses Rahmens nach Scrum arbeitet. Entscheidend ist, die Meilensteine auf Zeitpunkte zu legen, an denen ein integrierter, vorführbarer Stand vorliegt — typischerweise das Ende mehrerer Sprints oder eines Releases.
Häufige Fragen
- Wie lang sollte ein Sprint sein?
- Üblich sind zwei bis vier Wochen. Kürzere Sprints geben schnelleres Feedback, längere mehr Raum für umfangreichere Arbeit. Wichtig ist eine gleichbleibende Länge, damit sich ein verlässlicher Rhythmus einstellt.
- Braucht jedes Team einen Scrum Master?
- Die Rolle ist zentral, muss aber nicht zwingend eine eigene Vollzeitstelle sein. Entscheidend ist, dass jemand die Wirksamkeit von Scrum sicherstellt und Hindernisse beseitigt.
- Was ist der Unterschied zwischen Scrum und Kanban?
- Scrum arbeitet in festen Sprints mit definierten Rollen und Events. Kanban ist flussbasiert, ohne feste Iterationen, und begrenzt die parallele Arbeit über WIP-Limits. Beide lassen sich kombinieren.
- Ist Scrum dasselbe wie agil?
- Nein. Agil ist ein Oberbegriff für eine Haltung und Prinzipien. Scrum ist ein konkretes Rahmenwerk, das diese Prinzipien umsetzt — eines von mehreren.
- Was bedeutet Scrum?
- Scrum ist ein agiles Rahmenwerk für die Entwicklung komplexer Produkte in kurzen Zyklen, den Sprints. Der Name stammt aus dem Rugby und steht für ein Team, das gemeinsam ein Ziel verfolgt.
- Was sind die Scrum-Werte?
- Commitment, Fokus, Offenheit, Respekt und Mut. Sie tragen die Zusammenarbeit im Team und machen Rollen und Events erst wirksam.
- Wie wird in Scrum geschätzt?
- Scrum schreibt kein Schätzverfahren vor. Verbreitet sind relative Schätzungen in Story Points, etwa mit Planning Poker, aus denen sich über mehrere Sprints die Velocity des Teams ergibt.
- Wer hat Scrum erfunden?
- Ken Schwaber und Jeff Sutherland entwickelten Scrum in den 1990er-Jahren und beschreiben es im Scrum Guide, zuletzt in der Fassung von 2020.