Skip to Content

Changes for page Scrum

Last modified by pmeyer on 2025/09/12 04:57
From version arrow_back 9.1 arrow_forward
edited by Pascal Meyer
on 2025/07/30 17:42
Change comment: Uploaded new attachment "Unbenannt.JPG", version {1}
To version arrow_back 9.2 arrow_forward
edited by Pascal Meyer
on 2025/07/30 17:42
Change comment: There is no comment for this version

Summary

Details

insert_drive_file Page properties
Content
... ... @@ -67,7 +67,7 @@
67 67  *** Das gesamte Team kommt zusammen und diskutiert, wie es sich verbessern möchte
68 68  *** Methode hierfür bspw: Starfish (siehe Bild)
69 69  *** Weitere Methoden für die Retrospektiven finden sich z.B. hier: [[https:~~/~~/retromat.org/>>url:https://retromat.org/]]
70 -** **Tägliches Scrum-Meeting (Daily)​​​​​​​​​**
70 +** **Tägliches Scrum-Meeting (Daily)​​**
71 71  *** Wöchentliches Treffen startet mit Scrum-Meeting
72 72  *** Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
73 73  *** Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren
... ... @@ -240,4 +240,81 @@
240 240  
241 241  
242 242  
243 -
243 += User-Stories =
244 +
245 +== Was sind User Stories? ==
246 +
247 +Ein Werkzeug, das häufig im agilen Projektmanagement eingesetzt wird, sind User
248 +Stories. Eine User Story ist eine Beschreibung einer Anforderung an ein Softwareprodukt.
249 +Sie ist aus der Sicht eines Nutzers //(hier: Spielteilnehmer)// formuliert. Außerdem
250 +wird in einer User Story immer ein Mehrwert und eine Bedeutung für den Nutzer
251 +erwähnt, welchen dieser durch die Funktionalität hat. Diese Funktionalität wird in
252 +das zu erstellende Produkt implementiert und erhöht somit den Wert des Produkts.
253 +Eine User Story liefert also immer einen Mehrwert. Der Titel der User Story beschreibt
254 +knapp die Hauptaussage der gesamten Story, welche immer das Ziel des Nutzers ist. In
255 +den meisten Fällen wird eine User Story in der folgenden Form geschrieben:
256 +
257 +
258 +"Als [Rolle] möchte ich [Tätigkeit], um [Nutzen]."
259 +
260 +
261 +Im Rahmen des Softwareprojekts könnte eine User Story beispielsweise wie folgt aussehen:
262 +//"Als Nutzer dieses Systems möchte ich mich einloggen können, um ein Spiel zu//
263 +//starten."// Die explizite Erwähnung der [Rolle] ist wichtig, weil der Anwendungsfall von
264 +Rolle zu Rolle variieren kann. Die [Tätigkeit] ist der Vorgang, welchen die Rolle bei
265 +Nutzung des vom Team zu implementierenden Produkts ausführt. Der [Nutzen] dient
266 +zur Einordnung der Wichtigkeit und hilft, eine Priorisierung der zu implementierenden
267 +Features vorzunehmen. Außerdem hilft es dem Team zu verstehen, warum sie dieses
268 +Feature implementieren sollen.
269 +
270 +== Mehrwert von User Stories ==
271 +
272 +Da User Stories so formuliert werden sollten, dass sie jeder versteht, kann eine intensive
273 +Zusammenarbeit mit dem Auftraggeber //(hier: intensive Zusammenarbeit mit dem//
274 +//gesamten Team)// entstehen. Hierdurch wird die Beziehung untereinander gestärkt und
275 +sowohl Entwickler als auch Auftraggeber verstehen die Ziele der User Stories gleicherma-
276 +ßen. Ein weiterer Vorteil ist die Anpassbarkeit, weil sich die Wünsche des Auftraggebers
277 +jederzeit ändern können. Aus diesem Grund implementieren die Entwickler im schlimmsten
278 +Fall nur für eine sehr kurze Zeit etwas, was in der nächsten Iteration hinfällig ist,
279 +da sich der Wunsch des Auftraggebers jederzeit ändern kann. Außerdem werden nur
280 +die Stories detaillierter beschrieben, die in der Iteration erledigt werden sollen. So wird
281 +keine Zeit für die Planung von etwas aufgewendet, das sich im Nachhinein eventuell als
282 +obsolet herausstellt.
283 +
284 +== Der Nutzen von Akzeptanzkriterien ==
285 +
286 +Da die Entwickler eventuell unterschiedliche Vorstellungen davon haben, wann eine
287 +bestimmte User Story fertig bearbeitet ist, hat sie bestimmte Akzeptanzkriterien. Diese
288 +bestimmen die Vollständigkeit der in der Story gewünschten Funktion. Sobald diese
289 +Akzeptanzkriterien erfüllt sind, ist die User Story vollständig umgesetzt und liefert nur
290 +dann den gewünschten Mehrwert für den Auftraggeber //(hier: für das Team)//.
291 +
292 +== INVEST-Prinzip ==
293 +
294 +Es gibt bestimmte Eigenschaften, die eine gute User Story ausmachen. Mit dem INVEST-
295 +Prinzip lassen sich diese Eigenschaften beschreiben. Dabei ist das Wort INVEST ein
296 +Akronym für die folgenden Eigenschaften einer guten User Story:
297 +
298 +**Independent** Diese Eigenschaft meint, dass eine gute User Story unabhängig von
299 +anderen ist. Sind Stories voneinander abhängig, können Probleme entstehen, die eine
300 +Priorisierung erschweren.
301 +
302 +**Negotiable** Verhandelbare User Stories bedeuten, dass während des Entwicklungsprozesses
303 +bestimmte Akzeptanzkriterien angepasst werden können, wenn diese mit dem
304 +Auftraggeber //(hier: mit dem gesamten Team)// verhandelt wurden.
305 +
306 +**Valuable** Wertvolle User Stories meinen, dass sie einen bestimmten Mehrwert für
307 +den Auftraggeber und den Nutzer darstellen.
308 +
309 +**Estimatable** Eine gute User Story soll schätzbar sein, das bedeutet, dass die Story
310 +von anderen abgegrenzt wird, sodass sie gut unterscheidbar ist.
311 +
312 +**Small** Damit eine User Story gut schätzbar ist, muss sie klein sein. Außerdem können
313 +zu große User Stories nicht in einem Sprint bearbeitet werden.
314 +
315 +**Testable** Eine testbare User Story hat gut strukturierte Akzeptanzkriterien, die
316 +getestet werden können.
317 +
318 +=== Ausreichend beschriebene User Story mit dem INVEST-Prinzip ===
319 +
320 +[[image:Unbenannt.JPG]]​​​​​​​