Überblick

Was ist Scrum und warum brauchen wir das im SWP?

• Scrum ist einer von mehreren agilen Projektmanagement-Ansätzen und insbesondere für die Softwareentwicklung geeignet
• Wird benötigt, um die Entwicklung des im SWP geforderten Produkts im Rahmen eines vernünftig strukturierten Projektmanagements umzusetzen

Charakteristika

• Selbst-organisierende Teams
• Scrum-Projekte schreiten in Serien von Sprints voran
• Typische Sprintdauer beträgt 2-4 Wochen → Im SWP haben sich 2-3 Wochen bewährt
• Konstante Dauer führt zu einem besseren Rhythmus 
• Produkt wird während des Sprints entworfen, kodiert und getestet
• Es gibt Zeiten, in denen man in keinem Sprint ist, sondern einen neuen Sprint vorbereitet
• Anforderungsanalyse sollte grundsätzlich vor allen Sprints erfolgen
• Anforderungen sind als Listeneinträge im Product Backlog festgehalten (Hinweis: Das Backlog kann mehr als nur die Anforderungen enthalten, d.h. nicht jeder Eintrag im Backlog entspricht einer Anforderung.)
• Im SWP "kleine iterative Wasserfälle" → Anforderung, Design, Kodierung, Test

Rahmen

• Rollen
  • Product Owner
  • Scrum Master
  • Entwicklungs-Team
• Meetings
  • Sprint Planning
  • Sprint Review
  • Sprint Retrospektive
  • Tägliches Scrum-Meeting (Daily)
• Artefakte
  • Product Backlog
  • Sprint Backlog
  • Produktinkrement

Rollen

Product Owner:

• Definiert Product-Features
• Bestimmt Auslieferungsdatum und Inhalt
• Akzeptiert oder weist Arbeitsergebnisse zurück
• Im SWP der Tutor in Absprache mit Marco und das Team

Scrum Master:

• Repräsentiert das Management gegenüber dem Projekt
• Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken
• Beseitigt Hindernisse
• Stellt sicher, dass das Team vollständig, funktional und produktiv ist
• Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen
• Schützt das Team vor äußeren Störungen

           → Im SWP ein spezielles Mitglied der Gruppe

           → Soll trotzdem auch mit entwickeln

Entwicklungs-Team:

• Typischerweise 5-9 Personen
• Funktionsübergreifend
  • QS, Programmierer, UI-Designer, etc.
• Mitglieder sollen Vollzeitmitglieder sein 
• Teams organisieren sich selbst
• Mitgliedschaft kann nur zwischen Sprints verändert werden

           → Es kann helfen, einen Projektleiter zu bestimmen (ist nicht Scrum-Konform, aber im SWP kann es hilfreich sein)

Meetings

Sprint Planning

• Sprint Priorisierung
  • Product Backlog analysieren und auswerten
  • Sprint-Ziel festlegen
• Planung
  • Entscheiden, wie man das Sprint-Ziel erreichen kann (Design)
  • Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen
    • Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus
• Sprint Backlog schätzen (Planning Poker, Magic Estimation, etc.)

• Sprint-Ziel

  • Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
  • Wichtig! Wird gerne unterschätzt
  • Hilft, das Ziel im Auge zu behalten

Daily Scrum (hier: Weekly)

• Wöchentliches Treffen startet mit Scrum-Meeting
• Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
• Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren

Sprint-Review

• Das Team präsentiert, was es während eines Sprints erreicht hat
• Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur
• Das ganze Team nimmt teil!

Sprint-Retrospektive

• Regelmäßig prüfen, was gut und was nicht so gut funktioniert
• ca. 15-30 min lang 
• Nach jedem Sprint
• Das gesamte Team kommt zusammen und diskutiert, wie es sich verbessern möchte
• Methode hierfür bspw: Starfish (siehe Bild) 
• Weitere Methoden für die Retrospektiven finden sich z.B. hier: https://retromat.org/

Artefakte

Product Backlog

• Die Anforderungen für das finale Produkt 
• Eine Liste aller gewünschten Projektarbeiten
• Eigentlich immer mehr, als im aktuellen Sprint gebraucht wird 
• Im SWP: Zu Beginn füllen und später ergänzen 
• Vom Product Owner priorisiert
• Zu Beginn des Sprints repriorisiert

Sprint Backlog

• Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)
• Aber:
  
  • Im SWP hat jeder am Ende einer Sitzung eine Aufgabe!
  • Im Zweifelsfall durch Zuweisung...
• Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)
• Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird
• Definieren Sie für die Tickets eine Definition of Done (https://www.scrum-events.de/was-ist-die-definition-of-done-dod.html)

Scrum im Detail

Scrum-Prozess

Nachdem die Produktvision definiert wurde, wird das Product Backlog erstellt und vom
Product Owner (hier: gesamtes Team im Softwareprojekt) verwaltet. Aus dem Sprint
Planning resultiert das Sprint Backlog, welches im Sprint durch das Entwicklungsteam
(hier: Scrum Master gehört zum Entwicklungsteam und programmiert mit) abgearbeitet
wird. Der Scrum Master sorgt dafür, dass das Entwicklungsteam ungestört arbeiten
kann. Täglich (hier: wöchentlich) trifft er sich im Daily Scrum mit dem Team. Nach
dem Sprint wird ein Produktinkrement an den Auftraggeber (hier: an das gesamte
Team) ausgeliefert und in einem Sprint Review näher erläutert. Anschließend wird eine
Sprint Retrospektive durchgeführt, in der das Team die Zusammenarbeit reflektieren kann.

Product Backlog

Ein Product Backlog ist eine priorisierte Anforderungsliste für das von dem Auftraggeber
gewünschte Softwareprodukt. Diese ist nie vollständig und zu jederzeit anpassbar. Der
Product Owner (hier: das gesamte Team) ergänzt das Backlog stetig und hat in den
meisten Fällen bereits User Stories für den nächsten Sprint geplant. Aus diesem Grund
sind in dem Backlog nicht alle für das komplette Produkt relevanten Anforderungen
zu finden, weil sich von Sprint zu Sprint immer wieder neue Anforderungen ergeben
oder alte verworfen werden. Es ist auch möglich, dass sich die Prioritäten ändern. Der
Product Owner (hier: das gesamte Team) verwaltet das Backlog, allerdings muss es für
alle Mitglieder des Scrum Teams ersichtlich sein.

Der Nutzen eines gepflegten/priorisierten Product Backlogs

Priorisiert:

• Um die für das Projekt wertvollsten Stories am Anfang zu bearbeiten
• So kann schnell ein funktionierendes Spiel entwickelt werden
• Am Ende ist dann noch genug Zeit für feinere Anpassungen
• Kann die Arbeit im Projekt erleichtern

Gepflegt:

• Wichtig für ein effizientes, übersichtliches Arbeiten

Unterschiede Product Backlog vs. Sprint Backlog

• Product Backlog ist nie vollständig und zu jederzeit anpassbar
• Sprint Backlog kann nur unter bestimmten Voraussetzungen angepasst werden

Sprint Planning

Nachdem das Product Backlog initial gefüllt und das Sprint-Ziel festgelegt wurde, kann
das Planning beginnen. Das Sprint Planning ist wichtig, weil der Product Owner und
das Entwicklungsteam (hier: das gesamte Team) sich so einig über die zu bearbeitenden
User Stories werden können. In diesem Meeting wird gemeinsam mit dem Team, dem
Scrum Master und dem Product Owner der Sprint vorbereitet.

Ablauf eines Plannings (Checkliste)

✓ Sprint-Ziel festlegen
✓ Anhand des Sprint-Ziels die passenden User Stories aus dem Product Backlog suchen
✓ Die vorhandenen Schätzungen der User Stories überprüfen und ggf. anpassen
✓ Nicht geschätzte User Stories schätzen
✓ (nicht im ersten Sprint) Velocity heranziehen und schauen, wie viele Story Points im letzten Sprint erledigt wurden
✓ Die gleiche Anzahl an Story Points in das Sprint Backlog ziehen
✓ User Stories in Tasks aufsplitten
✓ Alle Teammitglieder suchen sich Aufgaben aus, die sie bearbeiten möchten
✓ Sprint starten

Die dazugehörigen Elemente eines Sprint Plannings

• Sprint-Ziel
• Schätzen von Aufwänden
• Product Backlog
• Velocity

Schätzen von Aufwänden

Es sollte aus mehreren Gründen geschätzt werden. Zum einen bekommen alle Teammitglieder
einen Einblick in den Inhalt aller User Stories, bevor angefangen wird, sie
umzusetzen. Dies schärft das Verständnis für das Produkt. Zum anderen findet das
Schätzen im besten Fall mit dem gesamten Team statt, wodurch dieses Meeting eine
teamgeistfördernde Aktivität ist. Ein weiterer Vorteil ist, dass jede Person im Team weiß,
worum es in der Story geht, sodass jede Person jede Aufgabe bearbeiten kann. Außerdem
können so in Diskussionen Probleme oder zusätzliche Informationen identifiziert werden,
wenn eine User Story beispielsweise in kleinere sinnvolle Einheiten aufgeteilt werden
kann. Die Einheit, in der zumeist geschätzt wird, nennt sich "Story Points".

Ablauf der Aufwandsschätzung (Checkliste)

✓ Auf eine Werteskala einigen (Fibonacci oder T-Shirt Größen) (siehe Abschnitt "Vorschlag für eine Werteskala zum Schätzen")
✓ Auf eine Schätzmethode einigen (siehe Abschnitt "Der Ablauf vom Planningpoker")
✓ Eine Referenzstory bestimmen, anhand dessen geschätzt werden soll
✓ Definition of Done bei der Schätzung mit einbeziehen
✓ Geschätzte Story Points den jeweiligen Stories hinzufügen

Der Ablauf vom Planningpoker

• Jedes Teammitglied hat einen Satz Karten, auf dem eine zuvor bestimmte Werteskala abgebildet ist (online abwandelbar, siehe Abschnitt "Tools, um online zu schätzen")
• Stories werden vorgestellt
• Es dürfen Fragen zu den Stories gestellt werden, falls etwas unklar ist
• Danach legt jedes Teammitglied eine Karte mit einem Wert verdeckt auf den Tisch
• Hat jede Person eine Karte abgelegt, werden diese umgedreht
• Ziel: Team einigt sich auf einen Wert
• Weichen die Werte auf den Karten stark voneinander ab, besteht offenbar Diskussionsbedarf
• Nach der Diskussion geht es in eine zweite Runde, bis sich das Team einigen konnte und alle offenen Fragen zu der Story geklärt sind

Vorschlag für eine Werteskala zum Schätzen

• Nur wenige Zahlen auswählen (bspw. 1,2,3,5,8)
• Wenn in T-Shirt-Größen geschätzt wird, dann jeder Größe eine Zahl zuweisen, sodass das Burndown- und Velocity-Chart genutzt werden kann

Definition eines Velocity Charts

Hat das Team schon mindestens einen Sprint hinter sich, kann der nächste Sprint auf
Basis der Velocity aufgebaut werden. Die Velocity steht für die Geschwindigkeit des
Teams. Das bedeutet, dass ermittelt wird, wie viele Story Points das Entwicklungsteam
in dem vorherigen Sprint geschafft hat. Aufgrund dieser Information kann der darauf
folgende Sprint genauer geplant werden, indem sich das Team nur auf die Anzahl der
vorher erledigten Story Points committet. Die Abbildung zeigt ein solches Velocity Chart.
Die x-Achse zeigt die bisherige Anzahl an Sprints und die y-Achse die Story Points, die
in einem Sprint erledigt wurden. Es ist zu sehen, dass beispielsweise im zweiten Sprint
15 Story Points geschafft wurden, jedoch im dritten Sprint nur fünf. Ab dem dritten
Sprint kann eine Verbesserung der Geschwindigkeit des Teams wahrgenommen werden.

Definition eines Burndown Charts

Eine Möglichkeit zur Überprüfung des Fortschritts während eines Sprints ist die Erstellung
eines Burndown Charts. Es zeigt die bereits erledigten Story Points auf Basis
der verbleibenden Zeit an. Somit kann schnell gesehen werden, ob Verzögerungen oder
Probleme auftreten und falls dies der Fall ist, kann ein Meeting einberufen werden,
damit über die Probleme gesprochen wird. Die Abbildung zeigt ein
Burndown Chart. Auf der x-Achse sind die Arbeitstage zu sehen und auf der y-Achse
die noch zu erledigenden Story Points für den Sprint. Es ist zu sehen, dass das Team
bisher einen guten Fortschritt hat, weil der Graph bisher stetig abfällt.

Daily Scrum

Täglich (hier: wöchentlich) treffen sich das Entwicklungsteam und der Scrum Master
zu einem Meeting. Es ist ein sehr kurzes Treffen, welches immer zur gleichen Zeit am
gleichen Ort stehend stattfindet. Zumeist stehend, damit es bewusst kurz gehalten wird.
Das Treffen sollte nicht länger als 15 Minuten dauern. Jedes Teammitglied beantwortet
drei Fragen:

1. Was habe ich gestern gemacht?
2. Was werde ich heute tun?
3. Gibt es Hindernisse, die mir im Weg stehen?

Durch das Daily Scrum werden Probleme sichtbar, die für den Scrum Master von großer
Bedeutung sind, da er hierdurch eventuelle Impediments wahrnehmen und anschließend
beseitigen kann. Außerdem ist dieses Treffen für das Team wichtig, um sich gegenseitig
zu informieren und nach eventuell benötigter Hilfe zu suchen. Damit dieses Treffen
möglichst effektiv ist, sollten sich die Teammitglieder darauf vorbereiten und vorher
überlegen, was gestern bearbeitet wurde und was heute erledigt wird. Der Scrum
Master sorgt in diesem Meeting dafür, dass die anderen Teammitglieder nicht den Fokus
verlieren. Außerdem achtet er auf die Zeit, sodass diese eingehalten wird.

Definition of Done/Definition of Ready

Definition of Done

Während eines Sprints beginnen die Entwickler erst eine neue Story, wenn die vorherige
abgeschlossen ist. Damit alle Teammitglieder und der Product Owner (hier: das gesamte
Team) das gleiche Verständnis für "fertig" haben, gibt es die Definition of Done. Diese
umfasst eine Sammlung bestimmter Kriterien, die erfüllt sein müssen, damit eine
Story als "fertig" gilt. Sie ist eine Forderung seitens des Product Owners an das
Entwicklungsteam (hier: seitens des Teams), welche, ebenso wie die Definition of Ready,
verhandelt wird. Die Kriterien der Definition of Done sammelt das Team gemeinsam
mit dem Product Owner (hier: ohne den Product Owner) bei einem separaten Treffen.

Nutzen einer Definition of Done

• Wenn keine Definition of Done vorhanden ist, kann es schnell zu einem Impediment führen, da kein klares Ende einer Story in Sicht ist
• Jedes Teammitglied ist dazu verpflichtet, diese Definition of Done einzuhalten
• Wenn sie nicht eingehalten wird, kann es am Ende des Projekts zu sehr viel Stress führen, wodurch viel Zeit verloren geht für bspw. Feinheiten
• Sollte direkt am Anfang erstellt werden, damit das Team sich dahingehend weiterentwickeln und lernen kann

Definition of Ready

Eine Definition of Ready ist eine Sammlung von Forderungen von dem Entwicklungsteam
an den Product Owner (hier: innerhalb des Teams), wie eine User Story beschrieben
sein muss, damit das Entwicklungsteam ungestört und ohne Hindernisse arbeiten kann.
Über diese Forderungen verhandelt das Team mit dem Product Owner (hier: das Team
handelt die Punkte untereinander aus) und das Ergebnis ist die Definition of Ready.
Beispielsweise kann das Team eine Form vorgeben, wie der Titel der Story geschrieben
sein soll oder dass Akzeptanzkriterien enthalten sein müssen und in welcher Form.
Das Team muss überprüfen, ob die Kriterien in den User Stories eingehalten wurden.
Wurden sie nicht eingehalten, können große Verzögerungen entstehen.

Unterschiede zwischen Definition of Done und Definition of Ready

• Definition of Done beschreibt, wann eine User Story fertig bearbeitet wurde
• Definition of Ready beschreibt, wann eine User Story fertig beschrieben wurde

Sprint Review

Am Ende eines Sprints findet das Sprint Review statt (siehe Sprint-Review mit Jira). Bei diesem Treffen werden
die Sprint-Ergebnisse allen Interessierten präsentiert. Dazu gehören beispielsweise der
Auftraggeber oder andere Stakeholder (hier: mit dem gesamten Team und ggf. dem
Tutor). Der Scrum Master bereitet dieses Meeting vor, indem er die Interessenten über
dieses Treffen informiert, des Weiteren moderiert er die Sitzung. Die Vorstellung der
Ergebnisse wird von den Teammitgliedern (hier: inkl. dem Scrum Master, da auch
der Scrum Master im Softwareprojekt programmiert) vorbereitet. Nachdem der Scrum
Master das Meeting eröffnet hat, erklärt er kurz das Sprint-Ziel und die User Stories,
die abgeschlossen wurden. Dann präsentiert das Entwicklungsteam die Ergebnisse. 

Mehrwert eines Reviews

• Dient dazu, allen Teammitgliedern zu zeigen, was in dem Sprint bearbeitet wurde
• Alle Teammitglieder bleiben auf dem neuesten Stand
• Es kann dadurch verhindert werden, dass Teammitglieder abgehängt werden, sollte deshalb regelmäßig durchgeführt werden
• Tutor wird über den Fortschritt informiert und kann bei Bedarf Tipps oder Hinweise geben, sodass verhindert werden kann, dass die Studierenden in eine komplett falsche Richtung laufen

Sprint Retrospektive

Während einer Retrospektive kann das Entwicklungsteam die Zusammenarbeit reflektieren,
Missmut äußern und Vorschläge für Verbesserungen sammeln. Das Ziel einer
Retrospektive ist der kontinuierliche Verbesserungsprozess innerhalb des Teams. Ein
gut funktionierendes Team kann qualitativ hochwertige Produkte liefern. Eine Retrospektive
muss von einem Scrum Master gut vorbereitet werden. Der Scrum Master
moderiert dieses Treffen

Beispiele für Retrospektiven finden sich z.B. hier: https://dzone.com/articles/7-formats-for-great-team-retrospectives?edition=703410

Video zur Sprintretrospektive und die Verwendung in Jira 1080p

Übersicht der einzelnen Scrum-Elemente + deren Zusammenhänge