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).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
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.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
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.
Scrum: Agiles Rahmenwerk zur iterativen Produktentwicklung in kurzen, zeitlich festen Iterationen (Sprints, 1–4 Wochen), mit klar definierten Rollen, Events und Artefakten.
4 Grundwerte (links wichtiger als rechts, aber beide haben Wert):
12 Prinzipien dahinter: kurze Iterationen, frühe Auslieferung, Selbstorganisation, Reflexion.
| 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). |
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]
| 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 |
1. Product Backlog
2. Sprint Backlog
3. Inkrement
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.
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.
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.
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.
6 Aufgaben zu Rollen, Events, Artefakten und typischen Klausur-Fallstricken.
Klausurfragen mit Lösungen (6)
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.
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.
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
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.
Zuordnungen:
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
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
6 typische Klausurfragen. Wenn du diese sicher kannst, bist du im Klausurmodus stark.
Klausurfragen mit Lösungen (6)
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'.
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.
Lösungen pro Lücke:
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
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.
Richtige Reihenfolge:
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
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.