Scrum - XWiki des Softwarelabors der Informatik in der Universität Oldenburg

[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]

10

11

12

13

= Ein kurzer Überblick =

14

15

**Was ist Scrum und warum brauchen wir das im SWP?**

16

17

* Scrum ist einer von mehreren agilen Projektmanagement-Ansätzen und insbesondere für die Softwareentwicklung geeignet

18

* Wird benötigt, um die Entwicklung des im SWP geforderten Produkts im Rahmen eines vernünftig strukturierten Projektmanagements umzusetzen

**Charakteristika:**

* Selbst-organisierende Teams

23

* Scrum-Projekte schreiten in Serien von Sprints voran

24

* Typische Sprintdauer beträgt 2-4 Wochen → //Im SWP haben sich 2-3 Wochen bewährt//

25

* Konstante Dauer führt zu einem besseren Rhythmus

26

* Produkt wird während des Sprints entworfen, kodiert und getestet

27

* Es gibt Zeiten, in denen man in keinem Sprint ist, sondern einen neuen Sprint vorbereitet

28

* Anforderungsanalyse sollte grundsätzlich vor allen Sprints erfolgen

29

* 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.)

30

* Im SWP "kleine iterative Wasserfälle" → Anforderung, Design, Kodierung, Test

**Rahmen:**

* **Rollen:**

** **Product Owner**

*** Definiert Product-Features

37

*** Bestimmt Auslieferungsdatum und Inhalt

38

*** Akzeptiert oder weist Arbeitsergebnisse zurück

39

*** Im SWP der Tutor in Absprache mit Marco und das Team

40

** **Scrum Master**

41

*** Repräsentiert das Management gegenüber dem Projekt

42

*** Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken

43

*** Beseitigt Hindernisse

44

*** Stellt sicher, dass das Team vollständig, funktional und produktiv ist

45

*** Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen

46

*** Schützt das Team vor äußeren Störungen

47

*** Im SWP ein spezielles Mitglied der Gruppe, welches trotzdem auch mitentwickelt

48

** **Entwicklungs-Team**

49

*** Typischerweise 5-9 Personen

50

*** Funktionsübergreifend

51

**** QS, Programmierer, UI-Designer, etc.

52

*** Mitglieder sollen Vollzeitmitglieder sein

53

*** Teams organisieren sich selbst

54

*** Mitgliedschaft kann nur zwischen Sprints verändert werden

55

* **Meetings:**

56

** **Sprint Planning**

57

*** Sprint Priorisierung

58

**** Product Backlog analysieren und auswerten

59

**** Sprint-Ziel festlegen

60

*** Planung

61

**** Entscheiden, wie man das Sprint-Ziel erreichen kann (Design)

62

**** Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen

63

***** Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus

64

*** Sprint Backlog schätzen (Planning Poker, Magic Estimation, etc.)

65

*** Sprint-Ziel

66

**** Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren

67

**** Wichtig! Wird gerne unterschätzt

68

**** Hilft, das Ziel im Auge zu behalten

69

** **Sprint Review**

70

*** Das Team präsentiert, was es während eines Sprints erreicht hat

71

*** Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur

72

*** Das ganze Team nimmt teil!

73

** **Sprint Retrospektive**

74

*** Regelmäßig prüfen, was gut und was nicht so gut funktioniert

75

*** ca. 15-30 min lang

76

*** Nach jedem Sprint

77

*** Das gesamte Team kommt zusammen und diskutiert, wie es sich verbessern möchte

78

*** Methode hierfür bspw: Starfish (siehe Bild)

79

