Changes for page Scrum

Last modified by pmeyer on 2025/09/12 04:57

arrow_back From 8.1 to 7.1 From 11.1 to 10.1 arrow_forward

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 8.1 arrow_forward

edited by Pascal Meyer
on 2025/07/29 03:54

Change comment: There is no comment for this version

Raw
Rendered

Summary

insert_drive_file Page properties (1 modified, 0 added, 0 removed)
attach_file Attachments (0 modified, 0 added, 2 removed)
- attach_file Unbenannt.JPG
- attach_file Unbenannt1.JPG

Details

insert_drive_file Page properties

Content

@@ -67,7 +67,7 @@
  *** Das gesamte Team kommt zusammen und diskutiert, wie es sich verbessern möchte
  *** Methode hierfür bspw: Starfish (siehe Bild)
  *** Weitere Methoden für die Retrospektiven finden sich z.B. hier: [[https:~~/~~/retromat.org/>>url:https://retromat.org/]]
--** **Tägliches Scrum-Meeting (Daily)**
++** **Tägliches Scrum-Meeting (Daily)**
  *** Wöchentliches Treffen startet mit Scrum-Meeting
  *** Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
  *** Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren
@@ -240,81 +240,4 @@
--= User-Stories =
--
--== Was sind User Stories? ==
--
--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:
--
--
--"Als [Rolle] möchte ich [Tätigkeit], um [Nutzen]."
--
--
--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.
--
--== Mehrwert von User Stories ==
--
--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.
--
--== Der Nutzen von Akzeptanzkriterien ==
--
--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:
--
--**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.
--
--**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.
--
--**Valuable** Wertvolle User Stories meinen, dass sie einen bestimmten Mehrwert für
--den Auftraggeber und den Nutzer darstellen.
--
--**Estimatable** Eine gute User Story soll schätzbar sein, das bedeutet, dass die Story
--von anderen abgegrenzt wird, sodass sie gut unterscheidbar ist.
--
--**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.
--
--**Testable** Eine testbare User Story hat gut strukturierte Akzeptanzkriterien, die
--getestet werden können.
--
--=== Ausreichend beschriebene User Story mit dem INVEST-Prinzip ===
--
--[[image:Unbenannt.JPG]]
++

attach_file Unbenannt.JPG

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.PascalMeyer

Size

...	...	@@ -1,1 +1,0 @@
1		-178.6 KB

Content info

attach_file Unbenannt1.JPG