Daily-Meeting

Das Daily-Meeting dient der täglichen Absprache von zu bearbeiteten Themen und der Klärung von offenen Fragen. Diese Themen sind im aktuellen Sprint abgebildet.

Vorbereitung

1. Überlegen, ob generelle Themen angesprochen werden müssen, die unabhängig vom Gitlab relevant sind.
2. Anschauen der selbst erstellten Bug-Issues vom Vortag. Es sollte darauffolgend eine kurze Erklärung möglich sein.
3. Überblick über das eigene Issue Board für den aktuellen Sprint verschaffen (z.B. Milestone=2026-01-20).
   
   • Die Issues sollten selbständig zwischen den Phasen: Open, Analysis, Development, Review, verschoben werden, sodass sich ein grober Überblick über die potenzielle Auslast verschafft werden kann.
   • Review: Welche Issues sind gemerged und können ins Testing übergehen oder geschlossen werden. Muss noch der Documentation Status gesetzt werden?
   • Development: Kurzen Überblick über den Entwicklungsstand verschaffen, Issues ggf. ins Review schieben und offene Fragen ansprechen.
     
   • Analysis: Werden noch weitere Informationen zu Issues benötigt, die bisher noch nicht geliefert wurden?
   • Gibt es Issues, die neu dazugekommen sind und innerhalb des Sprints priorisiert werden müssen?

Vorgehensweise

1. Ansprechen von generellen Themen, die unabhängig vom Gitlab erwähnt werden sollten.
2. Mit aktuellem Sprint-Milestone über das Issue board schauen und besprechen (Raindancer Gruppe).
   • Issue board mit Milestone=[Release-Datum], also z.B. Milestone=2026-01-20. 
   • Review: Welche Issues sind gemerged und können ins Testing übergehen oder geschlossen werden. Muss noch der Documentation Status gesetzt werden?
   • Development: Kurzen Überblick über den Entwicklungsstand geben und offene Fragen ansprechen.
     
   • Analysis: Werden noch weitere Informationen zu Issues benötigt, die bisher noch nicht geliefert wurden?
   • Wurden während des Sprints Issues hinzugefügt, durch die die maximale Gewichtung des Sprints überschritten wurde, weshalb andere Issues wieder aussortiert werden müssen?
   • Wie hoch ist das aktuelle Gewicht des Sprints? Damit kann identifziert werden, ob neue Issues dem Sprint hinzugefügt werden können.
3. Betrachten aller neuen Bug-Issues, die am Vortag in der Raindancer Gruppe erstellt wurden. Zur Zeit sind hier nur Issues aus dem Server-Projekt relevant.
   • Assignee=None, Milestone=None und Parent=None mit absteigender Sortierung nach Created Date.
   • Es muss das Bug-Label und eine Priorisierung durch Sterne vergeben werden.
   • Das Issue muss anhand der Fibonacci-Reihe gewichtet werden. Wird die 21 vergeben, muss das Issue auf jeden Fall in kleinere Issues und z.B. einen Epic unterteilt werden. Bei der 13 sollte in Erwägung gezogen werden, das Issue zu unterteilen, da dieses Gewicht auch nicht innerhalb eines Sprints abgearbeitet werden kann. Kann kein Gewicht festgelegt werden, muss das Label RFE (Request for estimate) gesetzt werden, sodass das Gewicht nachträglich hinzugefügt und das Issue ggf. neu zugeteilt werden kann.
     
   • Bugs sollen in der Regel sofort einem Sprint-Milestone zugewiesen werden. Ist die Auswirkung so gering, können sie auch einem Backlog-Milestone zugewiesen werden, jedoch besteht hier die Gefahr, dass sie erst spät wieder zugeteilt werden.
     
   • Optional: Es können weitere labels wie z.B. Quick vergeben werden.
     
   • Wichtig: Ist es nicht möglich, das Issue aufgrund von fehlenden Personen zu erklären oder zu bewerten, so muss das Issue ein Due Date erhalten und wird im nächsten Daily oder Montags-Meeting besprochen.