*** Weitere Methoden für die Retrospektiven finden sich z.B. hier: [[https:~~/~~/retromat.org/>>url:https://retromat.org/]]

80

** **Tägliches Scrum-Meeting (Daily)**

81

*** Wöchentliches Treffen startet mit Scrum-Meeting

82

*** Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)

83

*** Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren

84

* **Artefakte:**

85

** **Product Backlog**

86

*** Die Anforderungen für das finale Produkt

87

*** Eine Liste aller gewünschten Projektarbeiten

88

*** Eigentlich immer mehr, als im aktuellen Sprint gebraucht wird

89

*** Im SWP: Zu Beginn füllen und später ergänzen

90

*** Vom Product Owner priorisiert

91

*** Zu Beginn des Sprints repriorisiert

92

** **Sprint Backlog**

93

*** Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)

94

*** Aber**:**

95

**** Im SWP hat jeder am Ende einer Sitzung eine Aufgabe!

96

**** Im Zweifelsfall durch Zuweisung...

97

*** Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)

98

*** Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird

99

*** 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]])

100

** **Produktinkrement**

101

102

**[[image:Scrum-Prozess.JPG]]**

= Im Detail =

== Scrum-Prozess ==

Nachdem die Produktvision definiert wurde, wird das Product Backlog (in GitLab: [[Product-Backlog>>doc:Main.GitLab.WebHome||anchor="HProduct-Backlog"]]) erstellt und vom Product Owner //(hier: gesamtes Team im Softwareprojekt)// verwaltet. Aus dem Sprint Planning resultiert das Sprint Backlog (in Gitlab: [[Sprint-Backlog>>doc:Main.GitLab.WebHome||anchor="HSprint-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.

109

110

== Product Backlog ==

111

112

