Changes for page Scrum

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

arrow_back From 4.1 to 3.2 From 9.2 to 9.1 arrow_forward

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

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

Change comment: Uploaded new attachment "burnd.JPG", version {1}

Raw
Rendered

Summary

insert_drive_file Page properties (1 modified, 0 added, 0 removed)
attach_file Attachments (0 modified, 0 added, 3 removed)
- attach_file Scrum-Prozess.JPG
- attach_file Unbenannt.JPG
- attach_file Unbenannt2.JPG

Details

insert_drive_file Page properties

Content

@@ -1,5 +3,3 @@
--{{toc/}}
--
  = Scrum - Ein kurzer Überblick =
  **Was ist Scrum und warum brauchen wir das im SWP?**
@@ -60,7 +60,7 @@
  *** Das Team präsentiert, was es während eines Sprints erreicht hat
  *** Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur
  *** Das ganze Team nimmt teil!
--** **Sprint Retrospektive**
++** **Sprint Retrospektive**
  *** Regelmäßig prüfen, was gut und was nicht so gut funktioniert
  *** ca. 15-30 min lang
  *** Nach jedem Sprint
@@ -89,17 +89,31 @@
  *** 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]])
  ** **Produktinkrement**
--**[[image:Scrum-Prozess.JPG]]**
--
  = Scrum - im Detail =
  == Scrum-Prozess ==
--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.
++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.
  == Product Backlog ==
--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.
++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.
  === **Der Nutzen eines gepflegten/priorisierten Product Backlogs** ===
@@ -121,7 +121,11 @@
  == Sprint Planning ==
--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.
++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.
  === **Ablauf eines Plannings (Checkliste)** ===
@@ -144,7 +144,15 @@
  == Schätzen von Aufwänden ==
--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".
++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".
  === **Ablauf der Aufwandsschätzung (Checkliste)** ===
@@ -174,21 +174,38 @@
  === **Definition eines Velocity Charts** ===
--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
--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.
++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
++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** ===
--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.
++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
--
++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:
 . Was habe ich gestern gemacht?
@@ -195,13 +195,27 @@
 . Was werde ich heute tun?
 . Gibt es Hindernisse, die mir im Weg stehen?
--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.
++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.
  == Definition of Done/Definition of Ready ==
  === **Definition of Done** ===
--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.
++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.
  ==== **Nutzen einer Definition of Done** ====
@@ -212,7 +212,15 @@
  === **Definition of Ready** ===
--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.
++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.
  === **Unterschiede zwischen Definition of Done und Definition of Ready** ===
@@ -221,7 +221,15 @@
  == 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.
++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
++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.
  === **Mehrwert eines Reviews** ===
@@ -232,12 +232,17 @@
  == Sprint Retrospektive ==
--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
++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
  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]]
--[[image:Unbenannt2.JPG]]
++Video zur Sprintretrospektive und die Verwendung in Jira [[1080p>>url:https://swl.informatik.uni-oldenburg.de/swp/video/Jira/Sprint-Retrospektive.mp4]]
++[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG~|~|alt="Unbenannt2.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG]]
--

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 Unbenannt.JPG

Author

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

Size

...	...	@@ -1,1 +1,0 @@
1		-178.6 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

Changes for page Scrum

Summary

Details

Applications

Navigation