Scrum Überblick Teil 2

1. Scrum Overview
Teil 2
Christof Zahn

2. Review Teil 1
• Was ist Scrum
• Theorie des Empirismus
• Rollen im Scrum
• Product Owner
• Scrum Master
• Entwickler Team

3. Review Teil 1
• Scrum Prozesse und Artefakte
• Das Product Backlog
• User Stories / Anforderungsmanagement
• Schätzung / Planning Poker
• Der Sprint
• Sprint Planning Meeting 1 und 2
• Das Scrum Taskboard
• Sprint Backlog
• Hindernisse (Impediments)
• Daily Scrum

4. Definition of Done
• Jedes Team hat sein "Definition of done"
• wird im Sprint Meeting definiert
• Aufgaben sind erst fertig, wenn sie im Sinne des
"Definition of Done" fertig sind
• eine fertige Aufgabe liefert immer eine "Potentiell
auslieferbare Funktion"
• eine fertige Aufgabe ist getestet und dokumentiert

5. Sprint Review Meeting
• dauer 4 std.
• am Ende eines jeden Sprints
• Offenes Meeting, alle Stakeholder zugelassen
• Ergebnis / Produkt wird vom Entwickler Team
präsentiert
• nur fertige(!) Funktionen. Keine Dummys,
Präsentation

6. Sprint Retrospektive
• internes Meeting
• Anwesend: Scrum Master und Team
• was lief gut, was gilt es zu verbessern

7. Fortschrittskontrolle
• Fokus auf Restaufwände
• jeden Abend pro Arbeitspaket Restaufwände
schätzen
• Summe in Burndown Chart eintragen

8. Sprint Burndown
Charts
Quelle: www.sw-engineering-candies.com

9. Kennzahlen
• Remaining Work: Restaufwände pro arbeitspaket
• Total Burndown: gibt Auskunft darüber, wie viel Aufwand aus dem initial
geplanten Aufwand pro Sprint heruntergebrannt werden kann.
• Added Work: gibt Auskunft darüber, wie viele Änderungen sich
durchschnittlich pro Sprint ergeben haben.
• Team Burndown: gibt Auskunft darüber, wie viel Aufwand das Team real
heruntergebrannt hat, inkl. der Änderungen.
• Velocity: Burndown Geschwindigkeit des Teams pro Sprint
• Auf Basis dieser Informationen kann der nächste Sprint besser "vorausgesetzt"
werden = heisst in scrum "Das Wetter von gestern"
• Empirische Planung

10. Weitere, wichtige
Fragmente
• Time Boxing Prinzip
• Test driven Development

11. Warum Scrum?
• bessere Softwarequalität
• Mensch, Kunde, Team steht im Vordergrund
• Komplexität simplifizieren
• Empirisches Vorgehen = ich lerne aus der
Erfahrung

12. Das Agile Manifest
Individuen und Interaktionen mehr als Prozesse und
Werkzeuge
Funktionierende Software mehr als umfassende
Dokumentation
Zusammenarbeit mit dem Kunden mehr als
Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen
eines Plans

13. Scrum implementieren
• Lean Ansatz, schlank, "Bürokratielos"
• Scrum agil implementieren!
• Erstmal keine Software Unterstützung, (fast) alles
"offline"
• sukezzive Implementation, kontinuierliche Optimierung
- Nach Kaizen!
• Fragmente raussuchen und an eigene Prozesse
anpassen