Table of Contents
Motivation
SCRUM wurde von Ken Schwaber und Jeff Sutherland entwickelt und ist ein agiles Framework für die Softwareentwicklung.
Es hilft Teams, komplexe Projekte zu managen und schnell auf Veränderungen zu reagieren.
SCRUM fördert die Zusammenarbeit, Transparenz und kontinuierliche Verbesserung.
Werte
Commitment, Focus, Openness, Respect, and Courage
Vorgehensmodell
Interativ & Inkrementell
Entwicklungszeitraum wird in Sprints unterteilt
Sprints
Dauer: 2-8 Wochen
Ziel: funktionierende Software nach jedem Sprint mit neuen feature die business value maximieren
Messen der Velocity
- Velocity = Anzahl der Story Points, die in einem Sprint abgeschlossen wurden
- hilft bei der Planung zukünftiger Sprints
Rollen
Product Owner
Stellvertreter des Kunden und der Stakeholder
Der Product Owner ist verantwortlich für:
- Produktvision und Strategie
- Product Backlog erstellen und priorisieren
- Anforderungen verstehen, übersetzen und priorisieren
- Wert für das Produkt maximieren
- Stakeholder koordinieren
Er ist die zentrale Entscheidungsinstanz für das Produkt.
Scrum Master
- coacht Teammitglieder und Organisation
- verwaltet impediment backlog
- löst impediments auf
- moderiert Meetings mit dem Ziel, die Effizienz des Teams zu verbessern
- schützt das Team vor äußeren Störungen
- fördert die Einhaltung von Scrum-Prinzipien und -Praktiken
Scrum Team
- schätzt User Stories
- setzt Stories um
- arbeitet selbstorganisiert
- cross-funktional (Entwickler, Tester, Designer etc.)
- verantwortlich für die Lieferung von Inkrementen am Ende jedes Sprints
Artefakte
Inkrement
Neue Software, die am Ende eines Sprints fertiggestellt und potenziell auslieferbar ist.
Product-Backlog
- enthält User Stories mit Definition of Done (DoD) und Akzeptanzkriterien
- priorisiert nach Business Value
- dynamisch, wird während des Projekts angepasst
Sprint-Backlog
- alle Items für den Sprint, inkl. DoD und Akzeptanzkriterien
- Burndown / Burnup Chart für Fortschrittsverfolgung
Impediment-Backlog
Für Hindernisse, die das Team daran hindern, die Sprint-Ziele zu erreichen
Beispiele:
- CI Pipeline funktioniert nicht
- Zugang zu Testdaten fehlt
- API Dokumentation unvollständig
- Fehlende Hardware für Tests
Termine
Backlog Refinement (früher Backlog Grooming)
Zeitpunkt: 1-2 mal pro Sprint, oft in der Mitte des Sprints
Dauer: 1-2 Stunden
Ziel: User Stories mit DoD, Akzeptanzkriterien und Story Points versehen, damit sie für die Sprintplanung bereit sind
Planning Poker
Wie geschätzt wird, lässt Scrum offen, aber Planning Poker ist beliebt.
Jeder Teilnehmer erhält Karten mit Zahlen (z.B. Fibonacci-Folge: 1, 2, 3, 5, 8, 13)
Die Zahlen stehen für die Komplexität der Aufgabe von 1 – sehr simpel bis 13 sehr komplex.
Der Product Owner liest eine User Story vor, und die Teilnehmer schätzen gleichzeitig, indem sie eine Karte mit ihrer Schätzung hochhalten
Nach der Schätzung diskutieren die Teilnehmer, um ein gemeinsames Verständnis zu erreichen.
Sprint Planning
Zeitpunkt: Am Anfang eines Sprints
Dauer: 4-8 Stunden (je nach Sprintlänge)
Ziel: Sprint-Ziele festlegen, User Stories auswählen, die im Sprint bearbeitet werden sollen, und Aufgaben planen
Daily Standup
Zeitpunkt: Täglich, meist morgens
Dauer: 15 Minuten
Ziel: Mini-Retro: Awareness für erledigte und aktuelle Tätigkeiten, Impediments an Scrum Master kommunizieren
Sprint Retro
Zeitpunkt: Am Sprint-Ende
Dauer: 1-2 Stunden
Ziel: Reflexion über den vergangenen Sprint, Identifikation von Verbesserungsmöglichkeiten, Maßnahmen für den nächsten Sprint planen
Scrum but – Antipatterns
Wenn Scrum nicht richtig umgesetzt wird, können verschiedene Probleme auftreten, z.B.:
- Scrum Master ist nur ein Titel, aber keine echte Rolle im Team
- Product Owner ist nicht verfügbar oder hat keine Entscheidungsbefugnis
- Team arbeitet nicht selbstorganisiert, sondern wird von außen gesteuert
- Sprints werden nicht eingehalten, sondern ständig verlängert oder verkürzt
- Meetings werden nicht effektiv genutzt, sondern sind reine Zeitverschwendung
- Keine klare Definition of Done, was zu unklaren Anforderungen und Qualitätsproblemen führt
- Keine regelmäßige Retrospektive, was zu fehlender kontinuierlicher Verbesserung führt
- Keine klare Priorisierung im Product Backlog, was zu ineffizienter Arbeit und fehlendem Fokus führt
