Scrum ist ein schlankes Projektmanagement-Framework, das sich für Projekte mit unsicheren Anforderungen eignet und Iterationen sowie regelmäßige Anpassungen unterstützt. Es umfasst Rollen wie den Product Owner, Scrum Master und das Entwicklerteam, die alle gemeinsam an der Produktentwicklung im Rahmen von Sprints arbeiten. Wichtige Elemente sind das Product Backlog, Sprint Planning Meetings und Daily Scrums, die die Selbstorganisation und Eigenverantwortung des Teams fördern.

1. Scrum Overview
Teil 1
Christof Zahn

2. Was ist Scrum
• schlankes Projektmanagement Framework
• einfache Regeln
• besonderst für Projekte mit "schwammigen" Anforderungen geeignet
• Änderungen während des Projektes sind erwünscht
• selbstorganisiertes und eigenverantwortliches Team steht im
Vordergrund
• stark beeinflusst durch Extreme Programming (XP)
• iteratives Vorgehen und Verbesserung der Vorhersehbarkeit

3. Was ist Scrum
Scrum basiert auf der Theorie des Empirismus
"Empirismus basiert auf der Grundannahme,
dass Wissen aus Erfahrung gewonnen wird
und dass Entscheidungen auf Grundlage
bekannter Fakten getroffen werden."

4. Rollen
• Product Owner
• Scrum Master
• Entwickler Team
bilden zusammen das Scrum Team

5. Product Owner
• Primärer Kontakt zum Kunden
• konzipiert und vermittelt Produktstrategie und Vision
• vertritt Stakeholder / Auftraggeber
• betrachtet Wirtschaftlichkeit
• verwaltet und priorisiert die Produkt Anforderungen (Product Backlog)
• sollte immer greifbar sein
• hat keinen Einfluss auf Sprints oder Daily Scrums. Wohnt diesen lediglich
bei
• ist kein Teil des Entwickler Teams

6. Scrum Master
• gleiches Level wie Entwickler Team / kein Vorgesetzter
• Schnittstelle zur "Außenwelt" / Product Owner
• kontrolliert Scrum Regeln und Prozesse
• verantwortlich für korrekte Umsetzung von Scrum
• beseitigt anfallende Hindernisse
• moderiert die Scrum-Meetings
• hat die Verantwortung über die Scrum-Dokumente (Product Backlog, Sprint
Backlog, Burndown Charts)
• schützt das Team vor Einflüssen während des Sprints
• ist kein Teil des Entwickler Teams

7. Entwickler Team
• zwischen 5 bis 9 Entwickler (in der Realität auch weniger)
• bei mehr Entwicklern erfolgt Aufteilung auf mehrere Teams
• verschiedene Rollen (Entwickler, Architekt, Tester, Redakteure, etc.)
• organisiert sich selbst
• Entwicklung findet i.d.R in einem "war room" statt
• gleichgestellt zu Product Owner und Scrum Master
• entwickelt das Produkt in den Sprints
• jedes Team Mitglied kennt das "große Ganze"
• aktualisiert täglich das Sprint Backlog

8. Weitere Rollen
• Benutzer
• Käufer
• Höheres Management
sind in Review Meetings involviert

9. Scrum Prozesse und
Artefakte
• Vorplanung
• Product Backlog
• Sprint Backlog
• Sprint

10. Der Scrum Prozess
Quelle : http://www.scrum-kompakt.de/files/2010/03/abb10_scrum_prozess.jpg

11. Der Scrum Prozess
Quelle : https://www.3m5.de/scrum/

12. Vorplanung
• Teammitglieder definieren
• Werkzeuge definieren
• Konventionen definieren
• erstes Product Backlog erstellen (Sammlung
der Anforderungen)

13. Das Product Backlog
• wird vom Product Owner verwaltet
• enthält alle Anforderungen
• Beschreibung in "User Stories"
• Reihenfolge = Priorität
• enthält Schätzung in Form von "Story Points"
• wird stetig aktualisiert (Priorität, Anzahl, Schätzung, etc.)
• Änderungen während des Projektes sind erwünscht

14. User Stories
"Als <Person> möchte ich Wer?
<Funktion> um Was?
<Nutzen> zu haben" Wozu?

15. User Stories
"Als Informatiker möchte ich
arbeiten um
Spass zu haben"

16. Requirement
Engineering
• im Scum FW nicht weiter detailliert
• verweis auf bestehende Normen (CMMI,
ISO, Cohn)
• erfolgt über "natürliche Sprache" oder
Modellierung (z.b. UML)
• Ziel: gemeinsames Verständnis schaffen

