Scrum ist ein Rahmenwerk für komplexe Produktentwicklung. Ein kleines Team arbeitet in Sprints von höchstens einem Monat, liefert in jedem Sprint ein nutzbares Ergebnis und überprüft regelmäßig Produkt und Arbeitsweise.
Scrum schreibt weder User Stories, Story Points, ein Board noch bestimmte Software vor. Diese Techniken können helfen, gehören aber nicht zum verbindlichen Kern.
Die drei Verantwortlichkeiten
Das Scrum Team besteht aus einem Product Owner, einem Scrum Master und Developers. Es gibt innerhalb des Teams keine Unterteams oder Hierarchien.
Product Owner
Der Product Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren und das Product Backlog wirksam zu managen. Dazu gehören ein verständliches Produktziel, klar formulierte Einträge und eine transparente Reihenfolge. Arbeiten dürfen delegiert werden, die Verantwortung nicht.
Developers
Developers erstellen in jedem Sprint ein nutzbares Inkrement. Sie planen ihre Arbeit, sichern Qualität durch die Definition of Done und passen den Plan täglich an das Sprint-Ziel an. „Developers“ meint alle Fähigkeiten, die dafür erforderlich sind – nicht nur Programmierer.
Scrum Master
Der Scrum Master hilft Team und Organisation, Scrum zu verstehen und wirksam anzuwenden. Er ist kein Projektleiter, Protokollführer oder Aufpasser. Seine Arbeit umfasst Coaching, das Beseitigen systemischer Hindernisse und die Unterstützung guter Zusammenarbeit.
Der Sprint als Rahmen
Alle Scrum-Ereignisse finden innerhalb eines Sprints statt. Sprints haben eine feste Länge von höchstens einem Monat und folgen direkt aufeinander. Währenddessen darf der Umfang angepasst werden, solange das Sprint-Ziel nicht gefährdet wird. Qualität wird nicht abgesenkt.
Nur der Product Owner kann einen Sprint abbrechen – und zwar dann, wenn das Sprint-Ziel obsolet geworden ist.
Die fünf Ereignisse
Sprint Planning
Das gesamte Scrum Team beantwortet drei Fragen:
- Warum ist dieser Sprint wertvoll?
- Was kann in diesem Sprint fertig werden?
- Wie wird die ausgewählte Arbeit erledigt?
Ergebnis sind Sprint-Ziel und Sprint Backlog.
Daily Scrum
Das Daily Scrum ist ein 15-minütiges Ereignis für die Developers. Sie prüfen den Fortschritt zum Sprint-Ziel und passen ihren Plan an. Die bekannte Runde aus „gestern, heute, Hindernisse“ ist nur eine mögliche Technik.
Sprint Review
Team und Stakeholder überprüfen Ergebnis und veränderte Rahmenbedingungen. Das Review ist keine reine Abnahme oder Präsentation, sondern ein Arbeitsgespräch über das weitere Produkt.
Sprint Retrospective
Das Scrum Team untersucht Zusammenarbeit, Prozesse, Werkzeuge und Definition of Done. Mindestens eine konkrete Verbesserung sollte möglichst im nächsten Sprint umgesetzt werden.
Der Sprint
Der Sprint selbst ist ebenfalls ein Ereignis und umschließt Planning, Daily, Review, Retrospective und die eigentliche Produktarbeit.
Die drei Artefakte und ihre Commitments
- Product Backlog mit Produktziel: geordnete, fortlaufend verfeinerte Arbeit am Produkt.
- Sprint Backlog mit Sprint-Ziel: ausgewählte Backlog-Einträge plus der Plan der Developers.
- Inkrement mit Definition of Done: nutzbares, überprüfbares Ergebnis, das die vereinbarte Qualität erfüllt.
Refinement ist eine laufende Tätigkeit, kein vorgeschriebenes Ereignis. Definition of Ready, User Stories, Schätzungen und Burndown-Charts sind ebenfalls optionale Praktiken.
Wann Scrum passt
Scrum ist sinnvoll, wenn ein stabiles, funktionsübergreifendes Team ein komplexes Produkt entwickelt und regelmäßig Feedback von Stakeholdern erhalten kann. Weniger geeignet ist es für lose zusammengewürfelte Teilzeitgruppen, reine Ticketabwicklung oder Projekte, deren Prioritäten trotz neuer Erkenntnisse nicht verändert werden dürfen.
Typische Fehlanwendungen
- Der Product Owner ist nur Bestellannahme für Stakeholder.
- Der Scrum Master verteilt Aufgaben.
- Das Daily wird zum Statusbericht an Vorgesetzte.
- Im Review wird nur präsentiert, aber nichts entschieden.
- Unfertige Arbeit wird am Sprintende als „fast fertig“ verbucht.
- Velocity wird als Leistungskennzahl zwischen Teams verglichen.
- Jede alte Rolle bleibt bestehen und bekommt lediglich einen agilen Titel.
Scrum macht organisatorische Probleme sichtbar. Es löst sie nicht automatisch – und genau deshalb wirkt es manchmal unbequem.
Fazit
Scrum ist bewusst klein. Seine Wirkung entsteht aus Transparenz, regelmäßiger Überprüfung und Anpassung. Wer nur die Termine im Kalender übernimmt, erhält Meeting-Scrum. Wer Produktziel, Verantwortung und nutzbare Inkremente ernst nimmt, schafft einen belastbaren Lernrhythmus.
Agiles Projektmanagement mit Scrum erklärt
Quellen