Ein Product Backlog (in GitLab: [[Product-Backlog>>doc:Main.GitLab.WebHome||anchor="HProduct-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.

113

114

=== **Der Nutzen eines gepflegten/priorisierten Product Backlogs** ===

115

116

In Gitlab: [[Pflege und Priorisierung>>doc:Main.GitLab.WebHome||anchor="HPflege2FPriorisierungdesProduct-Backlogs"]]

117

Priorisiert:

118

119

* Um die für das Projekt wertvollsten Stories am Anfang zu bearbeiten

120

* So kann schnell ein funktionierendes Spiel entwickelt werden

121

* Am Ende ist dann noch genug Zeit für feinere Anpassungen

122

* Kann die Arbeit im Projekt erleichtern

Gepflegt:

* Wichtig für ein effizientes, übersichtliches Arbeiten

127

128

=== **Unterschiede Product Backlog vs. Sprint Backlog** ===

129

130

* Product Backlog ist nie vollständig und zu jederzeit anpassbar

131

* Sprint Backlog kann nur unter bestimmten Voraussetzungen angepasst werden

132

133

== Sprint Planning ==

134

135

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.

136

137

=== **Ablauf eines Plannings (Checkliste)** ===

138

139

✓ Sprint-Ziel festlegen

140

✓ Anhand des Sprint-Ziels die passenden User Stories aus dem Product Backlog suchen

141

✓ Die vorhandenen Schätzungen der User Stories überprüfen und ggf. anpassen

142

✓ Nicht geschätzte User Stories schätzen

143

✓ (nicht im ersten Sprint) Velocity heranziehen und schauen, wie viele Story Points im letzten Sprint erledigt wurden

144

✓ Die gleiche Anzahl an Story Points in das Sprint Backlog ziehen

145

✓ User Stories in Tasks aufsplitten

146

✓ Alle Teammitglieder suchen sich Aufgaben aus, die sie bearbeiten möchten

147

✓ Sprint starten (in GitLab: [[Erstellung eines Sprints in GitLab>>doc:Main.GitLab.WebHome||anchor="HErstellungeinesSprints"]])

148

149

=== **Die dazugehörigen Elemente eines Sprint Plannings** ===

150

151

* Sprint-Ziel

152

* Schätzen von Aufwänden

* Product Backlog

* Velocity

== Schätzen von Aufwänden ==

157

158

Es sollte aus mehreren Gründen geschätzt werden (in GitLab: [[Schätzung>>doc:Main.GitLab.WebHome||anchor="HSchE4tzungen"]]). 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". Die Schätzung kann bspw. auf der Seite: [[https:~~/~~/www.scrumpoker-online.org/en/>>url:https://www.scrumpoker-online.org/en/]] durchgeführt werden.

159

160

161

**Neu (02.03.2026)**: Als Betaversion gibt es nun [[image:1772434669364-397.png]] Damit ist das Schätzen deutlich besser in Gitlab integriert. Es sollte in allen Projekten rechts oben zu finden sein. Die URL ist [[https:~~/~~/pp.swl.informatik.uni-oldenburg.de/>>https://pp.swl.informatik.uni-oldenburg.de/]] und man logged sich mit seinen Nutzerdaten aus Gitlab ein.

162

163

164

=== **Ablauf der Aufwandsschätzung (Checkliste)** ===

165

166

✓ Auf eine Werteskala einigen (Fibonacci oder T-Shirt Größen) (siehe Abschnitt "Vorschlag für eine Werteskala zum Schätzen")

167

✓ Auf eine Schätzmethode einigen (siehe Abschnitt "Der Ablauf vom Planningpoker")

168

✓ Eine Referenzstory bestimmen, anhand dessen geschätzt werden soll

169

✓ Definition of Done bei der Schätzung mit einbeziehen

170

✓ Geschätzte Story Points den jeweiligen Stories hinzufügen

171

172

=== **Der Ablauf vom Planningpoker** ===

173

174

* Jedes Teammitglied hat einen Satz Karten, auf dem eine zuvor bestimmte Werteskala abgebildet ist (online abwandelbar, siehe Abschnitt "Tools, um online zu schätzen")

175

* Stories werden vorgestellt

176

* Es dürfen Fragen zu den Stories gestellt werden, falls etwas unklar ist

177

* Danach legt jedes Teammitglied eine Karte mit einem Wert verdeckt auf den Tisch

178

* Hat jede Person eine Karte abgelegt, werden diese umgedreht

179

* Ziel: Team einigt sich auf einen Wert

180

* Weichen die Werte auf den Karten stark voneinander ab, besteht offenbar Diskussionsbedarf

181

* 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

182

183

=== **Vorschlag für eine Werteskala zum Schätzen** ===

184

185

* Nur wenige Zahlen auswählen (bspw. 1,2,3,5,8)

186

* 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

187

188

[[image:tshirtfibo.JPG]]

189

190

=== **Definition eines Velocity Charts** ===

191

192

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

193

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.

[[image:velo.JPG]]

=== **Definition eines Burndown Charts** ===

198

199

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.

[[image:burnd.JPG]]

== 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?

210

1. Was werde ich heute tun?

211

1. Gibt es Hindernisse, die mir im Weg stehen?

212

213

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.

214

215

== Definition of Done/Definition of Ready ==

216

217

=== **Definition of Done** ===

218

219

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.

220

221

==== **Nutzen einer Definition of Done** ====

222

223

* Wenn keine Definition of Done vorhanden ist, kann es schnell zu einem Impediment führen, da kein klares Ende einer Story in Sicht ist

224

* Jedes Teammitglied ist dazu verpflichtet, diese Definition of Done einzuhalten

225

* 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

226

* Sollte direkt am Anfang erstellt werden, damit das Team sich dahingehend weiterentwickeln und lernen kann

227

228

=== **Definition of Ready** ===

229

230

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.

231

232

=== **Unterschiede zwischen Definition of Done und Definition of Ready** ===

233

234

* Definition of Done beschreibt, wann eine User Story fertig bearbeitet wurde

235

* Definition of Ready beschreibt, wann eine User Story fertig beschrieben wurde

== Sprint Review ==

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.

240

241

=== **Mehrwert eines Reviews** ===

242

243

* Dient dazu, allen Teammitgliedern zu zeigen, was in dem Sprint bearbeitet wurde

244

* Alle Teammitglieder bleiben auf dem neuesten Stand

245

* Es kann dadurch verhindert werden, dass Teammitglieder abgehängt werden, sollte deshalb regelmäßig durchgeführt werden

246

* 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

247

248

== Sprint Retrospektive ==

249

250

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

251

252

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]]

253

254

[[image:Unbenannt2.JPG]]

255

256

=== Hilfreiche Tools für die Durchführung einer Sprint Retrospektive ===

257

258

[[Retrotool.io>>https://retrotool.io/]]

259

260

* Auf der Startseite auf "Create free, anonymous retro" klicken.

261

* Das gewünschte Template auswählen, bspw. Mad, Sad, Glad und auf "Create Retro" klicken.

262

* Anschließend kann das Team per Link eingeladen werden.

263

* Wenn alle Teilnehmer anwesend sind, kann die Stoppuhr gestartet werden und jeder Teilnehmer hat eine bestimmte Zeit zur Formulierung von Notizen.

264

* Die Notizen werden in der "Private Section" verfasst. Diese sind anonym und werden erst durch das ziehen per "Drag and Drop", in den gewünschten Bereich, öffentlich.

265

* Sollte die Zeit abgelaufen oder jeder Teilnehmer fertig, werden Action Points formuliert. Dies sind Verbesserungen für die erkannten Probleme.

266

* Abschließend sollten die Ergebnisse dokumentiert und in dem nächsten Sprint überprüft werden.

267

268

[[Codigy>>https://codi.gy/]] (nicht anonym)

269

270

[[Collaboard>>https://whiteboard.academiccloud.de/]] (zunächst muss eine Anmeldung bei der [[Academic Cloud>>https://academiccloud.de/de/]] mit den Universitätsdaten erfolgen)

271

272

[[Miro>>https://miro.com/de/]]

= User Stories =

== Was sind User Stories? ==

277

278

Ein Werkzeug, das häufig im agilen Projektmanagement eingesetzt wird, sind User Stories. Eine User Story ist eine Beschreibung einer Anforderung an ein Softwareprodukt. Sie ist aus der Sicht eines Nutzers //(hier: Spielteilnehmer)// formuliert. Außerdem wird in einer User Story immer ein Mehrwert und eine Bedeutung für den Nutzer erwähnt, welchen dieser durch die Funktionalität hat. Diese Funktionalität wird in das zu erstellende Produkt implementiert und erhöht somit den Wert des Produkts. Eine User Story liefert also immer einen Mehrwert. Der Titel der User Story beschreibt knapp die Hauptaussage der gesamten Story, welche immer das Ziel des Nutzers ist. In den meisten Fällen wird eine User Story in der folgenden Form geschrieben:

279

280

"Als [Rolle] möchte ich [Tätigkeit], um [Nutzen]."

281

282

Im Rahmen des Softwareprojekts könnte eine User Story beispielsweise wie folgt aussehen: //"Als Nutzer dieses Systems möchte ich mich einloggen können, um ein Spiel zu starten."// Die explizite Erwähnung der [Rolle] ist wichtig, weil der Anwendungsfall von Rolle zu Rolle variieren kann. Die [Tätigkeit] ist der Vorgang, welchen die Rolle bei Nutzung des vom Team zu implementierenden Produkts ausführt. Der [Nutzen] dient zur Einordnung der Wichtigkeit und hilft, eine Priorisierung der zu implementierenden Features vorzunehmen. Außerdem hilft es dem Team zu verstehen, warum sie dieses Feature implementieren sollen.

283

284

== Mehrwert von User Stories ==

285

286

Da User Stories so formuliert werden sollten, dass sie jeder versteht, kann eine intensive Zusammenarbeit mit dem Auftraggeber //(hier: intensive Zusammenarbeit mit dem gesamten Team)// entstehen. Hierdurch wird die Beziehung untereinander gestärkt und sowohl Entwickler als auch Auftraggeber verstehen die Ziele der User Stories gleicherma- ßen. Ein weiterer Vorteil ist die Anpassbarkeit, weil sich die Wünsche des Auftraggebers jederzeit ändern können. Aus diesem Grund implementieren die Entwickler im schlimmsten Fall nur für eine sehr kurze Zeit etwas, was in der nächsten Iteration hinfällig ist, da sich der Wunsch des Auftraggebers jederzeit ändern kann. Außerdem werden nur die Stories detaillierter beschrieben, die in der Iteration erledigt werden sollen. So wird keine Zeit für die Planung von etwas aufgewendet, das sich im Nachhinein eventuell als obsolet herausstellt.

287

288

== Der Nutzen von Akzeptanzkriterien ==

289

290

Da die Entwickler eventuell unterschiedliche Vorstellungen davon haben, wann eine bestimmte User Story fertig bearbeitet ist, hat sie bestimmte Akzeptanzkriterien. Diese bestimmen die Vollständigkeit der in der Story gewünschten Funktion. Sobald diese Akzeptanzkriterien erfüllt sind, ist die User Story vollständig umgesetzt und liefert nur dann den gewünschten Mehrwert für den Auftraggeber //(hier: für das Team)//.

== INVEST-Prinzip ==

Es gibt bestimmte Eigenschaften, die eine gute User Story ausmachen. Mit dem INVEST-Prinzip lassen sich diese Eigenschaften beschreiben. Dabei ist das Wort INVEST ein Akronym für die folgenden Eigenschaften einer guten User Story:

295

296

**Independent** Diese Eigenschaft meint, dass eine gute User Story unabhängig von anderen ist. Sind Stories voneinander abhängig, können Probleme entstehen, die eine Priorisierung erschweren.

297

298

**Negotiable** Verhandelbare User Stories bedeuten, dass während des Entwicklungsprozesses bestimmte Akzeptanzkriterien angepasst werden können, wenn diese mit dem Auftraggeber //(hier: mit dem gesamten Team)// verhandelt wurden.

299

300

**Valuable** Wertvolle User Stories meinen, dass sie einen bestimmten Mehrwert für den Auftraggeber und den Nutzer darstellen.

301

302

**Estimatable** Eine gute User Story soll schätzbar sein, das bedeutet, dass die Story von anderen abgegrenzt wird, sodass sie gut unterscheidbar ist.

303

304

**Small** Damit eine User Story gut schätzbar ist, muss sie klein sein. Außerdem können zu große User Stories nicht in einem Sprint bearbeitet werden.

305

306

**Testable** Eine testbare User Story hat gut strukturierte Akzeptanzkriterien, die getestet werden können.

307

308

=== Ausreichend beschriebene User Story mit dem INVEST-Prinzip ===

309

310

[[image:Unbenannt.JPG]]

311

312

=== Unzureichend beschriebene User Story mit dem INVEST-Prinzip ===

313

314

[[image:Unbenannt1.JPG]]

= Scrum Workshop =

Im Winter 2020/21 wurde zum ersten Mal mit den Scrum-Mastern ein Scrum Workshop durchgeführt. Die dort verwendeten Materialen sind unter dem folgenden Link zu finden:

319

320

[[https:~~/~~/cloud.uni-oldenburg.de/s/XKi2PiW4H5yazzW>>url:https://cloud.uni-oldenburg.de/s/XKi2PiW4H5yazzW]]

321

322

Die Quelldateien sind unter

323

324

[[https:~~/~~/git.swl.informatik.uni-oldenburg.de/projects/SPB/repos/scrumworkshop/browse>>url:https://git.swl.informatik.uni-oldenburg.de/projects/SPB/repos/scrumworkshop/browse]]

zu finden.

Ich würde mich über einen kurzen Hinweis darüber, dass die Materialien woanders verwendet worden sind, freuen. Änderungsvorschläge gerne per PR im Git-Projekt (Zugangsdaten können ggf. bei [[Marco Grawunder>>https://uol.de/marco-grawunder]] angefordert werden).

329

330

331

[[FEHLERTEST>>http://www.marcograwunder.de/]]

332

Wiki source code of Scrum