Scrum ist ein agiles Rahmenwerk zur Produktentwicklung, das durch empirische Prozesskontrolle, Transparenz und kontinuierliche Anpassung geprägt ist. Es fördert die selbstorganisierte Zusammenarbeit im Team, den Austausch durch tägliche Abstimmungen und die regelmäßige Überprüfung von Fortschritten. Die Rollen innerhalb eines Scrum-Teams umfassen den Product Owner, Scrum Master und das Entwicklungsteam, während Events wie Sprints, Sprintplanungen und Retrospektiven den Arbeitsprozess strukturieren.

1. Scrum
ÜBERBLICK

2. Definition
Scrum (engl. das Gedränge) ist
ein Rahmenwerk mit
u Rollen,
u Events,
u Artefakten,
u Werten und
u Grundüberzeugungen,
das beim Entwickeln von
Produkten im Rahmen agiler
Softwareentwicklung hilfreich
ist.

3. Empirische Prozesssteuerung
u Wissen wird aus Erfahrung gewonnen und
u Entscheidungen auf Basis des Bekannten getroffen
Transparenz
•Das Wesentliche
muss für jeden
ersichtlich sein
•Gemeinsame
Prozesssprache
•Gemeinsames
Verständnis von
Done
Überprüfung
• Laufende
Überprüfung des
Fortschritts und
Artefakte in Bezug
auf Erreichung der
Sprint-Ziele
Anpassung
• Aus Fehlern schnell
lernen und Prozess
und Produkt schnell
anpassen, um
weitere
Abweichungen zu
minimieren

4. Kernaussagen von Scrum
u ... dient dazu komplexen Projekte zu managen und im Gegensatz zum Wasserfall nicht das
Projekt von Anfang bis Ende zu planen. komplex = probieren – erkennen – reagieren
u ... ist Iterativ, d.h. es ist ein schrittweises Vorgehen mit in sich wiederholenden Schleifen.
u ... ist Inkrementell, d.h. die Lieferung erfolgt in funktionstüchtigen Teilen.
u ... ist transparent durch ein ständiges Inspect & Adapt (Anschauen und Anpassen).
u ... hilft dabei Fehler frühzeitig zu erkennen, indem Fehler gemacht werden.
u ... ist ein Kontinuierliche Verbesserungsprozess (KVP = DEMING-Cycle) durch die Integration
entsprechender Praktiken wie Retrospektiven, Daily Scrum und das führen sogenannter
Impediment-Listen - wobei der KVP sowohl den Prozess als auch das Produkt anbelangt.
u ... stellt das selbstorganisierte Arbeiten (und Lernen) in das Zentrum.
u ... die Kommunikation läuft insbesondere face to face durch die entsprechenden Events ab.

5. Ziele
u Den Kunden durch direkte Einbindung zufriedenstellen
u Änderungen willkommen heißen
u Häufige Auslieferung
u Cross-funktionale Zusammenarbeit
u Unterstützung leisten und Vertrauen schenken
u Direkte persönliche Kommunikation
u Funktionierende Software (hochwertige Produkte)
u Streben nach (technischer) Exzellenz

6. Rollen innerhalb des Scrum Teams

7. Rolle: Product Owner
u Ist genau 1 Person, beeinflussbar durch Komitees, Management, Kunde, Vertrieb
u Erfassung der Bedürfnisse der Kunden und Stakeholder
u Bestimmung des Auslieferungsdatum und Inhalt
u Verantwortung für das Produkt und Erfolg (u.a. ROI)
u Definition und Priorisierung von Feature abhängig vom Geschäftswert
u Anpassung der Features und Prioritäten für jeden Sprint
u Abnahme bzw. Abweisung der Feature vor Sprintende
u Darf das Team bis zu 10 % seiner Zeit in Anspruch nehmen
• Für konzeptionelle Arbeiten und für Schätzungen (Grooming)
• Zusätzlich zur Sprint Planung und Sprint Review
u Muss mind. 80 % seiner Zeit für das Team zur Verfügung stellen

8. Rolle: Scrum Master
u Verantwortlich für die Einhaltung von Scrum Werten und Techniken
u Beseitigen von Hindernissen (selbst oder delegierend)
u Unterstützt die enge Zusammenarbeit zwischen allen Rollen
u Schützt das Team vor äußeren Störungen
u Versucht Lernprozess und Selbstorganisation des Teams anzustoßen
u Moderiert die Meetings oder hilft bei deren Vorbereitung
• Darf inhaltlich nicht mitarbeiten
• Ist nicht Teil des Umsetzungsteam
• Hat keine Weisungsbefugnis gegenüber dem Team

9. Rolle: Development Team
u Teamgröße: 5-9 Personen (Vollzeit, kein Titel)
u Cross-funktional aufgestellt
(Tester, Entwickler, Business Analyst, UI/UX)
u Das Team steuert sich selbst
• Teammitglieder übernehmen Aufgaben, bekommen sie nicht
zugewiesen (Pull-Prinzip)
• Das Team darf alles tun, was für die Zielerreichung notwendig
ist
u Teamzusammenstellung sollte sich nur in Ausnahmen und nur zu
einem Sprintwechsel ändern

10. Events

