Scrum: Rollen, Artefakte und was im Alltag davon ankommt
Scrum: Rollen, Artefakte und was im Alltag davon ankommt
Artikel-Übersicht
Scrum ist gut dokumentiert und wird trotzdem selten so beschrieben, wie es sich für Entwickler anfühlt. Dieser Artikel geht die 3-5-3-Regel vollständig durch — drei Rollen, fünf Ereignisse, drei Artefakte — und legt besonderes Gewicht auf die Verpflichtungen zu den Artefakten, die in fast jeder Darstellung fehlen und der eigentliche Grund sind, warum die Artefakte überhaupt wirken. Danach die drei Säulen und fünf Werte, jeweils mit einem Satz dazu, was ihr Fehlen im Alltag anrichtet, die saubere Abgrenzung zwischen Agile, Scrum und Kanban und der Umgang mit technischen Schulden. Zum Schluss der Abschnitt, der in Schulungsunterlagen nicht vorkommt: welche Ereignisse Wirkung zeigen und welche zu Ritualen werden.
Was Scrum ist
Scrum ist ein Rahmenwerk für die Zusammenarbeit an komplexen Vorhaben — mit festen Rollen, festen Ereignissen und der Regel, in kurzen Abständen etwas Fertiges zu liefern.
Ein Hinweis zur Bezeichnung, beiläufig, weil er die Sache klarer macht: Scrum wird meist „Methode" genannt und ist genau genommen keine. Eine Methode gibt ein Vorgehen vor; Scrum gibt einen Rahmen vor und lässt das Vorgehen offen. Es sagt nicht, wie man schätzt, wie man testet oder wie man entwirft — es sagt, wer wann worüber spricht und was am Ende vorliegen muss.
Das ist keine Wortklauberei, sondern der häufigste Grund für Enttäuschung: Scrum löst keine technischen Probleme. Ein Team, das nicht weiß, wie es gute Software baut, baut sie auch in Sprints nicht.
Die 3-5-3-Regel
Drei Rollen, fünf Ereignisse, drei Artefakte. Die Merkregel fasst den gesamten Rahmen zusammen:
| 3 Rollen | Product Owner, Scrum Master, Entwickler |
| 5 Ereignisse | Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective |
| 3 Artefakte | Product Backlog, Sprint Backlog, Inkrement |
Der Sprint zählt dabei als Ereignis, das die anderen vier umschließt — er ist der Behälter, nicht ein Termin darin.
Die drei Rollen
Product Owner. Verantwortet den Wert des Produkts. Er entscheidet, was gebaut wird und in welcher Reihenfolge, und er pflegt das Product Backlog. Häufigste Fehlbesetzung: eine Person ohne Entscheidungsbefugnis, die jede Priorisierung erst anderswo abstimmen muss — dann verschiebt sich die Entscheidung aus dem Team heraus, und der Rahmen läuft leer.
Scrum Master. Verantwortet die Wirksamkeit des Rahmenwerks. Er ist kein Projektleiter und kein Vorgesetzter; seine Arbeit besteht darin, Hindernisse zu beseitigen und dafür zu sorgen, dass die Ereignisse ihren Zweck erfüllen. Häufigste Fehlbesetzung: der Terminverwalter, der Besprechungen einlädt und Kennzahlen pflegt.
Entwickler. Alle, die am Inkrement arbeiten — Entwicklung, Test, Entwurf, was immer nötig ist. Sie entscheiden, wie gebaut wird, und wie viel sie sich für einen Sprint vornehmen.
Die wichtigste Grenze im ganzen Rahmenwerk verläuft zwischen der ersten und der dritten Rolle: Der Product Owner entscheidet über das Was, das Team über das Wie. Wenn diese Grenze verschwimmt — wenn also technische Lösungen von außen vorgegeben oder fachliche Prioritäten intern umsortiert werden —, entsteht der häufigste Konflikt in Scrum-Teams.
Die drei Artefakte — und ihre Verpflichtungen
Hier steht der Teil, der fast überall fehlt. Jedes Artefakt hat seit 2020 eine ausdrückliche Verpflichtung, und die ist der Grund, warum das Artefakt wirkt:
| Artefakt | Was es ist | Verpflichtung |
|---|---|---|
| Product Backlog | geordnete Liste alles Nötigen | Produktziel |
| Sprint Backlog | Auswahl für diesen Sprint plus Plan | Sprintziel |
| Inkrement | das fertige Ergebnis | Definition of Done |
Ohne die rechte Spalte sind die Artefakte Listen. Mit ihr bekommen sie eine Richtung:
Das Produktziel gibt dem Backlog einen Zweck. Ohne es ist die Liste eine Sammlung von Wünschen, und die Priorisierung wird zur Geschmacksfrage.
Das Sprintziel ist der am häufigsten weggelassene Teil des ganzen Rahmenwerks — und der folgenreichste. Ein Sprint ohne Ziel ist eine Zeitscheibe, in der abgearbeitet wird. Mit Ziel kann das Team unterwegs entscheiden, was wichtig ist und was entfallen darf, wenn es eng wird. Wer kein Sprintziel formuliert, nimmt dem Team genau diese Entscheidungsfähigkeit.
Die Definition of Done legt fest, wann etwas fertig ist. Sie ist der Ort, an dem Qualitätsanforderungen verbindlich werden — Tests geschrieben, Review durchgeführt, Dokumentation aktualisiert. Ohne sie bedeutet „fertig" bei jedem etwas anderes.
Die fünf Ereignisse
| Ereignis | Zweck | Zeitrahmen | Häufigster Missbrauch |
|---|---|---|---|
| Sprint | fester Rhythmus, umschließt alles andere | ein Monat oder kürzer | Ziel fehlt, wird zur Zeitscheibe |
| Sprint Planning | Was und Wie für diesen Sprint | bis 8 Stunden bei Monatssprint | Schätzrunde ohne Zielbildung |
| Daily Scrum | Abstimmung der Entwickler untereinander | 15 Minuten | Statusbericht an den Scrum Master |
| Sprint Review | Inkrement zeigen, Rückmeldung einholen | bis 4 Stunden | Abnahmetermin mit Vorführcharakter |
| Sprint Retrospective | Zusammenarbeit verbessern | bis 3 Stunden | Klagerunde ohne Maßnahme |
Zwei Missbräuche verdienen eine Erläuterung, weil sie so verbreitet sind:
Das Daily als Statusbericht. Es ist ein Termin der Entwickler für die Entwickler — sie stimmen ab, wie sie in den nächsten 24 Stunden auf das Sprintziel zuarbeiten. Sobald reihum an eine Person berichtet wird, ist es ein Statustermin, und der Nutzen für die Beteiligten verschwindet.
Das Review als Abnahme. Es soll Rückmeldung erzeugen, nicht Zustimmung einholen. Ein Review, in dem eine vorbereitete Vorführung gezeigt und danach abgehakt wird, liefert keine Erkenntnis. Ein Review, in dem jemand aus dem Fachbereich das Ergebnis selbst bedient, liefert regelmäßig welche.
Die drei Säulen und die fünf Werte
Die drei Säulen sind Transparenz, Überprüfung und Anpassung — die empirische Grundlage. Man kann nur überprüfen, was sichtbar ist, und nur anpassen, was man überprüft hat.
Was ihr Fehlen anrichtet: Ohne Transparenz beruhen Entscheidungen auf Vermutungen. Ohne Überprüfung merkt niemand, dass man in die falsche Richtung läuft. Ohne Anpassung war die Überprüfung umsonst.
Die fünf Werte sind Selbstverpflichtung, Fokus, Offenheit, Respekt und Mut. Sie klingen nach Poster im Flur und haben trotzdem eine konkrete Entsprechung:
- Selbstverpflichtung fehlt, wenn das Sprintziel niemanden interessiert.
- Fokus fehlt, wenn alle an fünf Dingen gleichzeitig arbeiten.
- Offenheit fehlt, wenn Probleme erst am Sprintende sichtbar werden.
- Respekt fehlt, wenn Schätzungen von außen korrigiert werden.
- Mut fehlt, wenn niemand sagt, dass das Ziel nicht erreichbar ist.
Agile, Scrum, Kanban
Drei Begriffe auf drei Ebenen:
| Was es ist | Kern | Woher | |
|---|---|---|---|
| Agile | eine Haltung | Werte und Prinzipien des Manifests von 2001 | Softwareentwicklung |
| Scrum | ein Rahmenwerk | feste Rollen, Ereignisse, Artefakte | Softwareentwicklung |
| Kanban | eine Methode zur Flusssteuerung | Arbeit sichtbar machen, laufende Arbeit begrenzen | Fertigung, später Software |
Agile ist keine Vorgehensweise, sondern eine Haltung — man kann nicht „Agile machen". Scrum ist eine mögliche Umsetzung davon. Kanban ist keine Alternative zu Scrum im engeren Sinn, sondern eine Methode, die man auch innerhalb von Scrum anwenden kann.
Der zentrale Unterschied in der Praxis: Scrum arbeitet in festen Zeitabschnitten, Kanban in einem kontinuierlichen Fluss mit Begrenzung der gleichzeitig laufenden Arbeit. Für Teams mit planbarem Vorlauf passt Scrum gut; für Teams, die überwiegend auf eingehende Anforderungen reagieren — Support, Betrieb, Wartung —, passt Kanban besser, weil ein Sprintziel dort ständig durchbrochen würde.
Mischformen sind der Normalfall und kein Makel.
Technische Schulden im Sprint
Wo Qualitätsarbeit unterkommt, ist eine strukturelle Frage. Drei Wege:
In der Definition of Done. Der wirksamste Ort, weil nicht verhandelbar: Was nicht getestet und nicht überprüft ist, ist nicht fertig. Damit ist ein Teil der Qualitätsarbeit gar nicht erst diskutierbar.
Als eigene Einträge im Backlog. Sichtbar und priorisierbar — und damit auch verschiebbar. Für strukturelle Vorhaben nötig, für den Alltag zu schwerfällig.
Als Pfadfinderregel. Jede Änderung hinterlässt den berührten Bereich etwas besser. Braucht keine Genehmigung und trifft automatisch die meistgeänderten Stellen.
Was in Scrum strukturell schwierig ist: „Wir machen das später" hat keinen Platz. Es gibt kein „später" außerhalb der Sprints — entweder es steht im Backlog, oder es passiert nicht. Das ist eine Stärke, wenn man es nutzt, und der Grund für schleichenden Verfall, wenn nicht. Wie man den Umfang der Schulden sichtbar macht, steht in Technische Schulden und Refactoring.
Verwandt ist die Frage, wo nichtfunktionale Anforderungen unterkommen — sie passen schlecht in User Stories und brauchen einen eigenen Ort, meist die Definition of Done. Mehr dazu in Requirements Engineering: Anforderungen, die tragen.
Was im Alltag wirklich ankommt
Der ehrliche Abschnitt, den Schulungsunterlagen nicht enthalten.
Was zuverlässig Wirkung zeigt:
- Die Retrospektive, wenn sie zu Maßnahmen führt. Sie ist das einzige Ereignis, das den Rahmen selbst verändern kann — und das erste, das gestrichen wird, wenn es eng wird. Ein Team, das ein Vierteljahr ohne Retrospektive arbeitet, verliert seine Selbstkorrektur.
- Ein echtes Sprintziel. Es verändert Gespräche unmittelbar: Statt „schaffen wir alles?" wird gefragt „was brauchen wir für das Ziel?".
- Die Definition of Done, weil sie Qualitätsdiskussionen aus dem Einzelfall herausnimmt.
Was zum Ritual wird:
- Das Daily, sobald es zum Statusbericht wird. Der Test: Sprechen die Leute miteinander oder zu einer Person?
- Das Review, wenn niemand aus dem Fachbereich kommt. Dann ist es eine interne Vorführung.
- Schätzungen, wenn sie als Zusagen behandelt werden. Dann wird gepolstert, und die Zahlen verlieren jede Aussagekraft.
Was ein Team ohne Scrum Master verliert: meist nicht die Termine — die stehen im Kalender —, sondern die Beseitigung von Hindernissen außerhalb des Teams. Genau die kostet die meiste Zeit und macht am wenigsten Freude, weshalb sie liegen bleibt, wenn niemand zuständig ist.
Der häufigste Abweichungspunkt ist die Sprintlänge in Verbindung mit dem fehlenden Ziel: Zwei-Wochen-Sprints ohne Ziel sind Zeitscheiben, in denen abgearbeitet wird. Das funktioniert eine Weile und ist dann kein Scrum mehr, sondern ein Ticketsystem mit Terminen.
Häufige Fragen
Was ist Scrum kurz erklärt? Ein Rahmenwerk für die Zusammenarbeit an komplexen Vorhaben, mit drei Rollen, fünf Ereignissen und drei Artefakten — und der Regel, in kurzen Abständen etwas Fertiges zu liefern.
Was besagt die 3-5-3-Regel im Scrum? Drei Rollen (Product Owner, Scrum Master, Entwickler), fünf Ereignisse (Sprint, Planning, Daily, Review, Retrospective) und drei Artefakte (Product Backlog, Sprint Backlog, Inkrement).
Was sind die drei Säulen von Scrum? Transparenz, Überprüfung und Anpassung — die empirische Grundlage des Rahmenwerks.
Was sind die fünf Scrum-Werte? Selbstverpflichtung, Fokus, Offenheit, Respekt und Mut.
Was ist der Unterschied zwischen Agile und Scrum? Agile ist eine Haltung mit Werten und Prinzipien, Scrum ein konkretes Rahmenwerk, das diese Haltung umsetzt.
Was ist Kanban und wie verhält es sich zu Scrum? Kanban ist eine Methode zur Flusssteuerung: Arbeit sichtbar machen und die gleichzeitig laufende Arbeit begrenzen. Es lässt sich auch innerhalb von Scrum anwenden; für reaktive Teams ist es oft der bessere Rahmen.
Zusammenfassung und praktische Tipps
Scrum ist ein Rahmen, kein Rezept — und die Teile, die im Alltag wirken, sind nicht die, über die am meisten gesprochen wird. Die wichtigsten Punkte:
- Drei Rollen, fünf Ereignisse, drei Artefakte — mehr gibt der Rahmen nicht vor.
- Jedes Artefakt hat eine Verpflichtung. Produktziel, Sprintziel, Definition of Done — ohne sie sind es Listen.
- Das Sprintziel ist der am häufigsten weggelassene und folgenreichste Teil.
- Der Product Owner entscheidet das Was, das Team das Wie. An dieser Grenze entstehen die meisten Konflikte.
- Das Daily ist ein Termin der Entwickler untereinander, kein Statusbericht.
- Die Definition of Done ist der wirksamste Ort für Qualitätsanforderungen, weil sie nicht verhandelbar ist.
- Die Retrospektive ist die Selbstkorrektur des Teams — und das Erste, was gestrichen wird.
Mein Rat für den Einstieg: Formuliert für den nächsten Sprint ein echtes Ziel — einen Satz, der beschreibt, was am Ende möglich sein soll, und der nicht bloß die ausgewählten Einträge aufzählt. Wenn euch dabei auffällt, dass sich aus der Auswahl kein sinnvoller Satz bilden lässt, habt ihr die wichtigste Erkenntnis dieses Sprints schon vor seinem Beginn.
Ressourcen
- Der Scrum Guide (deutsch) – die verbindliche Fassung, kostenlos, rund 13 Seiten
- Agiles Manifest – die vier Werte und zwölf Prinzipien auf Deutsch
- Kanban Guide – die kompakte Beschreibung der Flussmethode