18.05.2020
Von Peter Hecker, Inhaber von HECKER CONSULTINGScrum nach dem Scrum Guide 2020: Verantwortlichkeiten, Sprints, Produktziel und Definition of Done – mit Chancen, Grenzen und typischen Irrtümern.
Der Scrum Guide, das offizielle Regelwerk von Scrum, ist kürzer als manche Reisekostenrichtlinie: In der aktuellen Fassung von 2020 umfasst er weniger als 13 Seiten. Trotzdem gehen die Vorstellungen davon, was Scrum eigentlich ist, weit auseinander. Für die einen ist es ein Satz fester Meetings mit Klebezetteln an der Wand, für andere ein Freibrief, auf Planung zu verzichten, für wieder andere ein Etikett, das man bestehenden Projekten aufklebt.
Wer mitreden, entscheiden oder in einem Scrum-Team arbeiten will, sollte deshalb wissen, was tatsächlich im Scrum Guide steht – und was nur drumherum entstanden ist. Viele Einführungen im Netz geben übrigens noch die Fassung von 2017 wieder, mit „Entwicklungsteam“ und drei Pflichtfragen im Daily Scrum. Beides gibt es so nicht mehr. Hier finden Sie den aktuellen Stand, verständlich erklärt und mit einer ehrlichen Einschätzung, wann Scrum hilft und wann nicht.
Scrum ist älter, als viele denken. Der Name stammt aus dem Rugby: Das „Gedränge“ steht für ein Team, das sich gemeinsam nach vorn schiebt. Ken Schwaber und Jeff Sutherland stellten das Vorgehen Mitte der 1990er-Jahre vor; seit 2010 beschreiben die beiden es im Scrum Guide, der kostenlos und in vielen Sprachen auf scrumguides.org zu finden ist.
Zum Sammelbegriff „agil“ kam Scrum 2001. Damals formulierten 17 Softwareentwickler, darunter Schwaber und Sutherland, das Manifest für agile Softwareentwicklung. Es enthält vier Wertaussagen:
Wichtig ist das kleine Wort „wichtiger“. Das Manifest schafft Pläne, Verträge und Dokumentation nicht ab, es setzt Prioritäten. Wer behauptet, agile Teams bräuchten keine Dokumentation, hat es nicht gelesen.
Der Gegenentwurf ist das klassische, phasenorientierte Vorgehen – Wasserfall oder V-Modell: erst alle Anforderungen erheben, dann planen, bauen, testen, ausliefern. Das funktioniert gut, wenn das Ziel von Anfang an feststeht, etwa beim Umzug eines Rechenzentrums. Es funktioniert schlecht, wenn sich erst unterwegs zeigt, was die Nutzer wirklich brauchen. Agile Methoden wie Scrum, Kanban oder Skalierungsansätze wie SAFe antworten darauf mit kurzen Zyklen und häufigem Feedback. Scrum ist die bekannteste davon, aber nicht die einzige.
Scrum beruht auf Empirie. Gemeint ist: Entscheidungen stützen sich auf das, was man beobachtet hat, nicht auf das, was man am Anfang vermutet hat. Dazu kommt schlankes Denken aus der Lean-Philosophie – Verschwendung vermeiden, sich auf das Wesentliche konzentrieren.
Getragen wird das von drei Säulen:
Angenommen, eine Stadtverwaltung lässt ein Online-Formular für Anwohnerparkausweise entwickeln. Nach klassischem Plan sähe die Verwaltung das Ergebnis erst nach Monaten. Mit Scrum liegt nach zwei Wochen eine erste, schlichte Version vor, die echte Sachbearbeiter ausprobieren. Stellt sich heraus, dass die Hälfte der Anträge an einem unklaren Feld scheitert, wird das im nächsten Durchlauf geändert – nicht erst nach dem Abnahmetest.
Ein Scrum-Team ist klein, in der Regel zehn Personen oder weniger. Der Scrum Guide 2020 spricht nicht mehr von „Rollen“, sondern von drei Verantwortlichkeiten (englisch accountabilities). Der Unterschied ist mehr als Wortklauberei: Es geht darum, wer wofür geradesteht, nicht um Stellenbeschreibungen.
Der Product Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren. Er oder sie formuliert das Produktziel, pflegt und ordnet das Product Backlog und entscheidet, was als Nächstes gebaut wird. Der Product Owner ist eine einzelne Person, kein Gremium. Er kann Aufgaben delegieren, bleibt aber verantwortlich. In der Praxis ist das die anspruchsvollste Aufgabe im Team, weil sie Fachwissen, Entscheidungsbefugnis und Zeit verlangt. Ein Product Owner, der jede Priorität erst mit drei Abteilungsleitern abstimmen muss, bremst das ganze Team.
Der Scrum Master ist für die Wirksamkeit des Scrum-Teams verantwortlich. Er sorgt dafür, dass Scrum verstanden und angewendet wird, räumt Hindernisse aus dem Weg und unterstützt auch die übrige Organisation, etwa Führungskräfte, die mit der neuen Arbeitsweise fremdeln. Der Scrum Guide beschreibt ihn als Führungskraft, die dem Team und der Organisation dient. Ein Projektleiter, der Aufgaben verteilt, ist er ausdrücklich nicht.
Developers sind alle, die im Sprint an einem nutzbaren Ergebnis arbeiten. Das müssen keine Programmierer sein: In einem Marketingteam können es Texterinnen und Grafiker sein, in der Produktentwicklung Ingenieure. Bis 2017 sprach der Scrum Guide vom „Entwicklungsteam“ als eigener Einheit innerhalb des Scrum-Teams. Diese Trennung ist weggefallen, weil sie oft zu einem „Wir gegen die“ zwischen Product Owner und Entwicklung führte.
Zwei Grundsätze gelten für das ganze Team. Es ist funktionsübergreifend, bringt also gemeinsam alle Fähigkeiten mit, um ein fertiges Ergebnis zu liefern. Und es ist selbstmanagend: Das Team entscheidet intern, wer was wann und wie erledigt. Unterteams für Test, Architektur oder Betrieb und interne Hierarchien kennt Scrum nicht. Spezialisten gibt es trotzdem, die Verantwortung für das Ergebnis trägt aber das Team als Ganzes.
Herzstück von Scrum ist der Sprint, ein fester Zeitraum von höchstens einem Monat; viele Teams arbeiten mit zwei Wochen. Sprints folgen lückenlos aufeinander, ein Projekt hat damit keinen großen Anfang und kein großes Ende, sondern einen Rhythmus. Der Sprint ist zugleich der Rahmen für die vier übrigen Ereignisse. Der Scrum Guide nennt deshalb fünf Ereignisse, nicht vier, wie es in älteren Einführungen oft heißt.
Zu Beginn des Sprints plant das ganze Scrum-Team die Arbeit. Es beantwortet drei Fragen: Warum ist dieser Sprint wertvoll? Was lässt sich in diesem Sprint fertigstellen? Und wie wird die Arbeit erledigt? Ergebnis ist ein Sprint-Ziel, das in einem Satz sagt, wozu der Sprint dient – zum Beispiel „Kunden können ihre Rechnungen selbst als PDF herunterladen“.
Das Daily Scrum ist ein tägliches Treffen von 15 Minuten für die Developers. Sie prüfen, ob sie dem Sprint-Ziel näherkommen, und passen ihren Plan für den nächsten Arbeitstag an. Die drei bekannten Fragen „Was habe ich gestern getan? Was tue ich heute? Was hindert mich?“ schreibt der Scrum Guide seit 2020 nicht mehr vor. Das Team wählt Ablauf und Technik selbst. Ein Statusbericht an den Chef ist das Daily ausdrücklich nicht.
Am Ende des Sprints zeigt das Team den Stakeholdern, also Auftraggebern, Nutzern und anderen Betroffenen, was entstanden ist. Gemeinsam besprechen sie, was sich verändert hat und was als Nächstes sinnvoll ist. Das Review ist eine Arbeitssitzung, keine Abnahme und keine Präsentation mit Applausordnung. Ergebnis ist oft ein angepasstes Product Backlog. Wichtig: Das Review ist kein Tor, vor dem nichts ausgeliefert werden darf. Fertige Ergebnisse dürfen auch mitten im Sprint live gehen.
Zum Schluss schaut das Scrum-Team auf sich selbst: Was lief gut bei Zusammenarbeit, Abläufen, Werkzeugen und der Definition of Done, was nicht? Die wirksamsten Verbesserungen sollen möglichst schnell umgesetzt werden, sie können auch ins Sprint Backlog des nächsten Sprints wandern. Die Retrospektive unterscheidet sich vom Review: Dort geht es um das Produkt, hier um die Arbeitsweise.
Jedes Ereignis hat eine Höchstdauer, im Scrum-Jargon Timebox genannt. Die Werte gelten für einen einmonatigen Sprint, bei kürzeren Sprints fallen die Treffen meist kürzer aus:
Artefakte sind die Arbeitsdokumente von Scrum. Neu im Scrum Guide 2020 ist, dass jedes Artefakt eine Verpflichtung (englisch commitment) enthält, an der sich der Fortschritt messen lässt.
Das Product Backlog ist eine geordnete Liste von allem, was das Produkt verbessern könnte. Es ist nie fertig, sondern wächst und verändert sich mit Markt, Technik und Rückmeldungen der Nutzer. Oben stehen die wichtigsten und am besten ausgearbeiteten Einträge, weiter unten grobe Ideen. Das laufende Verfeinern, im Jargon Refinement, gehört zur normalen Arbeit: Einträge werden zerlegt, präzisiert und geschätzt. Die Schätzung übernehmen die Developers, denn sie machen die Arbeit.
Die zugehörige Verpflichtung ist das Produktziel, eine Neuerung von 2020. Es beschreibt einen künftigen Zustand des Produkts, auf den das Team hinarbeitet, etwa „Bestandskunden erledigen 80 Prozent ihrer Anliegen ohne Anruf im Service-Center“. Das Produktziel verhindert, dass ein Team Sprint für Sprint fleißig Einträge abarbeitet, ohne dass klar ist, wohin die Reise geht.
Das Sprint Backlog enthält das Sprint-Ziel, die für den Sprint ausgewählten Einträge und den Plan, wie das Team sie umsetzt. Es gehört den Developers und wird während des Sprints laufend aktualisiert. Ändert sich unterwegs etwas, verhandeln Developers und Product Owner den Umfang neu – das Sprint-Ziel bleibt dabei stabil.
Ein Inkrement ist ein fertiges, nutzbares Stück Produkt, das auf allen vorherigen aufbaut. In einem Sprint können mehrere Inkremente entstehen. Was „fertig“ heißt, legt die Definition of Done fest: eine verbindliche Beschreibung der Qualitätsanforderungen, etwa „getestet, dokumentiert, von der Fachabteilung geprüft, barrierefrei“. Arbeiten mehrere Teams am selben Produkt, gilt für alle dieselbe Definition of Done. Was sie nicht erfüllt, gilt nicht als Inkrement und wird im Review nicht vorgeführt. Gerade diese Regel unterschätzen viele Teams; sie ist der wichtigste Schutz gegen Scheinfortschritt.
Der Scrum Guide nennt fünf Werte: Commitment (Selbstverpflichtung), Fokus, Offenheit, Respekt und Mut. Auf den ersten Blick wirkt das wie Wandschmuck aus dem Leitbild-Workshop. Tatsächlich hängt der Erfolg von Scrum stark daran. Transparenz entsteht nur, wenn Teammitglieder offen sagen dürfen, dass etwas nicht klappt. Ein Sprint-Ziel funktioniert nur, wenn das Team sich darauf konzentriert und nicht jeden Tag neue Sonderwünsche einschiebt. Und Selbstmanagement setzt voraus, dass Menschen sich gegenseitig als fähige, eigenständige Fachleute respektieren.
Für Führungskräfte heißt das: Wer Fehler sanktioniert oder das Daily als Kontrollinstrument nutzt, bekommt geschönte Berichte statt Transparenz. Die Regeln von Scrum lassen sich in einem Nachmittag lernen, die Haltung dahinter braucht deutlich länger.
Wer Scrum vor einigen Jahren gelernt hat, sollte die wichtigsten Neuerungen kennen:
Eine ausführliche Gegenüberstellung finden Sie im Beitrag Der Scrum Guide 2020 ist da. Maßgeblich ist der Scrum Guide 2020 bis heute. Ergänzende Veröffentlichungen aus dem Umfeld der Scrum-Gründer ersetzen ihn nicht.
Vieles, was im Alltag als „Scrum“ gilt, steht gar nicht im Scrum Guide. Einige Irrtümer begegnen einem besonders häufig:
Scrum spielt seine Stärken aus, wenn das Ziel klar ist, der Weg dorthin aber nicht: bei neuen digitalen Produkten, Kundenportalen, internen Anwendungen, aber auch bei Kampagnen oder der Entwicklung neuer Dienstleistungen. Kurze Zyklen machen Fehlentwicklungen früh sichtbar, und Auftraggeber sehen regelmäßig echte Ergebnisse statt Statusfolien.
Weniger gut passt Scrum, wenn die Arbeit vor allem aus unplanbaren Einzelaufträgen besteht, etwa im IT-Support oder im laufenden Betrieb. Dort sind feste Sprints eher hinderlich; ein fließendes Vorgehen wie Kanban ist oft die bessere Wahl. Auch bei Vorhaben mit vollständig vorgegebenem Ergebnis und starren Abnahmen, wie manchen öffentlichen Ausschreibungen oder Bauprojekten, stößt Scrum an Grenzen – zumindest in Reinform.
Die größten Hürden liegen aber selten im Rahmenwerk, sondern in der Organisation:
Arbeiten viele Teams an einem Produkt, braucht es zusätzliche Abstimmung. Dafür gibt es Skalierungsansätze wie Nexus, SAFe oder Large-Scale Scrum (LeSS), die auf Scrum aufbauen, sich aber in Philosophie und Aufwand deutlich unterscheiden.
Der Scrum Guide 2020 erwähnt künstliche Intelligenz nicht, und das ist kein Mangel: An den Verantwortlichkeiten ändert KI nichts. Ein Sprachmodell kann einem Product Owner helfen, Backlog-Einträge vorzuformulieren, Rückmeldungen aus dem Kundenservice zu bündeln oder Akzeptanzkriterien zu entwerfen. Developers nutzen KI-Assistenten beim Programmieren, Testen und Dokumentieren. Entscheiden, was wertvoll ist, muss aber weiterhin ein Mensch, und verantworten ebenfalls.
Eine Folge wird oft übersehen: Wenn KI-Werkzeuge mehr Code und Text in kürzerer Zeit erzeugen, wird die Definition of Done wichtiger, nicht unwichtiger. Wer dort festhält, dass KI-erzeugte Ergebnisse geprüft, getestet und auf Datenschutz und Urheberrecht kontrolliert werden, schützt das Team vor schnellem, aber fehlerhaftem Output. Und die Retrospektive ist der richtige Ort, um nüchtern zu besprechen, wo die Werkzeuge wirklich helfen und wo sie nur neue Nacharbeit erzeugen.
Scrum ist kein Allheilmittel, aber für Produkte und Projekte mit unsicheren Anforderungen eines der besten verfügbaren Rahmenwerke. Sein größter Vorzug ist die Ehrlichkeit: Alle paar Wochen liegt ein echtes Ergebnis auf dem Tisch, und Probleme lassen sich nicht lange hinter Fortschrittsbalken verstecken.
Überschätzt wird dagegen, wie schnell eine Einführung wirkt. Neue Meetings und ein Board sind in einer Woche eingerichtet. Dass ein Product Owner wirklich entscheiden darf und Führungskräfte Teams wirklich selbst managen lassen, braucht Monate und oft Änderungen an Budgetierung und Zielvereinbarungen. Meine Empfehlung: Beginnen Sie mit einem Pilotteam an einem Vorhaben, bei dem sich Lernen lohnt, halten Sie sich zunächst eng an den Scrum Guide und passen Sie erst an, wenn Sie verstanden haben, warum eine Regel existiert. Wer Scrum vom ersten Tag an „für unsere Verhältnisse anpasst“, landet häufig bei einer Variante, die die Nachteile beider Welten verbindet.
Nein. Scrum stammt aus der Software, wird aber auch in Marketing, Produktentwicklung, Personalwesen oder Verwaltung eingesetzt. Die Fassung von 2020 wurde bewusst allgemeiner formuliert, deshalb heißt es „Developers“ statt „Entwicklungsteam“. Entscheidend ist, ob sich die Arbeit in kurze Zyklen mit vorzeigbaren Zwischenergebnissen gliedern lässt.
Höchstens einen Monat. Viele Teams wählen zwei Wochen, weil das genug Zeit für ein sinnvolles Ergebnis lässt und trotzdem häufiges Feedback ermöglicht. Wichtiger als die genaue Länge ist, dass sie konstant bleibt, damit ein verlässlicher Rhythmus entsteht.
Für die Anwendung nicht, der Scrum Guide ist frei verfügbar. Zertifikate wie Professional Scrum Master oder Professional Scrum Product Owner von Scrum.org oder der Certified ScrumMaster der Scrum Alliance belegen Grundwissen und werden in Stellenanzeigen häufig verlangt. Sie ersetzen aber keine Praxiserfahrung. Wer die Product-Owner-Verantwortung übernehmen will, findet im Seminar Professional Scrum Product Owner (PSPO) eine gezielte Vorbereitung.
Ja, das ist in vielen Unternehmen Alltag. Ein Gesamtprojekt mit festen Meilensteinen kann einzelne Teilvorhaben in Scrum umsetzen lassen. Wichtig ist eine klare Schnittstelle: Der Rahmen gibt Ziele und Budget vor, im Scrum-Team entscheiden Product Owner und Developers, wie der Weg dorthin aussieht.
Mehr zu Rahmenwerk, Rollen und Praxis finden Sie auf der Themenseite Scrum. Wer Scrum im eigenen Team einführen oder auffrischen möchte, lernt im Seminar Agiles Projektmanagement mit Scrum Ereignisse, Artefakte und Verantwortlichkeiten an praktischen Übungen kennen.
Wir erweitern ständig unser Beratungsportfolio. Über 600 Beratungsleistungen haben wir für Sie im Programm. Selbstverständlich lassen sich die einzelnen Themen kombinieren. So erhalten Sie genau die Beratung, die Sie wünschen und brauchen.
Mehr IT-, Online-, Digital-Beratungsleistungen anzeigen >>Als Developer in einem Scrum Team planen Sie den Sprint mit, halten die Definition of Done mit Tests, Code-Review und CI ein, machen technische Schulden sichtbar und bringen die Entwicklersicht in Refinement, Review und Retrospektive ein.
Für die Prüfung Professional Scrum Product Owner™ I (PSPO™ I) ordnen Sie, was die Rolle ausmacht: Wertmaximierung, Produktziel, Evidence-Based Management, Product-Backlog-Management, Stakeholder und Releases – mit Übungsfragen und Lernplan.
Als Product Owner sprechen Sie danach mit Entwickler:innen, UX und Management auf Augenhöhe – vom Request im Browser über APIs und Datenbanken bis zum Release im App Store.
Ihr Team plant Sprints und Releases in Jira Software, steuert den Arbeitsfluss auf Scrum- und Kanban-Boards, filtert mit JQL genau die Vorgänge, die zählen, und macht den Fortschritt auf Dashboards für alle sichtbar.
Sie schätzen Softwarevorhaben mit passenden Methoden – vom Expertenurteil über Planning Poker bis zur Monte-Carlo-Prognose – und kommunizieren Ergebnisse als ehrliche Spannbreite statt als Wunschtermin.
Sie erkennen, warum Standups, Retrospektiven, Reviews und Schätzungen in Ihrem agilen Team an Wirkung verloren haben, und beheben die Ursachen – im Team, mit dem Product Owner und gegenüber Management und Organisation.
Mit Large-Scale Scrum (LeSS) organisieren Sie mehrere Teams an einem Produkt mit einem Product Owner, einem Product Backlog und einem gemeinsamen Inkrement – und erkennen, wo Feature-Teams, LeSS Huge oder weniger Struktur weiterhelfen.
Sie führen ein Projekt nach dem aktuellen Scrum Guide mit klaren Verantwortlichkeiten, Produktziel, Sprint-Zielen und gemeinsamer Definition of Done und liefern in jedem Sprint ein Ergebnis, das Auftraggeber prüfen können – in IT, Marketing oder Verwaltung.
Aktuelle und interessante Themen und Beiträge für Sie zusammengetragen und aufbereitet.
Der Scrum-Guide ist im Laufe der Jahre immer präskriptiver geworden und bietet Struktur und Definition, wobei nun die neueste Ausgabe 2020 darauf abzielt, den Scrum-Guide zu einem minimalen, aber ausreichenden Rahmen mit nur 13 Seiten (wirklich leichtgewichtig) zu machen.
