Scrum ist ein Rahmenwerk für die Zusammenarbeit an komplexen Aufgaben. Es definiert drei Verantwortlichkeiten (Product Owner, Scrum Master, Entwickler), drei Artefakte (Product Backlog, Sprint Backlog, Increment) und fünf Ereignisse. Es ist ausdrücklich keine Methode und schreibt keine Technik vor.
Was Scrum ist
Scrum ist ein Rahmenwerk, in dem Teams komplexe Aufgaben in kurzen, festen Zyklen bearbeiten. Der Grundgedanke: Wenn zu Beginn nicht sicher bekannt ist, was genau gebraucht wird, ist es wirksamer, in kurzen Abständen etwas Nutzbares zu liefern und daraus zu lernen, als lange zu planen.
Wichtig ist die Bezeichnung Rahmenwerk. Scrum schreibt keine Vorgehensweisen für Analyse, Entwicklung oder Test vor. Es legt Rollen, Ereignisse und Artefakte fest und lässt bewusst offen, wie die Arbeit inhaltlich erfolgt. Diese Offenheit ist der häufigste Anlass für Frustration bei der Einführung — Organisationen erwarten eine Methode und erhalten ein Gerüst.
Die drei Verantwortlichkeiten
| Rolle | Verantwortet | Häufiges Missverständnis |
|---|---|---|
| Product Owner | Was gebaut wird, Reihenfolge im Backlog, Produktwert | Ist kein Anforderungssammler, sondern entscheidet |
| Scrum Master | Wirksamkeit von Team und Prozess, Hindernisse beseitigen | Ist keine Projektleitung und kein Vorgesetzter |
| Entwickler | Wie gebaut wird, Schätzung, Qualität, Lieferung des Increments | Umfasst alle Fachrichtungen, nicht nur Programmierung |
Die kritischste Rolle ist der Product Owner, und zwar wegen der Entscheidungsbefugnis. Ein Product Owner, der für jede Priorisierung Rücksprache halten muss, blockiert das Team — dann entsteht eine Weiterleitungsstelle statt einer Rolle. Ohne echtes Mandat funktioniert Scrum nicht, und das ist die häufigste organisatorische Hürde bei der Einführung.
Die drei Artefakte
- Product Backlog — die geordnete Liste alles Bekannten, das am Produkt zu tun wäre. Nie fertig, laufend verfeinert. Verantwortung: Product Owner.
- Sprint Backlog — die Auswahl für den laufenden Sprint plus der Plan zur Umsetzung. Gehört den Entwicklern und ist im Sprint nicht von aussen änderbar.
- Increment — das nutzbare Ergebnis am Sprint-Ende. Muss die Definition of Done erfüllen, sonst ist es kein Increment.
Der zweite Punkt trägt eine Konsequenz, die oft unterschätzt wird: Der Sprint-Inhalt ist geschützt. Neue Wünsche gehen ins Product Backlog und kommen frühestens im nächsten Sprint. Wo dieser Schutz nicht durchgehalten wird, entsteht ein Team, das in Zwei-Wochen-Abschnitten unterbrochen arbeitet — mit allen Nachteilen der Iteration und keinem ihrer Vorteile.
Die fünf Ereignisse
| Ereignis | Zweck | Dauer (bei 2 Wochen) |
|---|---|---|
| Sprint | Der Rahmen, in dem alles andere stattfindet | 2 Wochen |
| Sprint Planning | Was und wie wird in diesem Sprint gemacht | max. 4 Stunden |
| Daily Scrum | Abstimmung der Entwickler auf das Sprint-Ziel | 15 Minuten |
| Sprint Review | Increment zeigen, Rückmeldung einholen | max. 2 Stunden |
| Sprint Retrospective | Wie arbeiten wir zusammen, was verbessern wir | max. 1.5 Stunden |
Das Daily Scrum ist Abstimmung der Entwickler untereinander, kein Statusbericht an eine Führungsperson. Sobald reihum an jemanden berichtet wird, ist es ein tägliches Rapportmeeting mit fünfzehn Minuten Länge.
Das Sprint-Ziel
Das am häufigsten weggelassene Element ist das Sprint-Ziel — eine Aussage darüber, wozu dieser Sprint dient. Ohne Ziel ist ein Sprint eine Liste abzuarbeitender Aufgaben, und die Frage, was bei knapper Zeit weggelassen werden kann, lässt sich nicht beantworten.
Mit Ziel funktioniert diese Abwägung: Was auf das Ziel einzahlt, bleibt; was nicht, wandert zurück ins Backlog. Das Sprint-Ziel ist damit weniger Motivationsinstrument als Entscheidungshilfe für den Moment, in dem es eng wird — und der kommt in jedem Sprint.
Was Scrum nicht regelt
Scrum sagt nichts über Schätzverfahren, technische Praktiken, Dokumentation, Architektur, Umgang mit mehreren Teams oder die Rolle klassischer Projektleitung. All das muss die Organisation ergänzen. Wer erwartet, dass Scrum diese Fragen beantwortet, wird enttäuscht und schliesst daraus oft fälschlich, Scrum funktioniere nicht.
In Umgebungen mit Budgetzyklen, Beschaffungsrecht und Gremienstrukturen — etwa der öffentlichen Verwaltung — bedeutet das, Scrum in einen Rahmen einzubetten, der diese Anforderungen abdeckt. Das ist kein Widerspruch zu Scrum, sondern die vorgesehene Ergänzung.
Diese Methode lässt sich in einem Projekt-Tool wie Flenio direkt abbilden — DACH-nativ und DSG-konform gehostet.
Häufige Fragen
- Was ist Scrum einfach erklärt?
- Ein Rahmenwerk, in dem Teams komplexe Aufgaben in kurzen festen Zyklen (Sprints) bearbeiten und am Ende jedes Zyklus etwas Nutzbares liefern. Es definiert drei Verantwortlichkeiten, drei Artefakte und fünf Ereignisse — und lässt bewusst offen, wie inhaltlich gearbeitet wird.
- Welche Rollen gibt es in Scrum?
- Product Owner (entscheidet, was gebaut wird), Scrum Master (verantwortet die Wirksamkeit von Team und Prozess) und Entwickler (entscheiden, wie gebaut wird, und liefern das Increment). Der Begriff Entwickler umfasst alle Fachrichtungen, nicht nur Programmierung.
- Was regelt Scrum nicht?
- Schätzverfahren, technische Praktiken, Dokumentation, Architektur, Skalierung auf mehrere Teams und die Rolle klassischer Projektleitung. Das muss die Organisation ergänzen — Scrum ist ein Rahmenwerk, keine vollständige Methode.