Wiki source code of Scrum

Version 7.1 by Pascal Meyer on 2025/07/29 03:54

version	line-number	content
1.5	1	= Scrum - Ein kurzer Überblick =
1.1	2
1.5	3	Was ist Scrum und warum brauchen wir das im SWP?
	4
	5	* Scrum ist einer von mehreren agilen Projektmanagement-Ansätzen und insbesondere für die Softwareentwicklung geeignet
	6	* Wird benötigt, um die Entwicklung des im SWP geforderten Produkts im Rahmen eines vernünftig strukturierten Projektmanagements umzusetzen
	7
	8	Charakteristika:
	9
	10	* Selbst-organisierende Teams
	11	* Scrum-Projekte schreiten in Serien von Sprints voran
	12	* Typische Sprintdauer beträgt 2-4 Wochen → //Im SWP haben sich 2-3 Wochen bewährt//
	13	* Konstante Dauer führt zu einem besseren Rhythmus
	14	* Produkt wird während des Sprints entworfen, kodiert und getestet
	15	* Es gibt Zeiten, in denen man in keinem Sprint ist, sondern einen neuen Sprint vorbereitet
	16	* Anforderungsanalyse sollte grundsätzlich vor allen Sprints erfolgen
	17	* 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.)
	18	* Im SWP "kleine iterative Wasserfälle" → Anforderung, Design, Kodierung, Test
	19
	20	Rahmen:
	21
1.8	22	* Rollen:
1.7	23	Product Owner**
1.5	24	*** Definiert Product-Features
	25	*** Bestimmt Auslieferungsdatum und Inhalt
	26	*** Akzeptiert oder weist Arbeitsergebnisse zurück
	27	*** Im SWP der Tutor in Absprache mit Marco und das Team
1.7	28	Scrum Master**
1.6	29	*** Repräsentiert das Management gegenüber dem Projekt
	30	*** Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken
	31	*** Beseitigt Hindernisse
	32	*** Stellt sicher, dass das Team vollständig, funktional und produktiv ist
	33	*** Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen
	34	*** Schützt das Team vor äußeren Störungen
1.7	35	*** Im SWP ein spezielles Mitglied der Gruppe, welches trotzdem auch mitentwickelt
	36	Entwicklungs-Team**
	37	*** Typischerweise 5-9 Personen
	38	*** Funktionsübergreifend
	39	**** QS, Programmierer, UI-Designer, etc.
	40	*** Mitglieder sollen Vollzeitmitglieder sein
	41	*** Teams organisieren sich selbst
	42	*** Mitgliedschaft kann nur zwischen Sprints verändert werden
1.8	43	* Meetings:
1.7	44	Sprint Planning**
	45	*** Sprint Priorisierung
	46	**** Product Backlog analysieren und auswerten
	47	**** Sprint-Ziel festlegen
	48	*** Planung
	49	**** Entscheiden, wie man das Sprint-Ziel erreichen kann (Design)
	50	**** Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen
	51	***** Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus
	52	*** Sprint Backlog schätzen (Planning Poker, Magic Estimation, etc.)
	53	*** Sprint-Ziel
	54	**** Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
	55	**** Wichtig! Wird gerne unterschätzt
	56	**** Hilft, das Ziel im Auge zu behalten