17. Schätzung
• geschätzt wird in Story Points "gefühlte Größen"
• Relative Kennzahl / Vergleichsgrösse zwischen den Backlog
Items
• Umrechnung in absolute Zahlen erfolgt nach Sprints
• Werkzeuge bei Schätzung:
• Planning Poker,
• fibonacci Sequenz 0,1,2...55,89
• Pert/Dreipunkt-Schätzung

18. Der Sprint
Quelle : https://www.3m5.de/scrum/

19. Sprint Planning
Meeting 1 und 2
• Kickoff
• wird in zwei Meetings aufgeteilt, möglichst an einem Tag
• Dauer: je 1 h pro Meeting pro Sprint Woche
• Teil 1
• Bestimmung des "was"
• Anwesend: Gesamtes Scrum Team
• Besprechung der Product Backlog Issues mit höchster Priorität
• Definition des Sprint Goals. Vorschlag des Product Owners. Commit durch Teams
• Verplichtende Bestimmung des Lieferumfangs anhand der Anfordeungen
• Entwickler Team entscheidet was in Sprint realistisch ist

20. Sprint Planning
Meeting 1 und 2
• Teil 2
• Bestimmung des "wie"
• Anwesend: Gesamtes Scrum Team. optional : Product Owner (aber
passiv). Weitere beratende Personen
• Entwickler Team arbeitet selbstorganisiert
• Breakdown der Anforderungen in Tasks für Sprint Backlog
• Dauer der Tasks <= 1 Tag. Ansonsten weiteres Breakdown
• Ggf. Nachverhandlung über Arbeitsumfang des Sprints
• Werkzeuge: Scrum Taskboard (Kanban Ansicht). Hängt im war room

21. Scrum Taskboard
Quelle: http://www.mountaingoatsoftware.com/scrum/task-boards

22. Vorteile Scrum Board
• alle Tasks auf einen Blick (ähnlich Kanban)
• trotzdem Fokus aufs wesentliche
• I.d.r In Form eines physikalischen Tafel, nicht online.
Somit
• effizienter,
• leichter pflegbar,
• immer im Blick

23. Sprint Backlog
• beinhaltet priorisierte Sprint Tasks
• steht in Beziehung zu Items aus dem Product
Backlog (i.d.r. 1 Item = n Tasks)
• Status wird durch Team täglich aktualisiert
• Scrum Master kontrolliert Status und sorgt für
Einhaltung des Sprint Goals

24. Im Sprint
• definierter Timeslot. I.d.r 4 Wochen oder weniger
• umsetzung aller Sprint Backlog Tasks
• Team arbeitet selbstständig und unterstützt sich gegenseitig
• keine Änderungen/Einflüsse während des Sprint erlaubt
• bestmögliche Abarbeitung aller Tasks während des Sprints
• Zum Start: Sprint Planning Meeting
• während des Sprints: Daily Scrums
• zum Ende: Sprint Review Meeting
• Scrum Master: kümmert sich um Hindernisse
• Das Team organisiert sich selbst

25. Hindernisse - der
Impediments Backlog
• alle Hindernisse (Blocker) werden in eine
Liste aufgenommen
• Liste wird bei Daily Scrum besprochen
• enthält Priorisierung, Datum, Beschreibung
• Scrum Master muss diese Hindernisse
zügig beseitigen

26. Daily Scrum
• 15 minütiges Stand-Up Meeting
• startet pünktlich (wie alle Scrum Meetings)
• erfolgt täglich immer am selben Ort
• Product Owner und Scrum Master nehmen als passive Zuhörer Teil
• abgleich der Aktivitäten seit und bis zum nächste Daily Scrum
• Hindernisse identifizieren und beseitigen. Protokollierung im "Impedment Backlog"
• Was wurde seit dem letzten Meeting erreicht?
• Was wird vor dem nächsten Meeting erledigt?
• Welche Hindernisse („Impediments“) sind dabei im Weg?
• Ggf. Folge-Gespräche unter den Entwicklern

27. Vorteile Daily Scrum
• verbessert Kommunikation
• effizientes Update
• fokussiert schnelle Entscheidungsprozesse
• verbessert Projektwissen aller Beteiligten

28. Ende Teil 1,
Ausblick Teil 2
• Sprint Ende, Review und Retrospektive
• Der Abschluss
• Fortschrittskontrolle / Reporting
• Releasemanagement
• Scrum implementieren

29. Quellen
• http://de.wikipedia.org/wiki/Scrum
• http://scrum-master.de/
• offical scrum rulebook, http://www.scrum.org/
• http://www.scrum-kompakt.de/