METHODE

Scrum

Ein agiles Framework, das Arbeit in feste Sprints gliedert, mit definierten Rollen, Events und Artefakten, um ein Team in einem engen Liefer- und Inspektionszyklus zu halten.

Zuletzt geprüft: 2026-06-02 vonKevin Riedl wiki ↗

Scrum hat drei Rollen, drei Artefakte und eine Handvoll Events. Der Product Owner entscheidet, was gebaut wird und in welcher Reihenfolge. Der Scrum Master räumt Blockaden aus dem Weg und schützt den Prozess. Die Entwickler bauen es. Die Artefakte sind das Product Backlog (alles, was gebaut werden könnte), das Sprint Backlog (worauf sich dieser Sprint festlegt) und das Increment (was tatsächlich ausgeliefert wird). Die Events sind Sprint Planning, der Daily Standup, das Sprint Review und die Retrospektive.

Wo Scrum wirklich hilft: bei Teams, die mit Fokus und Sichtbarkeit kämpfen. Der feste Sprint erzwingt eine echte Festlegung, das Review erzwingt eine echte Demo, und die Retro zwingt das Team, den eigenen Prozess anzuschauen statt ihn zu ignorieren. Für ein Team, das noch nie in einem Takt geliefert hat, ist Scrum ein nützliches Gerüst.

Wo es zum Theater wird: wenn die Events überleben, aber die Substanz stirbt. Ein Standup, der ein Statusbericht an den Manager ist. Ein Review ohne lauffähige Software zum Zeigen. Eine Retro, die alle zwei Wochen dieselben drei Maßnahmen produziert und keine davon umsetzt. Viele Scrum-Teams führen die Zeremonien durch und holen keinen Wert daraus. Wenn ihr die Meetings macht, aber kein lauffähiges Increment demonstrieren könnt, habt ihr kein Scrum, sondern eine Meeting-Gewohnheit.

Wavects ehrliche Sicht: Scrum ist ein gutes Einstiegs-Framework und eine schlechte Religion. Behaltet die Teile, die Feedback erzeugen, und lasst die Teile weg, die Overhead erzeugen. Die meisten reifen Teams driften zu etwas Leichterem, oft näher an Kanban, sobald die Disziplin verinnerlicht ist.

// FAQ

Häufige Fragen

Häufige Fragen

Ein agiles Framework, das Arbeit in feste Sprints abwickelt, mit drei Rollen (Product Owner, Scrum Master, Entwickler), drei Artefakten (Product Backlog, Sprint Backlog, Increment) und vier Events (Planning, Standup, Review, Retro). Das Ziel ist ein enger Bau- und Inspektionszyklus, nicht die Meetings selbst.
Scrum bündelt Arbeit in feste Sprints mit einer Festlegung und einem Review an jeder Grenze. Kanban läuft als kontinuierlicher Fluss mit WIP-Limits und ohne feste Iterationen. Wählt Scrum, wenn ein Team die Struktur eines Takts braucht, um Lieferdisziplin aufzubauen. Wählt Kanban, wenn Arbeit unvorhersehbar eintrifft oder das Team reif genug ist, den Fluss ohne Gerüst zu steuern.
Wenn die Zeremonien laufen, aber nichts produzieren. Ein Standup, der zum Statusmeeting wurde, ein Review ohne Demo, eine Retro, die nichts ändert. Wenn ihr am Ende eines Sprints kein lauffähiges Increment zeigen könnt, ist das Framework Theater, und ihr solltet die Substanz reparieren, nicht mehr Prozess hinzufügen.