3.2	57	Sprint Review**
1.8	58	*** Das Team präsentiert, was es während eines Sprints erreicht hat
	59	*** Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur
	60	*** Das ganze Team nimmt teil!
	61	Sprint Retrospektive**
	62	*** Regelmäßig prüfen, was gut und was nicht so gut funktioniert
	63	*** ca. 15-30 min lang
	64	*** Nach jedem Sprint
	65	*** Das gesamte Team kommt zusammen und diskutiert, wie es sich verbessern möchte
	66	*** Methode hierfür bspw: Starfish (siehe Bild)
	67	*** Weitere Methoden für die Retrospektiven finden sich z.B. hier: [[https:~~/~~/retromat.org/>>url:https://retromat.org/]]
	68	Tägliches Scrum-Meeting (Daily)**
	69	*** Wöchentliches Treffen startet mit Scrum-Meeting
	70	*** Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
	71	*** Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren
	72	* Artefakte:
1.9	73	Product Backlog**
	74	*** Die Anforderungen für das finale Produkt
	75	*** Eine Liste aller gewünschten Projektarbeiten
	76	*** Eigentlich immer mehr, als im aktuellen Sprint gebraucht wird
	77	*** Im SWP: Zu Beginn füllen und später ergänzen
	78	*** Vom Product Owner priorisiert
	79	*** Zu Beginn des Sprints repriorisiert
	80	Sprint Backlog**
	81	*** Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)
	82	* Aber:**
	83	**** Im SWP hat jeder am Ende einer Sitzung eine Aufgabe!
	84	**** Im Zweifelsfall durch Zuweisung...
	85	*** Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)
	86	*** Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird
	87	*** Definieren Sie für die Tickets eine Definition of Done ([[https:~~/~~/www.scrum-events.de/was-ist-die-definition-of-done-dod.html>>url:https://www.scrum-events.de/was-ist-die-definition-of-done-dod.html]])
3.2	88	Produktinkrement**
1.5	89
6.3	90	[[image:Scrum-Prozess.JPG]]
6.2	91
3.2	92	= Scrum - im Detail =
1.5	93
	94	== Scrum-Prozess ==
	95
6.3	96	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.
1.5	97
	98	== Product Backlog ==
	99
6.3	100	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.
1.5	101
	102	=== Der Nutzen eines gepflegten/priorisierten Product Backlogs ===
	103
	104	Priorisiert:
	105
	106	* Um die für das Projekt wertvollsten Stories am Anfang zu bearbeiten
	107	* So kann schnell ein funktionierendes Spiel entwickelt werden
	108	* Am Ende ist dann noch genug Zeit für feinere Anpassungen
	109	* Kann die Arbeit im Projekt erleichtern
	110
	111	Gepflegt:
	112
	113	* Wichtig für ein effizientes, übersichtliches Arbeiten
	114
	115	=== Unterschiede Product Backlog vs. Sprint Backlog ===
	116
	117	* Product Backlog ist nie vollständig und zu jederzeit anpassbar
	118	* Sprint Backlog kann nur unter bestimmten Voraussetzungen angepasst werden
	119
	120	== Sprint Planning ==
	121
6.3	122	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.
1.5	123
	124	=== Ablauf eines Plannings (Checkliste) ===
	125
	126	✓ Sprint-Ziel festlegen
	127	✓ Anhand des Sprint-Ziels die passenden User Stories aus dem Product Backlog suchen
	128	✓ Die vorhandenen Schätzungen der User Stories überprüfen und ggf. anpassen
	129	✓ Nicht geschätzte User Stories schätzen
	130	✓ (nicht im ersten Sprint) Velocity heranziehen und schauen, wie viele Story Points im letzten Sprint erledigt wurden
	131	✓ Die gleiche Anzahl an Story Points in das Sprint Backlog ziehen
	132	✓ User Stories in Tasks aufsplitten
	133	✓ Alle Teammitglieder suchen sich Aufgaben aus, die sie bearbeiten möchten
	134	✓ Sprint starten
	135
	136	=== Die dazugehörigen Elemente eines Sprint Plannings ===
	137
	138	* Sprint-Ziel
	139	* Schätzen von Aufwänden
	140	* Product Backlog
	141	* Velocity
	142
	143	== Schätzen von Aufwänden ==
	144
6.3	145	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".
1.5	146
	147	=== Ablauf der Aufwandsschätzung (Checkliste) ===
	148
	149	✓ Auf eine Werteskala einigen (Fibonacci oder T-Shirt Größen) (siehe Abschnitt "Vorschlag für eine Werteskala zum Schätzen")
	150	✓ Auf eine Schätzmethode einigen (siehe Abschnitt "Der Ablauf vom Planningpoker")
	151	✓ Eine Referenzstory bestimmen, anhand dessen geschätzt werden soll
	152	✓ Definition of Done bei der Schätzung mit einbeziehen
	153	✓ Geschätzte Story Points den jeweiligen Stories hinzufügen
	154
	155	=== Der Ablauf vom Planningpoker ===
	156
	157	* Jedes Teammitglied hat einen Satz Karten, auf dem eine zuvor bestimmte Werteskala abgebildet ist (online abwandelbar, siehe Abschnitt "Tools, um online zu schätzen")
	158	* Stories werden vorgestellt
	159	* Es dürfen Fragen zu den Stories gestellt werden, falls etwas unklar ist
	160	* Danach legt jedes Teammitglied eine Karte mit einem Wert verdeckt auf den Tisch
	161	* Hat jede Person eine Karte abgelegt, werden diese umgedreht
	162	* Ziel: Team einigt sich auf einen Wert
	163	* Weichen die Werte auf den Karten stark voneinander ab, besteht offenbar Diskussionsbedarf
	164	* 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
	165
	166	=== Vorschlag für eine Werteskala zum Schätzen ===
	167
	168	* Nur wenige Zahlen auswählen (bspw. 1,2,3,5,8)
	169	* 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
	170
3.2	171	[[image:tshirtfibo.JPG]]
1.5	172
	173	=== Definition eines Velocity Charts ===
	174
6.3	175	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
	176	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.
1.5	177
3.2	178	[[image:velo.JPG]]
1.5	179
	180	=== Definition eines Burndown Charts ===
	181
6.3	182	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.
1.5	183
6.2	184	[[image:burnd.JPG]]
1.5	185
	186	== Daily Scrum ==
	187
6.3	188	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
	189
1.5	190	drei Fragen:
	191
	192	1. Was habe ich gestern gemacht?
	193	1. Was werde ich heute tun?
	194	1. Gibt es Hindernisse, die mir im Weg stehen?
	195
7.1	196	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.
1.5	197
	198	== Definition of Done/Definition of Ready ==
	199
	200	=== Definition of Done ===
	201
7.1	202	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.
1.5	203
	204	==== Nutzen einer Definition of Done ====
	205
	206	* Wenn keine Definition of Done vorhanden ist, kann es schnell zu einem Impediment führen, da kein klares Ende einer Story in Sicht ist
	207	* Jedes Teammitglied ist dazu verpflichtet, diese Definition of Done einzuhalten
	208	* 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
	209	* Sollte direkt am Anfang erstellt werden, damit das Team sich dahingehend weiterentwickeln und lernen kann
	210
	211	=== Definition of Ready ===
	212
7.1	213	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.
1.5	214
	215	=== Unterschiede zwischen Definition of Done und Definition of Ready ===
	216
	217	* Definition of Done beschreibt, wann eine User Story fertig bearbeitet wurde
	218	* Definition of Ready beschreibt, wann eine User Story fertig beschrieben wurde
	219
	220	== Sprint Review ==
	221
7.1	222	Am Ende eines Sprints findet das Sprint Review statt. 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.
1.5	223
	224	=== Mehrwert eines Reviews ===
	225
	226	* Dient dazu, allen Teammitgliedern zu zeigen, was in dem Sprint bearbeitet wurde
	227	* Alle Teammitglieder bleiben auf dem neuesten Stand
	228	* Es kann dadurch verhindert werden, dass Teammitglieder abgehängt werden, sollte deshalb regelmäßig durchgeführt werden
	229	* 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
	230
	231	== Sprint Retrospektive ==
	232
7.1	233	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
1.5	234
	235	Beispiele für Retrospektiven finden sich z.B. hier: [[https:~~/~~/dzone.com/articles/7-formats-for-great-team-retrospectives?edition=703410>>url:https://dzone.com/articles/7-formats-for-great-team-retrospectives?edition=703410]]
	236
6.2	237	[[image:Unbenannt2.JPG]]
1.5	238
6.2	239
1.5	240
1.4	241
6.2	242
	243

Wiki source code of Scrum

Applications

Navigation