Skip to Content

Changes for page Scrum

Last modified by pmeyer on 2025/09/12 04:57
From version arrow_back 6.3 arrow_forward
edited by Pascal Meyer
on 2025/07/29 03:53
Change comment: There is no comment for this version
To version arrow_back 3.1 arrow_forward
edited by Pascal Meyer
on 2025/07/29 03:50
Change comment: Uploaded new attachment "velo.JPG", version {1}

Summary

Details

insert_drive_file Page properties
Content
... ... @@ -54,7 +54,7 @@
54 54  **** Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
55 55  **** Wichtig! Wird gerne unterschätzt
56 56  **** Hilft, das Ziel im Auge zu behalten
57 -** **Sprint Review**
57 +** **Sprint Review​​​​​​​**
58 58  *** Das Team präsentiert, was es während eines Sprints erreicht hat
59 59  *** Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur
60 60  *** Das ganze Team nimmt teil!
... ... @@ -85,19 +85,33 @@
85 85  *** Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)
86 86  *** Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird
87 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]])
88 -** **Produktinkrement**
88 +** **Produktinkrement**​​​​​​​
89 89  
90 -**[[image:Scrum-Prozess.JPG]]**
90 += Scrum im Detail =
91 91  
92 -= Scrum - im Detail =
93 -
94 94  == Scrum-Prozess ==
95 95  
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.
94 +Nachdem die Produktvision definiert wurde, wird das Product Backlog erstellt und vom
95 +Product Owner //(hier: gesamtes Team im Softwareprojekt)// verwaltet. Aus dem Sprint
96 +Planning resultiert das Sprint Backlog, welches im Sprint durch das Entwicklungsteam
97 +//(hier: Scrum Master gehört zum Entwicklungsteam und programmiert mit)// abgearbeitet
98 +wird. Der Scrum Master sorgt dafür, dass das Entwicklungsteam ungestört arbeiten
99 +kann. Täglich //(hier: wöchentlich)// trifft er sich im Daily Scrum mit dem Team. Nach
100 +dem Sprint wird ein Produktinkrement an den Auftraggeber //(hier: an das gesamte//
101 +//Team)// ausgeliefert und in einem Sprint Review näher erläutert. Anschließend wird eine
102 +Sprint Retrospektive durchgeführt, in der das Team die Zusammenarbeit reflektieren kann.
97 97  
98 98  == Product Backlog ==
99 99  
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.
106 +Ein Product Backlog ist eine priorisierte Anforderungsliste für das von dem Auftraggeber
107 +gewünschte Softwareprodukt. Diese ist nie vollständig und zu jederzeit anpassbar. Der
108 +Product Owner //(hier: das gesamte Team)// ergänzt das Backlog stetig und hat in den
109 +meisten Fällen bereits User Stories für den nächsten Sprint geplant. Aus diesem Grund
110 +sind in dem Backlog nicht alle für das komplette Produkt relevanten Anforderungen
111 +zu finden, weil sich von Sprint zu Sprint immer wieder neue Anforderungen ergeben
112 +oder alte verworfen werden. Es ist auch möglich, dass sich die Prioritäten ändern. Der
113 +Product Owner //(hier: das gesamte Team)// verwaltet das Backlog, allerdings muss es für
114 +alle Mitglieder des Scrum Teams ersichtlich sein.
101 101  
102 102  === **Der Nutzen eines gepflegten/priorisierten Product Backlogs** ===
103 103  
... ... @@ -119,7 +119,11 @@
119 119  
120 120  == Sprint Planning ==
121 121  
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.
136 +Nachdem das Product Backlog initial gefüllt und das Sprint-Ziel festgelegt wurde, kann
137 +das Planning beginnen. Das Sprint Planning ist wichtig, weil der Product Owner und
138 +das Entwicklungsteam //(hier: das gesamte Team)// sich so einig über die zu bearbeitenden
139 +User Stories werden können. In diesem Meeting wird gemeinsam mit dem Team, dem
140 +Scrum Master und dem Product Owner der Sprint vorbereitet.
123 123  
124 124  === **Ablauf eines Plannings (Checkliste)** ===
125 125  
... ... @@ -142,7 +142,15 @@
142 142  
143 143  == Schätzen von Aufwänden ==
144 144  
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".
163 +Es sollte aus mehreren Gründen geschätzt werden. Zum einen bekommen alle Teammitglieder
164 +einen Einblick in den Inhalt aller User Stories, bevor angefangen wird, sie
165 +umzusetzen. Dies schärft das Verständnis für das Produkt. Zum anderen findet das
166 +Schätzen im besten Fall mit dem gesamten Team statt, wodurch dieses Meeting eine
167 +teamgeistfördernde Aktivität ist. Ein weiterer Vorteil ist, dass jede Person im Team weiß,
168 +worum es in der Story geht, sodass jede Person jede Aufgabe bearbeiten kann. Außerdem
169 +können so in Diskussionen Probleme oder zusätzliche Informationen identifiziert werden,
170 +wenn eine User Story beispielsweise in kleinere sinnvolle Einheiten aufgeteilt werden
171 +kann. Die Einheit, in der zumeist geschätzt wird, nennt sich "Story Points".
146 146  
147 147  === **Ablauf der Aufwandsschätzung (Checkliste)** ===
148 148  
... ... @@ -168,25 +168,42 @@
168 168  * Nur wenige Zahlen auswählen (bspw. 1,2,3,5,8)
169 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 170  
171 -[[image:tshirtfibo.JPG]]
197 +[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/78f387122adf2a44d3b92efa743d3446/tshirtfibo.JPG~|~|alt="tshirtfibo.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/78f387122adf2a44d3b92efa743d3446/tshirtfibo.JPG]]
172 172  
173 173  === **Definition eines Velocity Charts** ===
174 174  
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.
201 +Hat das Team schon mindestens einen Sprint hinter sich, kann der nächste Sprint auf
202 +Basis der Velocity aufgebaut werden. Die Velocity steht für die Geschwindigkeit des
203 +Teams. Das bedeutet, dass ermittelt wird, wie viele Story Points das Entwicklungsteam
204 +in dem vorherigen Sprint geschafft hat. Aufgrund dieser Information kann der darauf
205 +folgende Sprint genauer geplant werden, indem sich das Team nur auf die Anzahl der
206 +vorher erledigten Story Points committet. Die Abbildung zeigt ein solches Velocity Chart.
207 +Die x-Achse zeigt die bisherige Anzahl an Sprints und die y-Achse die Story Points, die
208 +in einem Sprint erledigt wurden. Es ist zu sehen, dass beispielsweise im zweiten Sprint
209 +15 Story Points geschafft wurden, jedoch im dritten Sprint nur fünf. Ab dem dritten
210 +Sprint kann eine Verbesserung der Geschwindigkeit des Teams wahrgenommen werden.
177 177  
178 -[[image:velo.JPG]]
212 +[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/3bb28351d712bbf3e9ad6360fd85bc6a/velo.JPG~|~|alt="velo.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/3bb28351d712bbf3e9ad6360fd85bc6a/velo.JPG]]
179 179  
180 180  === **Definition eines Burndown Charts** ===
181 181  
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.
216 +Eine Möglichkeit zur Überprüfung des Fortschritts während eines Sprints ist die Erstellung
217 +eines Burndown Charts. Es zeigt die bereits erledigten Story Points auf Basis
218 +der verbleibenden Zeit an. Somit kann schnell gesehen werden, ob Verzögerungen oder
219 +Probleme auftreten und falls dies der Fall ist, kann ein Meeting einberufen werden,
220 +damit über die Probleme gesprochen wird. Die Abbildung zeigt ein
221 +Burndown Chart. Auf der x-Achse sind die Arbeitstage zu sehen und auf der y-Achse
222 +die noch zu erledigenden Story Points für den Sprint. Es ist zu sehen, dass das Team
223 +bisher einen guten Fortschritt hat, weil der Graph bisher stetig abfällt.
183 183  
184 -[[image:burnd.JPG]]
225 +[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/a5dbbbeddb36c2545d5748bfef5124c2/burnd.JPG~|~|alt="burnd.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/a5dbbbeddb36c2545d5748bfef5124c2/burnd.JPG]]
185 185  
186 186  == Daily Scrum ==
187 187  
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 -
229 +Täglich //(hier: wöchentlich)// treffen sich das Entwicklungsteam und der Scrum Master
230 +zu einem Meeting. Es ist ein sehr kurzes Treffen, welches immer zur gleichen Zeit am
231 +gleichen Ort stehend stattfindet. Zumeist stehend, damit es bewusst kurz gehalten wird.
232 +Das Treffen sollte nicht länger als 15 Minuten dauern. Jedes Teammitglied beantwortet
190 190  drei Fragen:
191 191  
192 192  1. Was habe ich gestern gemacht?
... ... @@ -193,7 +193,12 @@
193 193  1. Was werde ich heute tun?
194 194  1. Gibt es Hindernisse, die mir im Weg stehen?
195 195  
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
239 +Durch das Daily Scrum werden Probleme sichtbar, die für den Scrum Master von großer
240 +Bedeutung sind, da er hierdurch eventuelle Impediments wahrnehmen und anschließend
241 +beseitigen kann. Außerdem ist dieses Treffen für das Team wichtig, um sich gegenseitig
242 +zu informieren und nach eventuell benötigter Hilfe zu suchen. Damit dieses Treffen
243 +möglichst effektiv ist, sollten sich die Teammitglieder darauf vorbereiten und vorher
244 +überlegen, was gestern bearbeitet wurde und was heute erledigt wird. Der Scrum
197 197  Master sorgt in diesem Meeting dafür, dass die anderen Teammitglieder nicht den Fokus
198 198  verlieren. Außerdem achtet er auf die Zeit, sodass diese eingehalten wird.
199 199  
... ... @@ -236,7 +236,7 @@
236 236  
237 237  == Sprint Review ==
238 238  
239 -Am Ende eines Sprints findet das Sprint Review statt. Bei diesem Treffen werden
287 +Am Ende eines Sprints findet das Sprint Review statt (siehe [[Sprint-Review mit Jira>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/691404828/Sprint-Review+mit+Jira]]). Bei diesem Treffen werden
240 240  die Sprint-Ergebnisse allen Interessierten präsentiert. Dazu gehören beispielsweise der
241 241  Auftraggeber oder andere Stakeholder //(hier: mit dem gesamten Team und ggf. dem//
242 242  //Tutor)//. Der Scrum Master bereitet dieses Meeting vor, indem er die Interessenten über
... ... @@ -264,10 +264,8 @@
264 264  
265 265  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]]
266 266  
267 -[[image:Unbenannt2.JPG]]
315 +Video zur Sprintretrospektive und die Verwendung in Jira [[1080p>>url:https://swl.informatik.uni-oldenburg.de/swp/video/Jira/Sprint-Retrospektive.mp4]]
268 268  
269 -
317 +[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG~|~|alt="Unbenannt2.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG]]
270 270  
271 271  
272 -
273 -
attach_file Scrum-Prozess.JPG
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -59.4 KB
Content info
attach_file Unbenannt2.JPG
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -60.7 KB
Content info
attach_file burnd.JPG
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -21.3 KB
Content info