Migrate all repos into monorepo context folders
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
@@ -0,0 +1,65 @@
|
||||
# Team Europa: Scrum Events
|
||||
|
||||
Version: 3 | Last modified: 2026-02-02T11:45:51.789+01:00
|
||||
Source: confluence page ID 490592987
|
||||
|
||||
---
|
||||
|
||||
42
|
||||
Team Sync / DailyÂ
|
||||
Ziel: Das Daily dient dazu, den Fortschritt zu überprüfen, Hindernisse zu identifizieren und die Arbeit für den Tag zu planen.
|
||||
Dauer: Max. 15 Minuten
|
||||
Ablauf:Â
|
||||
Was habe ich seit dem letzten Daily erreicht?
|
||||
Was werde ich bis zum nächsten Stand-up tun?
|
||||
Welche Hindernisse stehen mir im Weg?
|
||||
|
||||
Anti-Patterns:
|
||||
Statusbericht an ScM oder PO: Das Daily ist kein Reporting-Meeting, sondern ein Austausch unter den Teammitgliedern.
|
||||
Zu lange Diskussionen: Detaildiskussionen sollten nach dem Meeting separat geführt werden - z.B. im "Meet-after"
|
||||
Fehlender Fokus auf Hindernisse: Hindernisse sollten klar benannt und nicht verschwiegen werden.
|
||||
Multitasking während des Meetings: Alle Teilnehmer sollten aufmerksam und fokussiert sein.
|
||||
Backlog RefinementZiel: Abhängigkeiten und Probleme identifizieren, die sich auf
|
||||
die nächste Iteration auswirken könnten. Fertiges Backlog für die Iterationsplanung erstellen.
|
||||
Dauer: 70 Minuten
|
||||
Ablauf: (Muster)
|
||||
PO stellt ein Set von potentiellen Stories / Enablern vor und führt durch das Backlog
|
||||
PO und Team besprechen jede Story.Erstellen u. a. AKs und decken Abhängigkeiten auf
|
||||
-> letztlich sollten die Stories / Enabler die DoR erfüllen.
|
||||
|
||||
Anti-Patterns:
|
||||
Fehlende Priorisierung: Wenn die Backlog Items nicht klar priorisiert sind, kann das Team Schwierigkeiten haben, sich auf die wichtigsten Aufgaben zu konzentrieren.
|
||||
Unklare Akzeptanzkriterien: Wenn die Akzeptanzkriterien nicht klar definiert sind, kann es zu Missverständnissen und Nacharbeit kommen.
|
||||
ReviewZiel: Das Sprint Review dient dazu, die während des Sprints erzielten Ergebnisse zu präsentieren und Feedback innerhalb des Teams einzuholen. Es hilft, den Fortschritt zu bewerten und Anpassungen für zukünftige Sprints zu planen.
|
||||
Dauer: 50 Minuten
|
||||
Ablauf: (Muster)
|
||||
Blick auf die Objectives, haben wir sie erreicht?
|
||||
Demonstration der Ergebnisse und Feedback
|
||||
|
||||
Anti-Patterns:
|
||||
Fehlende Vorbereitung: Unvorbereitete Präsentationen können den Wert des Reviews mindern.
|
||||
RetrospektiveZiel:Â Die Retrospektive dient dazu, die Zusammenarbeit und Prozesse im Team zu reflektieren und kontinuierlich zu verbessern. Es sollen MaÃnahmen zur Optimierung identifiziert und beschlossen werden.
|
||||
Dauer:Â 80 Min
|
||||
Ablauf:Â (Muster)
|
||||
Check-in
|
||||
Daten sammeln: Was lief gut? Was könnte verbessert werden?Â
|
||||
Erkenntnisse gewinnen:Â Diskussion der gesammelten Daten und Identifikation von Mustern oder Problemen.
|
||||
MaÃnahmen planen:Â Konkrete MaÃnahmen zur Verbesserung festlegen und Verantwortlichkeiten zuweisen.
|
||||
Check-out
|
||||
|
||||
Anti-Patterns:
|
||||
Schuldzuweisungen:Â Die Retrospektive sollte nicht dazu genutzt werden, Schuld zuzuweisen, sondern konstruktiv zu bleiben.
|
||||
Keine MaÃnahmen:Â Ohne konkrete MaÃnahmen verliert die Retrospektive an Wert.
|
||||
Dominanz einzelner Personen: Wenn nur wenige Personen sprechen und andere nicht zu Wort kommen, kann das die Qualität der Diskussion beeinträchtigen.
|
||||
Sprint PlanningZiel: Das Sprint Planning dient dazu, die Arbeit für den kommenden Sprint zu planen und sicherzustellen, dass das Team versteht, was zu tun ist und wie es erreicht werden soll.
|
||||
Dauer:Â 70 Min
|
||||
Ablauf:Â (Muster)
|
||||
Zielsetzung:Â Der Product Owner stellt das Sprint-Ziel vor.
|
||||
Backlog-Durchsicht: Das Team bespricht die priorisierten Backlog-Items und wählt die aus, die im Sprint bearbeitet werden sollen.
|
||||
Aufgabenplanung: Das Team plant die Umsetzung der ausgewählten Items und schätzt den Aufwand.
|
||||
Abschluss:Â Zusammenfassung und Sicherstellung, dass alle Teammitglieder die Ziele und Aufgaben verstehen.
|
||||
|
||||
Anti-Patterns:
|
||||
Ãberladung des Sprints: Zu viele Items in den Sprint zu packen, kann zu Ãberlastung und Frustration führen.
|
||||
Fehlende Priorisierung:Â Wenn die wichtigsten Aufgaben nicht priorisiert werden, kann das Team an weniger wichtigen Dingen arbeiten und die Sprint-Ziele verfehlen.
|
||||
Fehlende Teambeteiligung:Â Das gesamte Team sollte aktiv am Planning teilnehmen und nicht nur der PO oder der Scrum Master.
|
||||
Reference in New Issue
Block a user