BE SCRUM und Zeitschreibung

Last modified by Dimitri Rupp on 2026/06/11 09:30

Auf dieser Seite

⏱️ BE SCRUM und Zeitschreibung
- 🔁 SCRUM-Prozess
  - Workpackages (WPs) – Status und Regeln
    - Weitere Vorgaben
  - Backlog Prozess
- Verwandte Themen

SCRUM-Rhythmus und Zeiterfassung

⏱️ BE SCRUM und Zeitschreibung

🔁 SCRUM-Prozess

BE arbeitet in Sprints, die jeweils 4–5 Wochen dauern und entweder zu Beginn oder am Ende eines Monats abgeschlossen werden. Der Prozess gliedert sich in drei zentrale Meetings:

🔄 Sprint-Zyklus:

flowchart LR
    P[Sprint Planning
Mittwoch] --> S[Sprint
4–5 Wochen]
    S --> R[Sprint Review
Dienstag]
    R --> RE[Sprint Retrospektive
kurz nach Review]
    RE --> P
    classDef act fill:#e3f2fd,stroke:#1976d2,stroke-width:1px
    class P,S,R,RE act

- 1. Sprint Planning

Findet in der Regel mittwochs statt.
Ziel: Abstimmung des kommenden Sprints im Team.
Vorbereitung: Der Sprint sollte vor dem Termin bereits zu ca. 80 % geplant sein. Im Planning können bei Bedarf Anpassungen vorgenommen werden.

2. Sprint Review

Meist am Dienstag vor dem nächsten Planning.
Zweck: Rückblick auf den vergangenen Sprint.
Ablauf: Jeder stellt seine Lead-Workpackages (WPs) vor und fasst die Ergebnisse kurz zusammen.
Fokus: Vergangenheit, nicht Zukunft.
Fokus auf das "gelbe Auto" (Produkt): Wir reden über das Auto, darüber, dass es gelb ist, und nicht darüber, wie ist es zustande gekommen ist oder was im Weiteren passiert.

3. Sprint Retrospektive

Kurz nach dem Review.
Ziel: Reflexion der positiven und negativen Ereignisse des Sprints.
Ergebnis: Verbesserung des Prozesses für die Zukunft.

Workpackages (WPs) – Status und Regeln

Jedes WP durchläuft vier Phasen:

Inactive – WP ist ein Zeitblocker (z.B.: “fixe BE Meetings”)
Active – WP liegt in einem Sprint, aber es wurde noch keine Zeit gebucht.
In Progress – Zeit wurde auf das WP gebucht.
Closed – Die Definition of Done (DoD) für den Sprint ist erfüllt.Aktuelle Regel: Vor dem Review sollen WPs, die für den nächsten Sprint gesplittet wurden, nicht auf „Closed“ gesetzt werden. Stattdessen wird der Tag „Sprint done“ verwendet.

🔄 WP-Status – vier Phasen:

flowchart LR
    I[Inactive
Zeitblocker] --> A[Active
im Sprint, noch keine Zeit gebucht]
    A --> IP[In Progress
Zeit gebucht]
    IP --> C[Closed
Definition of Done erfüllt]
    classDef act fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px
    class I,A,IP,C act

Weitere Vorgaben

Regelmäßige Statusupdates als Notiz im WP.
Vor jedem Review: „Review des Monats“ – kurze Zusammenfassung des Sprints in 1–2 Sätzen.
Bei jedem neuen oder gesplitteten WP:Definition of Done festlegen.Bei größeren Themen zusätzlich eine DoD für den Sprint definieren.1: WP DoD2: Monats DoD

Backlog Prozess

Ziel: Ein transparenter, schlanker Prozess zur Pflege und Priorisierung des Backlogs.

Rollen:

Teammitglieder: Dürfen jederzeit neue Backlog-Items anlegen.
Product Owner (pro Themengebiet): Prüfen fachliche Vollständigkeit.Rebekka: Odoo, RimoRoxanna: BMD, Fabric/Power BI/AzurePatrick: Jira, Fabric/Power BI/AzureDejan: Odoo, Rimo, QM
Head of: Finalisiert Priorisierung vor Sprintplanung.

Prozess:

WP anlegen (kontinuierlich) - Jeder kann neue Items einstellen. - Template: Titel (kurz & prägnant), Beschreibung (Was ist das Ziel?), Business Value (Warum wichtig?), Größe grob (S/M/L). - Aufwand: max. 5 Minuten pro WP.
Wöchentlicher Mini-Check (15 Min im Weekly) - Neue WPs vorstellen. - Prüfen auf Verständlichkeit und Vollständigkeit. - Ziel: Qualität sichern, bevor sich Müll ansammelt.
Backlog-Refinement (1× pro Sprint, max. 60 Min) - Review neuer WPs. - Schätzung (S/M/L). - Vorläufige Priorisierung. - Ziel: Backlog ist sauber und priorisiert.

🔄 Backlog-Prozess:

flowchart TD
    A[WP anlegen
kontinuierlich, max. 5 Min] --> B[Wöchentlicher Mini-Check
15 Min im Weekly]
    B --> C[Backlog-Refinement
1x pro Sprint, max. 60 Min]
    C --> D[Backlog sauber und priorisiert]
    classDef act fill:#fff3cd,stroke:#b85c00,stroke-width:1px
    class A,B,C,D act

Priorisierung:

High = Muss rein.
Medium = Gut, wenn Zeit.
Low = Parken.
Optional: Business Value vs. Aufwand Matrix.

Transparenz:

Backlog immer sichtbar im Tool.
Status: Inactive → WP neu angelegt. WP muss ausgearbeitet werden. Verantwortliche/r: ErstellerInActive → WP von ErstellerIn vollständig ausgearbeitet. WP muss geprüft werden. Verantwortliche/r: Product OwnerIn Progress → WP geprüft + vollständig. Wartet auf Umsetzung in Sprint. Verantwortliche/r: gesamtes TeamClosed → WP wird nicht umgesetzt

Grafische Darstellung: