Changes for page Scrum

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

arrow_back From 1.1 to 1.2 From 1.7 to 1.8 arrow_forward

From version arrow_back 1.2 arrow_forward

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

Change comment: There is no comment for this version

To version arrow_back 1.7 arrow_forward

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

Change comment: There is no comment for this version

Raw
Rendered

Summary

insert_drive_file Page properties (1 modified, 0 added, 0 removed)

Details

insert_drive_file Page properties

Content

@@ -1,6 +1,6 @@
--= Scrum - Überblick =
++= Scrum - Ein kurzer Überblick =
--**Was ist Scrum und warum brauchen wir das im SWP?**
++**Was ist Scrum und warum brauchen wir das im SWP?**
  * Scrum ist einer von mehreren agilen Projektmanagement-Ansätzen und insbesondere für die Softwareentwicklung geeignet
  * Wird benötigt, um die Entwicklung des im SWP geforderten Produkts im Rahmen eines vernünftig strukturierten Projektmanagements umzusetzen
@@ -17,20 +17,372 @@
  * Anforderungen sind als Listeneinträge im Product Backlog festgehalten (Hinweis: Das Backlog kann mehr als nur die Anforderungen enthalten, d.h. nicht jeder Eintrag im Backlog entspricht einer Anforderung.)
  * Im SWP "kleine iterative Wasserfälle" → Anforderung, Design, Kodierung, Test
--**Rahmenbedingungen:**
++**Rahmen:**
--* Rollen
--** Product Owner
--** Scrum Master
--** Entwicklungs-Team
--* Meetings
--** Sprint Planning
--** Sprint Review
++* **Rollen**
++** **Product Owner**
++*** Definiert Product-Features
++*** Bestimmt Auslieferungsdatum und Inhalt
++*** Akzeptiert oder weist Arbeitsergebnisse zurück
++*** Im SWP der Tutor in Absprache mit Marco und das Team
++** **Scrum Master**
++*** Repräsentiert das Management gegenüber dem Projekt
++*** Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken
++*** Beseitigt Hindernisse
++*** Stellt sicher, dass das Team vollständig, funktional und produktiv ist
++*** Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen
++*** Schützt das Team vor äußeren Störungen
++*** Im SWP ein spezielles Mitglied der Gruppe, welches trotzdem auch mitentwickelt
++** **Entwicklungs-Team**
++*** Typischerweise 5-9 Personen
++*** Funktionsübergreifend
++**** QS, Programmierer, UI-Designer, etc.
++*** Mitglieder sollen Vollzeitmitglieder sein
++*** Teams organisieren sich selbst
++*** Mitgliedschaft kann nur zwischen Sprints verändert werden
++* **Meetings**
++** **Sprint Planning**
++*** Sprint Priorisierung
++**** Product Backlog analysieren und auswerten
++**** Sprint-Ziel festlegen
++*** Planung
++**** Entscheiden, wie man das Sprint-Ziel erreichen kann (Design)
++**** Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen
++***** Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus
++*** Sprint Backlog schätzen (Planning Poker, Magic Estimation, etc.)
++*** Sprint-Ziel
++**** Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
++**** Wichtig! Wird gerne unterschätzt
++**** Hilft, das Ziel im Auge zu behalten
++** **Sprint Review**
  ** Sprint Retrospektive
  ** Tägliches Scrum-Meeting (Daily)
--* Artefakte
++* **Artefakte**
  ** Product Backlog
  ** Sprint Backlog
  ** Produktinkrement