11. Event: SPRINT
Ein Sprint hat immer die selbe Dauer (max. 4 Wochen) und muss als Ergebnis ein
fertiges Produkt-Inkrement liefern („Done“)
Während eines Sprints
- dürfen keine Änderungen vorgenommen werden, die das Sprint-Ziel gefährden
- darf der Qualitätsanspruch nicht geschmälert werden
- darf der Anforderungsumfang neu verhandelt werden, wenn sich neue Erkenntnisse
ergeben.
Jeder Sprint ist ein kleines Projekt mit:
- definiertem Leistungsumfang
- einem Entwurf
- einem flexiblem Plan

12. Event: SPRINT Planung
u Sprintplanung I: AnalyseDas Entwicklungsteam soll genau verstehen WAS der (End-) Benutzer funktional
möchte. Am Ende des Meetings ist das Team in der Lage selbst zu entscheiden, was
und wie viel es in diesem Sprint liefern will.
Nacheinander werden die Backlog Items wiefolgt behandelt:
1. Die Anforderungen der Story werden vom Entwicklungsteam diskutiert, so dass jedem
diese klar ist.
2. Die Akzeptanzkriterien werden vom Entwicklungsteamerstellt bzw. verfeinert.
3. Die Constraints (technische Auflagen und Bedingungen) werden festgehalten
4. Der Level of Done für diese Story wird festgelegt.
- Selected Product Backlog ist abhängig der Teamkapazität definiert (Commitment)
- Anforderungen für jedes Backlog Item ist jedem klar
- Akzeptanzkriterien sind festgelegt

13. Event: SPRINT Planung
u Sprintplanung II: DesignDas Team entwickelt eine Lösung für die Backlog Items, die in diesem Sprint
tatsächlich implementiert werden. Am Ende dieses Meetings ist dem Team klar, WIE
es die geplanten Funktionalitäten umsetzen will.
Nacheinander werden die Backlog Items wiefolgt behandelt:
1. Es findet eine ergebnisorientierte Diskussion darüber statt, wiedas Backlog Item umgesetzt
werden könnte.
2. Das Sprint Backlog ist anschließend gemeinschaftlich erstellt, indem Task identifiziert
werden.
- Design und ggf. ergänzende (Architektur-)Diagramme und technische Beschreibungen
- Abgeleitete Tasks
- Das Team hat klareVorstellung entwickelt, wie dieBacklog Items konkret umgesetzt werden.

14. Event: Daily Scrum
Das Team plant und koordiniert seine Aktivitäten für diesen Tag, es identifiziert und
diskutiert auftretende Hindernisse. Das Taskboard hilft sich auf die aktuellen
Aufgaben zu fokussieren.
1. Das Scrum Team trifft sich beim Taskboard.
2. Ein Teammitglied beginnt den anderen zu erklären, was es seit dem letzten Daily Scrum
umgesetzt hat.
3. Das Teammitglied bewegt den dazu passenden Task amBoard in die korrekteSpalte.
4. Bei Bedarf wählt er eine geeignete neue Aufgabe und hängt sie in die„In Progress“
Spalte.
- Ein Überblick darüber, WER WAS tut.
- Einträge im Impediment Backlog
- Inhalt für das Team Backlog

15. Event: Daily Scrum - Eigenschaften
- Stand-up Meeting
- Täglich am selben Ort zur selben Zeit
- Dauer: max. 15 min
Ziel:
- Abstimmung im Team, keine Diskussion /
Problemlösung
. Alle sind eingeladen
. Aber nur das Scrum Team darf reden
Jeder beantwortet die drei Fragen:
- Was hast du seit dem letzten Daily geschafft?
- Was wirst du bis zum nächsten Daily
erledigten?
- Was behindert dich beim Vorwärts kommen?
Hindernisliste wird aufgefüllt

16. Event: SPRINT Review
Das Scrum Team zeigt dem (End-) Benutzer seine Arbeit.
1. Nach der Begrüßung der Teilnehmer durch den Product Owner stellt er das Sprintziel vor.
2. Das Entwicklungsteam demonstriert dieneuen Funktionalitäten.
3. Der Scrum Master moderiert das Teffen.
4. Das Feedback wird vom Product Owner dokumentiert.
- Feedback (mit Auswirkung auf das Product Backlog)
- Neue Stories
- Punkte für das Impediment Backlog

17. Event: SPRINT Review - Eigenschaften
Das Team präsentiert in Form
einer Demo alles was während
eines Sprints erreicht wurde.
Grobe Regel: Zwei Stunden zur
Vorbereitung, keine Folien,
sondern echte Artefakte.
Das ganze Team sowie jeder der
daran Interesse hat nimmt teil.
Feedback kann von jedem aus
dem Raum gegeben werden.

18. Event: SPRINT Retrospective
Das Scrum Team identifiziert die Verbesserungsmöglichkeiten am gemeinsamen
Arbeitsprozess, um noch effektiver und effizienter Erfolge zu erzielen.
1. In einem Zeitrahmen von 30-60 min wird der Status quo überprüft:
- Was lief gut während demSprint?
- Was kann im nächsten Sprint verbessert werden?
2. Diskussion der identifizierten Probleme
Ableitung von max. 3 Action items
- Aus der Vergangenheit für die Zukunft lernen
- Ziel ist es, die Produktivität des Teams zu verbessern

19. Artefakte
u Product Backlog
u Sprint Backlog
u Inkrement
u Definition of Done
u Monitoring Prozess
u Monitoring Sprint Ziel

20. Überblick