Agiles Rahmenwerk

Was ist Scrum?

Scrum ist ein Rahmenwerk für die Arbeit an Vorhaben mit unklarem Umfang, in dem ein Team in festen Zeitabschnitten, den Sprints, jeweils ein brauchbares Zwischenergebnis liefert. Es legt Verantwortlichkeiten, Termine und Artefakte fest, macht aber keine Vorgabe, wie die fachliche Arbeit erledigt wird.

Wenn sich Anforderungen noch während der Arbeit ändern, kommt Scrum als Vorschlag auf den Tisch, und ob es trägt, entscheidet weniger das Rahmenwerk als die Frage, wer im Haus Prioritäten setzen darf.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Taktung: Sprints mit festem Zeitrahmen
Verantwortlichkeiten: Product Owner, Scrum Master, Entwickler
Ereignisse: Planung, Daily, Review, Retrospektive
Verwechselt mit: Kanban

Die drei Verantwortlichkeiten

Der Product Owner entscheidet über Inhalt und Reihenfolge im Product Backlog und verantwortet, dass die Arbeit einen Nutzen bringt. Der Scrum Master sorgt dafür, dass das Rahmenwerk verstanden und angewendet wird, und räumt Hindernisse aus dem Weg. Die Developer sind alle, die am Ergebnis arbeiten, unabhängig von ihrer Fachrichtung.

Der häufigste Übersetzungsfehler besteht darin, den Product Owner als Auftraggeber und den Scrum Master als Projektleitung zu behandeln. Keiner von beiden weist dem Team Arbeit zu. Wie viel in einen Sprint passt, entscheiden die, die die Arbeit erledigen.

Termine und Artefakte

Der Sprint ist der Rahmen, innerhalb dessen die übrigen Termine liegen: die Planung am Anfang, die tägliche kurze Abstimmung, das Review mit den Beteiligten außerhalb des Teams und die Retrospektive zum Schluss. Die drei Artefakte sind Product Backlog, Sprint Backlog und das Increment, also das im Sprint entstandene Ergebnis.

Zu jedem Artefakt gehört ein Bezugspunkt: das Produktziel, das Sprintziel und die Definition of Done. Letztere ist der unterschätzte Teil, denn sie legt fest, wann etwas wirklich fertig ist, inklusive Tests, Dokumentation und Freigaben. Ohne sie wächst ein Berg halbfertiger Arbeit, der erst am Ende sichtbar wird.

Wo es in der Einführung klemmt

Typisch ist ein Sprint ohne Ziel: Das Team arbeitet die Liste ab, statt auf ein gemeinsames Ergebnis hinzuarbeiten, und jede Störung von außen wirkt gleich wichtig. Ebenso typisch sind Rollen in Doppelbesetzung, etwa eine Führungskraft, die zugleich Scrum Master sein soll.

Scrum macht Probleme sichtbar, es löst sie nicht. Wenn ein Team drei Sprints nacheinander sein Ziel verfehlt, ist das keine Niederlage, sondern ein Befund. Er zeigt, dass zu viel eingeplant wird, dass die Zuarbeit fehlt oder dass der Umfang laufend von außen verändert wird.

Nicht jede Arbeit passt in das Rahmenwerk. Wo Aufgaben unvorhersehbar hereinkommen und sofort erledigt werden müssen, etwa im Betrieb oder im Support, führt eine Begrenzung paralleler Arbeit meist weiter als ein Sprintplan.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Scrum und was oft damit gleichgesetzt wird

Scrum gegen Kanban

Kanban arbeitet ohne feste Zeitabschnitte und begrenzt stattdessen die parallel laufende Arbeit. Das passt zu stetigem Zulauf wie im Support. Scrum plant in Sprints, die auf ein gemeinsames Ziel hinarbeiten.

Scrum gegen Agilität

Agilität ist die Arbeitsweise mit kurzen Rückkopplungsschleifen. Scrum ist eine konkrete Ausprägung davon und nicht der Oberbegriff.

Scrum gegen Klassisches Vorgehen

Im klassisch geplanten Projekt steht der Umfang zu Beginn fest und wird in Phasen abgearbeitet. In Scrum steht die Zeit fest, und der Umfang wird von Sprint zu Sprint angepasst.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Ohne entscheidungsfähigen Product Owner bleibt der Rest Kulisse

Die häufigste Störung ist ein Product Owner, der die Reihenfolge nicht wirklich bestimmen darf. Dann laufen Wünsche an ihm vorbei direkt ins Team, der Sprint wird mittendrin umgeworfen, und die Planung verliert ihren Sinn. Ob Scrum trägt, entscheidet sich also nicht im Team, sondern an der Frage, wer Prioritäten setzen darf.

Der zweite Klassiker ist der Wasserfall in Sprintform, also ein Sprint für die Analyse, einer für den Entwurf, einer für die Umsetzung. Am Ende liegt wieder erst spät etwas Brauchbares vor, nur mit mehr Terminen als vorher.

Ohne eine verbindliche Definition of Done wandert unfertige Arbeit außerdem von Sprint zu Sprint weiter. Tests fehlen, die Dokumentation kommt später, die Abnahme steht aus. Der Fortschrittsbericht sieht dabei gut aus, während sich ein Rest aufstaut, den irgendwann niemand mehr anfassen will.

Scrum lernen

Wie sich das Rahmenwerk in gewachsene Strukturen einfügt, klären die Kurse zum agilen Arbeiten in Projekten .

Geht es konkret um Softwareprojekte mit Schnittstellen und Abnahmen, sind die Weiterbildungen für Vorhaben in der IT näher dran.

Kurse, die Scrum behandeln

Häufige Fragen

Wie lang ist ein Sprint?

Höchstens einen Monat, in der Praxis meist ein bis zwei Wochen. Kürzere Sprints geben schneller Rückmeldung, kosten anteilig aber mehr Zeit für die festen Termine.

Braucht jedes Team einen Scrum Master?

Das Rahmenwerk sieht die Rolle vor, weil jemand Ablauf und Hindernisse verantworten muss. In eingespielten Teams ist der Aufwand klein, in schwierigen Umfeldern füllt die Aufgabe eine ganze Stelle. Sie mit der disziplinarischen Führungskraft zu besetzen, führt regelmäßig zu Rollenkonflikten.

Passt Scrum auch außerhalb der Softwareentwicklung?

Überall dort, wo der Umfang zu Beginn unklar ist und sich Zwischenergebnisse vorzeigen lassen, etwa in der Produktentwicklung, im Marketing oder bei internen Vorhaben. Bei planbarer Routinearbeit bringt es wenig.

Persönlich für dich da