Scrum: Das agile Rahmenwerk in der Praxis

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.

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:

1. 01
   Sprint PlanningZu Beginn legt das Team fest, welches Ziel der Sprint verfolgt und welche Backlog-Einträge dafür umgesetzt werden.
2. 02
   Daily ScrumEin kurzes tägliches Treffen, in dem sich das Team synchronisiert und Hindernisse benennt.
3. 03
   Sprint ReviewAm Ende wird das Inkrement den Stakeholdern gezeigt und Feedback eingeholt.
4. 04
   Sprint 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.

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.

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.