Skip to Content

Changes for page Scrum

Last modified by pmeyer on 2025/09/12 04:57
From version arrow_back 10.1 arrow_forward
edited by Pascal Meyer
on 2025/07/30 17:43
Change comment: Uploaded new attachment "Unbenannt1.JPG", version {1}
To 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}

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,81 +240,4 @@
240 240  
241 241  
242 242  
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]]​​​​​​​
243 +
attach_file Unbenannt1.JPG
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.PascalMeyer
Size
... ... @@ -1,1 +1,0 @@
1 -163.8 KB
Content info