--= S =
++=== **Rollen** ===
++
++Product Owner:
++
++* Definiert Product-Features
++* Bestimmt Auslieferungsdatum und Inhalt
++* Akzeptiert oder weist Arbeitsergebnisse zurück
++* Im SWP der Tutor in Absprache mit Marco und das Team
++
++Scrum Master:
++
++* Repräsentiert das Management gegenüber dem Projekt
++* Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken
++* Beseitigt Hindernisse
++* Stellt sicher, dass das Team vollständig, funktional und produktiv ist
++* Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen
++* Schützt das Team vor äußeren Störungen
++
++           → Im SWP ein spezielles Mitglied der Gruppe
++
++           → Soll trotzdem auch mit entwickeln
++
++Entwicklungs-Team:
++
++* Typischerweise 5-9 Personen
++* Funktionsübergreifend
++** QS, Programmierer, UI-Designer, etc.
++* Mitglieder sollen Vollzeitmitglieder sein
++* Teams organisieren sich selbst
++* Mitgliedschaft kann nur zwischen Sprints verändert werden
++
++           → Es kann helfen, einen Projektleiter zu bestimmen (ist nicht Scrum-Konform, aber im SWP kann es hilfreich sein)
++
++=== **Meetings** ===
++
++Sprint Planning
++
++* Sprint Priorisierung
++** Product Backlog analysieren und auswerten
++** Sprint-Ziel festlegen
++* Planung
++** Entscheiden, wie man das Sprint-Ziel erreichen kann (Design)
++** Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen
++*** Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus
++* Sprint Backlog schätzen (Planning Poker, Magic Estimation, etc.)
++* Sprint-Ziel
++** Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
++** Wichtig! Wird gerne unterschätzt
++** Hilft, das Ziel im Auge zu behalten
++
++Daily Scrum //(hier: Weekly)//
++
++* 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
++
++Sprint-Review
++
++* 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
++
++* Regelmäßig prüfen, was gut und was nicht so gut funktioniert
++* ca. 15-30 min lang
++* Nach jedem Sprint
++* 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/]]
++
++[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/e505851f2237f527759101e71f2207f9/Retrospektive.png~|~|alt="Retrospektive.png" height="393" width="524"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/e505851f2237f527759101e71f2207f9/Retrospektive.png]]
++
++=== **Artefakte** ===
++
++Product Backlog:
++
++* Die Anforderungen für das finale Produkt
++* Eine Liste aller gewünschten Projektarbeiten
++* Eigentlich immer mehr, als im aktuellen Sprint gebraucht wird
++* Im SWP: Zu Beginn füllen und später ergänzen
++* Vom Product Owner priorisiert
++* Zu Beginn des Sprints repriorisiert
++
++Sprint Backlog:
++
++* Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)
++* **Aber:**
++** Im SWP hat jeder am Ende einer Sitzung eine Aufgabe!
++** Im Zweifelsfall durch Zuweisung...
++* Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)
++* Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird
++* 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]])
++
++= 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.
++
++== 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.
++
++=== **Der Nutzen eines gepflegten/priorisierten Product Backlogs** ===
++
++Priorisiert:
++
++* Um die für das Projekt wertvollsten Stories am Anfang zu bearbeiten
++* So kann schnell ein funktionierendes Spiel entwickelt werden
++* Am Ende ist dann noch genug Zeit für feinere Anpassungen
++* Kann die Arbeit im Projekt erleichtern
++
++Gepflegt:
++
++* Wichtig für ein effizientes, übersichtliches Arbeiten
++
++=== **Unterschiede Product Backlog vs. Sprint Backlog** ===
++
++* Product Backlog ist nie vollständig und zu jederzeit anpassbar
++* Sprint Backlog kann nur unter bestimmten Voraussetzungen angepasst werden
++
++== 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.
++
++=== **Ablauf eines Plannings (Checkliste)** ===
++
++✓ Sprint-Ziel festlegen
++✓ Anhand des Sprint-Ziels die passenden User Stories aus dem Product Backlog suchen
++✓ Die vorhandenen Schätzungen der User Stories überprüfen und ggf. anpassen
++✓ Nicht geschätzte User Stories schätzen
++✓ (nicht im ersten Sprint) Velocity heranziehen und schauen, wie viele Story Points im letzten Sprint erledigt wurden
++✓ Die gleiche Anzahl an Story Points in das Sprint Backlog ziehen
++✓ User Stories in Tasks aufsplitten
++✓ Alle Teammitglieder suchen sich Aufgaben aus, die sie bearbeiten möchten
++✓ Sprint starten
++
++=== **Die dazugehörigen Elemente eines Sprint Plannings** ===
++
++* Sprint-Ziel
++* Schätzen von Aufwänden
++* Product Backlog
++* Velocity
++
++== 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".
++
++=== **Ablauf der Aufwandsschätzung (Checkliste)** ===
++
++✓ Auf eine Werteskala einigen (Fibonacci oder T-Shirt Größen) (siehe Abschnitt "Vorschlag für eine Werteskala zum Schätzen")
++✓ Auf eine Schätzmethode einigen (siehe Abschnitt "Der Ablauf vom Planningpoker")
++✓ Eine Referenzstory bestimmen, anhand dessen geschätzt werden soll
++✓ Definition of Done bei der Schätzung mit einbeziehen
++✓ Geschätzte Story Points den jeweiligen Stories hinzufügen
++
++=== **Der Ablauf vom Planningpoker** ===
++
++* Jedes Teammitglied hat einen Satz Karten, auf dem eine zuvor bestimmte Werteskala abgebildet ist (online abwandelbar, siehe Abschnitt "Tools, um online zu schätzen")
++* Stories werden vorgestellt
++* Es dürfen Fragen zu den Stories gestellt werden, falls etwas unklar ist
++* Danach legt jedes Teammitglied eine Karte mit einem Wert verdeckt auf den Tisch
++* Hat jede Person eine Karte abgelegt, werden diese umgedreht
++* Ziel: Team einigt sich auf einen Wert
++* Weichen die Werte auf den Karten stark voneinander ab, besteht offenbar Diskussionsbedarf
++* Nach der Diskussion geht es in eine zweite Runde, bis sich das Team einigen konnte und alle offenen Fragen zu der Story geklärt sind
++
++=== **Vorschlag für eine Werteskala zum Schätzen** ===
++
++* Nur wenige Zahlen auswählen (bspw. 1,2,3,5,8)
++* 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
++
++[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/78f387122adf2a44d3b92efa743d3446/tshirtfibo.JPG~|~|alt="tshirtfibo.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/78f387122adf2a44d3b92efa743d3446/tshirtfibo.JPG]]
++
++=== **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.
++
++[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/3bb28351d712bbf3e9ad6360fd85bc6a/velo.JPG~|~|alt="velo.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/3bb28351d712bbf3e9ad6360fd85bc6a/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.
++
++[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/a5dbbbeddb36c2545d5748bfef5124c2/burnd.JPG~|~|alt="burnd.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/a5dbbbeddb36c2545d5748bfef5124c2/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
++drei Fragen:
++
++1. Was habe ich gestern gemacht?
++1. Was werde ich heute tun?
++1. 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.
++
++== 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.
++
++==== **Nutzen einer Definition of Done** ====
++
++* Wenn keine Definition of Done vorhanden ist, kann es schnell zu einem Impediment führen, da kein klares Ende einer Story in Sicht ist
++* Jedes Teammitglied ist dazu verpflichtet, diese Definition of Done einzuhalten
++* Wenn sie nicht eingehalten wird, kann es am Ende des Projekts zu sehr viel Stress führen, wodurch viel Zeit verloren geht für bspw. Feinheiten
++* Sollte direkt am Anfang erstellt werden, damit das Team sich dahingehend weiterentwickeln und lernen kann
++
++=== **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.
++
++=== **Unterschiede zwischen Definition of Done und Definition of Ready** ===
++
++* Definition of Done beschreibt, wann eine User Story fertig bearbeitet wurde
++* Definition of Ready beschreibt, wann eine User Story fertig beschrieben wurde
++
++== Sprint Review ==
++
++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** ===
++
++* Dient dazu, allen Teammitgliedern zu zeigen, was in dem Sprint bearbeitet wurde
++* Alle Teammitglieder bleiben auf dem neuesten Stand
++* Es kann dadurch verhindert werden, dass Teammitglieder abgehängt werden, sollte deshalb regelmäßig durchgeführt werden
++* Tutor wird über den Fortschritt informiert und kann bei Bedarf Tipps oder Hinweise geben, sodass verhindert werden kann, dass die Studierenden in eine komplett falsche Richtung laufen
++
++== 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
++
++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]]
++
++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]]
++
++

Changes for page Scrum

Summary

Details

Applications

Navigation