Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Scrum ist das mit Abstand häufigste agile Framework, über 70 % aller IT-Teams nutzen es laut State-of-Agile-Report 2023. Klausur-Pflicht in 13/15 Software-Engineering-Klausuren.
Die Idee in einem Satz
Scrum: Agiles Rahmenwerk zur iterativen Produktentwicklung in kurzen, zeitlich festen Iterationen (Sprints, 1–4 Wochen), mit klar definierten Rollen, Events und Artefakten.
Das Agile Manifest (2001)
4 Grundwerte (links wichtiger als rechts, aber beide haben Wert):
- Individuen und Interaktionen über Prozesse und Werkzeuge
- Funktionierende Software über umfassende Dokumentation
- Zusammenarbeit mit dem Kunden über Vertragsverhandlung
- Reagieren auf Veränderung über das Befolgen eines Plans
12 Prinzipien dahinter: kurze Iterationen, frühe Auslieferung, Selbstorganisation, Reflexion.
Die 3 Scrum-Rollen
| Rolle | Verantwortung |
|---|---|
| Product Owner (PO) | Maximiert Produkt-Wert. Pflegt das Product Backlog, priorisiert User Stories, entscheidet WAS gebaut wird. |
| Scrum Master (SM) | Coach + Hindernis-Beseitiger. Sorgt für Scrum-Einhaltung, schützt Team vor Störungen. Kein Chef! |
| Development Team | 3–9 selbstorganisierte Personen. Entscheidet WIE gebaut wird. Cross-functional (Entwicklung + Design + Test in einem). |
Der Sprint (Herz von Scrum)
Sprint = zeitlich feste Iteration, typisch 2 Wochen.
[Sprint Planning]
↓
┌───────────────────────┐
│ Sprint (2 Wochen) │
│ ↻ Daily Standups (15') │
└───────────────────────┘
↓
[Sprint Review] ← Demo mit Stakeholdern
↓
[Sprint Retrospektive] ← Was lief gut? Was verbessern?
↓
[Nächster Sprint]
Die 5 Scrum-Events
| Event | Dauer (bei 2-Wochen-Sprint) | Ziel |
|---|---|---|
| Sprint Planning | max. 4 Std. | Was wird gemacht? Wie? |
| Daily Standup (Daily Scrum) | max. 15 Min. täglich | Gestern? Heute? Hindernisse? |
| Sprint Review | max. 2 Std. | Demo des Sprint-Ergebnisses an Stakeholder |
| Sprint Retrospektive | max. 1,5 Std. | Team-Reflexion: Was verbessern wir im nächsten Sprint? |
| Backlog Refinement | laufend (~10 % Zeit) | Stories verfeinern, schätzen, priorisieren |
Die 3 Scrum-Artefakte
1. Product Backlog
- Liste aller Anforderungen (User Stories, Bugs, Tech-Debt).
- Vom Product Owner gepflegt und priorisiert.
- Top = wichtigste / nächst-umsetzbare Items.
2. Sprint Backlog
- Auswahl aus Product Backlog für diesen Sprint.
- Team commitet sich beim Sprint Planning.
- Inhalt während Sprint stabil (kein Scope-Change!).
3. Inkrement
- Lauffähige, getestete Version am Sprint-Ende.
- Erfüllt Definition of Done (DoD), gemeinsam vereinbarte Qualitätsstandards.
Wichtige Begriffe
User Story: Kurze Anforderungsbeschreibung aus Nutzer-Sicht. Format:
"Als <Rolle> möchte ich <Funktion>, um <Nutzen>."
Story Points: Relative Aufwand-Schätzung (oft Fibonacci: 1, 2, 3, 5, 8, 13, 21). Keine Stunden!
Velocity: Story Points pro Sprint, die das Team historisch schafft. → Planungsgrundlage.
Burndown-Chart: Verbleibende Arbeit (Y-Achse) über Sprint-Zeit (X-Achse). Idealkurve = Diagonale.
Klausur-Faustregeln
1. Sprint-Dauer: 1–4 Wochen, typisch 2. Nie länger als 1 Monat.
2. 3 Rollen: PO (WAS), Scrum Master (WIE-Coach), Dev-Team (UMSETZUNG).
3. 5 Events: Sprint Planning + Daily + Review + Retro + Refinement.
4. 3 Artefakte: Product Backlog, Sprint Backlog, Inkrement.
5. Sprint-Scope ist stabil. Während des Sprints keine neuen Anforderungen reinpacken.
6. Daily Standup = 15 Min., stehend, 3 Fragen: was gestern, was heute, Hindernisse.
Häufige Stolpersteine
1. Scrum Master = Chef. FALSCH. SM ist Coach + Servant Leader. Kein Befehlsgeber, kein Personal-Verantwortlicher.
2. Sprint-Backlog ändern, weil "ist ja agil". FALSCH. Innerhalb des Sprints bleibt der Scope stabil, sonst keine Planung möglich. Änderungen kommen in nächste Sprint.
3. Story Points = Stunden. FALSCH. Story Points sind relative Komplexität (1, 2, 3, 5, 8, 13 …). Aufwand in Stunden = Anti-Pattern, weil Schätzungen schwanken.
4. Agile = chaotisch + ohne Plan. FALSCH. Agile hat klare Struktur (Sprints, Events, Rollen). Was anders ist: Plan wird kontinuierlich angepasst.
5. Daily Standup wird zum Status-Meeting an SM. FALSCH. Daily ist Team-Sync untereinander. SM ist Beobachter, nicht Berichts-Empfänger.
6. Retrospektive auslassen, weil "keine Zeit". ❌ Genau dann muss sie stattfinden. Kontinuierliche Verbesserung ist Kern von Scrum.
7. Scrum mit Kanban verwechseln. Scrum = zeitlich feste Iterationen mit Commitment. Kanban = kontinuierlicher Fluss, WIP-Limits, kein Sprint-Commitment.
Interaktiv verstehen
Scrum-Sprint visualisiert
Das Diagramm zeigt einen kompletten 2-Wochen-Sprint mit allen Events, Rollen und Artefakten. Klicke auf die Phasen, um Details zu sehen.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Wenn du in der Klausur eine "Scrum-Frage" siehst, IMMER zuerst die 3 Säulen nennen: Transparenz, Inspektion, Adaption. Das beeindruckt Korrektoren und ist der theoretische Kern hinter allen Events.
Praxis-Übung
Scrum, Praxis-Übung
6 Aufgaben zu Rollen, Events, Artefakten und typischen Klausur-Fallstricken.
Klausurfragen mit Lösungen (6)
- F1.Welche 3 Rollen kennt Scrum?
Antwort: Product Owner, Scrum Master, Development Team
Erklärung: Scrum kennt genau 3 Rollen: Product Owner (verantwortlich für Produkt-Wert + Backlog-Priorisierung), Scrum Master (Coach + Hindernis-Beseitiger, kein Chef!), Development Team (3–9 selbstorganisierte Personen, cross-functional). Klassische Manager/PM-Rollen passen NICHT in Scrum.
- F2.Wie lang dauert ein Daily Standup maximal?
Antwort: 15 Minuten
Erklärung: Daily Standup = max. 15 Minuten, stehend (deshalb 'Standup'). 3 Fragen pro Person: Was habe ich gestern getan? Was mache ich heute? Welche Hindernisse gibt es? Bei mehr als 15 Min: Detail-Diskussion danach in kleiner Runde, nicht im Daily.
- F3.Während eines laufenden Sprints darf der Product Owner neue Anforderungen in den Sprint Backlog packen, wenn sie wichtig sind.
Antwort: Falsch
Erklärung: FALSCH. Der Sprint-Backlog ist während des Sprints STABIL. Neue Anforderungen kommen in den Product Backlog und werden frühestens im NÄCHSTEN Sprint umgesetzt. Sonst gibt es keine zuverlässige Planung. Notfälle können einen Sprint-Abbruch durch PO rechtfertigen, aber kein 'mal eben dazwischenpacken'.
Typ: Wahr/Falsch
- F4.Was sind Story Points?
Antwort: Relative Aufwand-Schätzung (oft Fibonacci-Zahlen)
Erklärung: Story Points sind RELATIVE Aufwand-Schätzungen, sie vergleichen Stories miteinander statt absolute Stunden zu schätzen. Typische Skala: Fibonacci (1, 2, 3, 5, 8, 13, 21) oder T-Shirt-Größen (XS/S/M/L/XL). Vorteil: relative Schätzung ist konsistenter als Stunden-Schätzung. Die Velocity (= Story Points pro Sprint) macht Planung möglich.
- F5.Ordne die Scrum-Events ihrer Hauptaufgabe zu.
Zuordnungen:
- Sprint Planning → Festlegen, was im Sprint gemacht wird
- Daily Standup → Tägliche 15-Minuten-Team-Synchronisation
- Sprint Review → Demo des Sprint-Ergebnisses an Stakeholder
- Sprint Retrospektive → Team-Reflexion: Was verbessern wir?
Erklärung: Die 4 Haupt-Events haben klar getrennte Ziele: Planning (Was?), Daily (Sync), Review (Demo Stakeholder), Retro (Team-Verbesserung). Das 5. Event Backlog Refinement läuft laufend, nicht als festes Meeting.
Typ: Zuordnung
- F6.Der Scrum Master ist der Vorgesetzte des Development Teams und teilt Aufgaben zu.
Antwort: Falsch
Erklärung: FALSCH. Der Scrum Master ist KEIN Vorgesetzter. Er ist Coach + Hindernis-Beseitiger (Servant Leader). Das Development Team ist selbstorganisiert, es entscheidet selbst, wer welche Aufgabe übernimmt. Der SM sorgt nur dafür, dass Scrum eingehalten wird und das Team ungestört arbeiten kann.
Typ: Wahr/Falsch
Klausur-Quiz
Scrum, Klausur-Quiz
6 typische Klausurfragen. Wenn du diese sicher kannst, bist du im Klausurmodus stark.
Klausurfragen mit Lösungen (6)
- F1.Welcher der vier Werte gehört NICHT zum Agile Manifest?
Antwort: Vollständige Spezifikation über schnelle Lieferung
Erklärung: Das Agile Manifest hat 4 Grundwerte (alle 'X über Y'-Form): Individuen/Interaktionen, funktionierende Software, Kunden-Zusammenarbeit, Reagieren auf Veränderung. 'Vollständige Spezifikation über schnelle Lieferung' ist das GEGENTEIL von Agile (sequenzieller Plan zuerst). Im Agilen Manifest steht 'Working Software over Comprehensive Documentation'.
- F2.Wer pflegt das Product Backlog?
Antwort: Der Product Owner
Erklärung: Der Product Owner (PO) ist alleinig für das Product Backlog verantwortlich. Er priorisiert User Stories, fügt neue Items hinzu, kann Items entfernen. Das Team und Stakeholder können Vorschläge machen, aber die finale Entscheidung trifft der PO. Das macht ihn zu einer mächtigen Rolle.
- F3.Ein Sprint dauert typischerweise {{1}} Wochen, aber nie länger als {{2}} Monat. Die 3 Säulen von Scrum sind: {{3}}, Inspektion und Adaption.
Lösungen pro Lücke:
- {{1}}: 2 / zwei
- {{2}}: 1 / ein / einen
- {{3}}: Transparenz
Erklärung: Standard-Sprint = 2 Wochen, maximal aber 1 Monat. Die 3 Empirie-Säulen von Scrum sind Transparenz (alle sehen das gleiche), Inspektion (regelmäßig prüfen) und Adaption (anpassen). Diese 3 Säulen sind die theoretische Grundlage hinter allen Events.
Typ: Lückentext
- F4.Was ist die DEFINITION OF DONE (DoD)?
Antwort: Gemeinsame Qualitäts-Kriterien, wann ein Item als 'fertig' gilt (z.B. getestet, dokumentiert, deployed)
Erklärung: Die Definition of Done (DoD) ist eine TEAM-VEREINBARUNG, was 'fertig' bedeutet: typisch z.B. Code geschrieben, Code-Review durchlaufen, Unit-Tests grün, Integrationstests grün, Doku aktualisiert, deployed auf Staging. Ohne DoD gibt es Streit über 'ist das jetzt fertig?'. Wichtig im Klausur-Kontext: DoD ist gemeinsam vereinbart, nicht vom PO diktiert.
- F5.Bringe die Scrum-Events in die richtige zeitliche Reihenfolge innerhalb eines Sprints.
Richtige Reihenfolge:
- Sprint Planning
- Daily Standups (mehrfach täglich)
- Sprint Review
- Sprint Retrospektive
Erklärung: Reihenfolge: 1) Sprint Planning (Start des Sprints, Was machen wir?), 2) Daily Standups (täglich während des Sprints), 3) Sprint Review (Demo des Ergebnisses an Stakeholder), 4) Sprint Retrospektive (Team-Reflexion am Ende). Danach: nächster Sprint mit Planning.
Typ: Reihenfolge
- F6.Ein Team hat eine Velocity von 30 Story Points pro Sprint. Im Product Backlog liegen Stories mit insgesamt 150 Story Points. Wie viele Sprints braucht das Team voraussichtlich?
Antwort: 5 Sprints
Erklärung: 150 Story Points / 30 SP pro Sprint = 5 Sprints. Die Velocity wird genutzt, um Release-Termine zu planen. **Aber:** Velocity ist eine Schätzung, kein Versprechen, schwankt typisch ±20 %. Außerdem kommen während der Sprints neue Stories dazu. Daher: Velocity-basierte Planung gibt eine grobe Richtung, keinen exakten Termin.
