6. Agiles Arbeiten III – Scrum light + Kanban, Projekt in GitLab

Nach diesem Kapitel kannst du:

• erklären, welche Elemente Scrum light + Kanban aus Scrum und aus Kanban übernimmt, was bewusst weggelassen wird und warum.
• Rollen, Sprinttermine und den Sprint-Rhythmus für ein eigenes Projektteam festlegen und die Velocity pro Projekteinheit rechnen.
• Verstöße gegen die Kanban-Regeln auf einem Sprint-Board erkennen und die nächste richtige Handlung ableiten.
• Product Backlog und Sprint Backlog unterscheiden und Rückmeldungen und Vorgaben der Lehrkraft dem richtigen Ort zuordnen: Product Backlog, Sprint Backlog oder Definition of Done.
• ein GitLab-Projekt mit Labels, Milestones und zwei Issue Boards so aufsetzen, dass es über mehrere Sprints trägt.
• Alle Kommandos und Beispiele findest du auch unter https://gitlab.com/htl-villach/personal/gam/selected/gam_internal/-/blob/main/projekte/anforderungen_software_projekte/git_workflow_commands.md (Anmerkung für gam: im Ordner C:\m7\m7a\dev\devgitlab\gam_internal\projekte\anforderungen_software_projekte)

Im vorigen Kapitel lief der Sprint vom Planning bis zur Retrospektive, und Sprint 0 hat den Rahmen für das Jahresprojekt gesteckt. Dieses Kapitel legt fest, wie ein kleines Schulteam diesen Ablauf tatsächlich lebt und wie das Projekt in GitLab aufgesetzt wird, in der Matura-Analogie: wie aus der geordneten Stoffliste ein Lernplan mit festen Blöcken wird.

Scrum light + Kanban: die Arbeitsweise für Projekte

Scrum in Reinform passt nicht zu einem Team von zwei bis vier Personen, das sich an zwei Tagen pro Woche sieht: Drei Verantwortlichkeiten sind nicht besetzbar, ein tägliches Daily gibt es nicht. Scrum light + Kanban nimmt aus Scrum den Rhythmus, aus Kanban die Regeln für den Arbeitsfluss und benennt jede Abweichung, denn unbenannte Abweichungen sind laut Kapitel 03 Cargo-Kult.

In der Matura-Analogie: Du lernst in Blöcken von zwei, drei Wochen mit einem Ziel pro Block (Scrum), und du fängst kein neues Kapitel an, solange zwei halb gelernte offen sind (Kanban).

flowchart LR
  S["Scrum<br/>Blöcke mit einem Ziel"] --> M["Scrum light + Kanban"]
  K["Kanban<br/>erst fertig, dann neu"] --> M
  M --> P["dein Projektteam<br/>2-4 Personen"]

Aus Scrum übernommen	Aus Kanban übernommen	Bewusst weggelassen
Sprints von meist 2-3 Wochen, Termine mit der Lehrkraft vereinbart, je ein Milestone	WIP-Limit auf „In Arbeit“	Scrum Master als eigene Rolle
Sprint-Ziel in einem Satz	Pull-Prinzip: Arbeit wird geholt, nicht zugeteilt	tägliches Daily als eigener Termin
Planning, Review mit Abnahme, Retrospektive	erst fertig machen, dann neu anfangen	Lehrkraft als Product Owner
Product Owner im Team, Definition of Done	Review vor neuer Arbeit	gleich lange Sprints
ein Release pro Sprint	Blockaden sofort sichtbar

Sprinttermine. Ein Sprint dauert meist zwei bis vier Wochen, aber Ferien, Schularbeitswochen und Projekttage machen nicht jeden gleich lang. Das Team legt die Termine, vor allem die Reviews, beim Projektstart mit der Lehrkraft fest, je Sprint ein Milestone. Fällt ein Termin aus, wird der Milestone in Absprache verschoben.

Genauer erklärt: Der Scrum Guide sieht gleich lange Sprints vor, damit sie vergleichbar sind. Bei flexibler Länge rechnet das Team die Velocity deshalb pro Einheit. Wer in sechs Einheiten 12 Punkte geschafft hat, plant für einen Sprint mit vier Einheiten rund 8 Punkte ein:

flowchart LR
  A["Sprint 1<br/>12 Punkte in 6 Einheiten"] --> B["2 Punkte<br/>pro Einheit"]
  B --> C["Sprint 2<br/>4 Einheiten"]
  C --> D["rund 8 Punkte<br/>einplanen"]

Rollen im Projekt

Rolle	Wer	Aufgaben
Product Owner	eine Person aus dem Team, fix für das ganze Projekt	ordnet das Product Backlog, schreibt Akzeptanzkriterien, hält Rücksprache mit der Lehrkraft, entwickelt selbst mit
Prozessverantwortliche:r	eine Person aus dem Team, wechselt jeden Sprint	moderiert Board-Check und Retrospektive, achtet auf WIP-Limit, Zeiterfassung und offene Reviews
Entwicklungsteam	alle, inklusive PO und Prozessrolle	verantwortet das Sprint Backlog, setzt Stories um, reviewt gegenseitig, hält das Board aktuell
Lehrkraft	Stakeholder (Auftraggeberin bzw. Auftraggeber)	gibt die Vorgaben vor, gibt in der Sprint-Präsentation Rückmeldung und nimmt ab, berät dazwischen; priorisiert über den PO, nicht am Board vorbei

Bei zwei Personen ist eine Person Product Owner, die andere hat dauerhaft die Prozessrolle. Bei einer Diplomarbeit mit externem Auftraggeber ist dieser der Stakeholder, die Lehrkraft betreut.

Genauer erklärt: Warum ist die Lehrkraft nicht Product Owner? Ein PO muss laufend erreichbar sein und entscheiden, was als Nächstes kommt; eine Lehrkraft mit mehreren Teams schafft das nicht. Außerdem lernt das Team das Reihen und Streichen nur, wenn es selbst entscheidet. Das letzte Wort über „abgenommen“ hat die Lehrkraft trotzdem, im Review. Ein neuer Wunsch nimmt deshalb immer den Weg über den PO:

flowchart LR
  L["Lehrkraft<br/>Stakeholder"] -- "neuer Wunsch" --> PO["Product Owner"]
  PO -- "ordnet ein" --> B["Product Backlog"]
  B -- "Pull" --> T["Team"]
  T -- "Review" --> L

Der Sprint-Rhythmus

flowchart LR
  P["Planning<br/>erste Einheit, 30 min"] --> B["Board-Check<br/>jede Einheit, 5 min"]
  B --> B
  B --> R["Review mit Lehrkraft<br/>letzte Einheit, 20 min"]
  R --> X["Retrospektive<br/>nur Team, 20 min"]
  X --> L["Release und<br/>Milestone schließen"]
  L --> P

• Planning (erste Einheit des Sprints): Der PO stellt die oberen Stories vor, das Team schätzt, wählt nach Velocity aus und formuliert das Sprint-Ziel. Die Lehrkraft kann für Prioritäten dazukommen, muss aber nicht.
• Board-Check (zu Beginn jeder Projekteinheit, 5 Minuten, im Stehen vor dem Board): ersetzt das Daily. An Tagen ohne Projekteinheit schreibt jede Person einen Satz in den Team-Channel.
• Review (letzte Einheit), an der Schule meist Sprint-Präsentation genannt: Das Team führt lauffähige Software vor, die Lehrkraft gibt Rückmeldung und nimmt Story für Story ab (Details im nächsten Abschnitt).
• Retrospektive direkt danach, ohne Lehrkraft: eine Maßnahme mit verantwortlicher Person.
• Release und Schließen des Milestones beenden den Sprint (siehe Git-Workflow light in Kapitel 07).

Beim Board-Check spricht das Team zum Board, nicht zur Lehrkraft:

Pro Karte in "In Arbeit" und "Review":
- Was ist seit der letzten Einheit passiert?
- Was passiert heute damit?
- Was blockiert? (Blockade sofort als Kommentar ins Issue)
Danach: Ist das WIP-Limit eingehalten? Wartet etwas im Review?

Kanban-Regeln auf dem Sprint-Board

• WIP-Limit: Auf „In Arbeit“ stehen höchstens Teamgröße minus eins Karten, mindestens eine, damit immer jemand für Reviews und Hilfe frei ist. Ist das Limit erreicht, hilft man an einer laufenden Karte mit.
• Pull statt Push: Wer frei ist, holt die oberste Karte aus dem Sprint Backlog. Niemand teilt zu, auch der PO nicht.
• Review vor neuer Arbeit: Wartet eine Karte im Review, wird zuerst reviewt. Kurzform: Stop starting, start finishing.
• Blockaden sichtbar: Eine blockierte Karte bleibt in ihrer Spalte, die Blockade steht als Kommentar im Issue und kommt im nächsten Board-Check zuerst dran.

Für die Frage „Was tue ich als Nächstes?“ ergeben die Regeln einen einfachen Entscheidungsweg:

flowchart TD
  F["Ich bin frei"] --> R{"Wartet eine Karte<br/>im Review?"}
  R -- "ja" --> RV["zuerst reviewen"]
  R -- "nein" --> W{"WIP-Limit<br/>erreicht?"}
  W -- "nein" --> PU["oberste Karte aus dem<br/>Sprint Backlog holen"]
  W -- "ja" --> H["helfen statt<br/>neu anfangen"]

Genauer erklärt: Ein Dreierteam fängt ohne Limit alle sechs Stories an und hat am Sprintende sechs fast fertige, also null Punkte. Mit Limit 2 sind bei gleicher Arbeit vier fertig und zwei nicht begonnen:

xychart-beta
  title "Dreierteam, 6 Stories: fertige Stories am Sprintende"
  x-axis ["ohne WIP-Limit", "mit WIP-Limit 2"]
  y-axis "fertige Stories" 0 --> 6
  bar [0, 4]

Kurz nachgedacht

Dreierteam, dritte Einheit: drei Karten in „In Arbeit“ (WIP-Limit 2), zwei seit einer Woche in „Review“, und die Lehrkraft hat in der Pause eine „ganz dringende“ Story zugerufen, die jetzt jemand anfängt. Welche Regeln sind verletzt, und was tut die prozessverantwortliche Person als Erstes?

Auflösung

Drei Regeln sind verletzt: WIP-Limit überschritten, neue Arbeit trotz wartender Reviews, und die Story kommt am Product Owner vorbei. Zuerst werden die zwei Reviews abgearbeitet. Die neue Story kommt über den PO ins Product Backlog; er klärt mit der Lehrkraft, ob sie in diesen Sprint gehört und was dafür hinausfällt. Maßstab ist das Sprint-Ziel.

Weiterlesen

• Scrum Guide - das Original, kurz und verbindlich: Sprints von höchstens einem Monat, Daily von 15 Minuten. Zeigt, wovon Scrum light bewusst abweicht.
• Wikipedia: Scrumban - die Mischform aus Scrum und Kanban mit WIP-Limits und Pull-Prinzip, auf der diese Arbeitsweise aufbaut.

Zwei Backlogs und die Rolle der Lehrkraft

Product Backlog und Sprint Backlog

Beide Begriffe kennst du aus Kapitel 02, im Projekt verwechselt man sie trotzdem leicht. In der Matura-Analogie ist das Product Backlog die ganze Stoffliste, das Sprint Backlog der Lernplan für die nächsten zwei Wochen: ausgewählt, zerlegt, mit einem Ziel.

	Product Backlog	Sprint Backlog
Inhalt	alle Wünsche an das Produkt, geordnet	Sprint-Ziel, die ausgewählten Stories und der Plan dafür (Tasks)
Verantwortlich	Product Owner	Entwicklungsteam
Wer ändert	der PO jederzeit: neue Einträge, umreihen, streichen	nur das Team; der Umfang ändert sich nur mit dem PO, das Sprint-Ziel bleibt
Lebensdauer	das ganze Projekt	ein Sprint
Detailgrad	oben fein, unten grob	alles fein: Akzeptanzkriterien, Schätzung, Tasks
in GitLab	offene Issues ohne Milestone	offene Issues mit Milestone Sprint N

flowchart LR
  L["Lehrkraft, Team"] -- "Wünsche" --> PB["Product Backlog<br/>PO ordnet"]
  PB -- "Planning" --> SB["Sprint Backlog<br/>Team plant"]
  SB --> I["fertige Stories<br/>Sprint-Präsentation"]
  SB -. "nicht fertig" .-> PB

Genauer erklärt: Was nicht fertig wird, rutscht nicht automatisch in den nächsten Sprint, sondern geht zurück ins Product Backlog, wo der PO neu reiht. Auch ein neuer Wunsch mitten im Sprint landet dort, sonst wird das Sprint-Ziel zur Wunschliste.

Sprint-Präsentation: Rückmeldung und Abnahme

In der Sprint-Präsentation zeigt das Team an der laufenden Software, ohne Folien, was fertig ist. Die Lehrkraft hat dabei zwei Aufgaben mit verschiedenem Ergebnis:

• Abnahme: Story für Story prüft sie gegen Akzeptanzkriterien und Definition of Done. Ergebnis ist „fertig“ oder „nicht fertig“. Nur abgenommene Stories zählen für die Velocity.
• Rückmeldung: Was soll anders werden, was fehlt, was war unklar? Ergebnis sind neue oder geänderte Einträge, die der PO ins Product Backlog übernimmt und einordnet.

flowchart LR
  P["Sprint-Präsentation"] --> A["Abnahme<br/>gegen AK und DoD"]
  P --> R["Rückmeldung<br/>der Lehrkraft"]
  A -- "fertig" --> V["zählt für die Velocity"]
  A -- "nicht fertig" --> PB["Product Backlog"]
  R -- "PO ordnet ein" --> PB

Eine Rückmeldung ist Material für das nächste Planning; der PO schreibt sie gleich mit.

Vorgaben der Lehrkraft

Neben Wünschen gibt die Lehrkraft einen festen Rahmen vor: Vorgaben (Constraints), die für das ganze Projekt gelten und nicht verhandelbar sind. In der Matura-Analogie sind das die Prüfungsbedingungen: nicht auf der Stoffliste, aber gültig für jedes Kapitel.

Bereich	Beispiel einer Vorgabe	wo sie landet
Technologie-Stack	Sprache, Framework und Datenbank sind vorgegeben, Abweichung nur nach Rücksprache	Projektdokumentation, Gerüst in Sprint 0
Security	keine Secrets im Repository, Passwörter nur gehasht, Eingaben serverseitig validiert	Definition of Done
Deployment	jedes Sprint-Release läuft über die Pipeline auf der Testumgebung	Task in Sprint 0, danach Definition of Done
Dokumentation	README.md mit Start-Anleitung ist aktuell	Definition of Done
Tests	neue Logik hat automatische Tests, die Pipeline ist grün	Definition of Done
Lizenzen	Bibliotheken, fremder Code und Bilder haben eine passende Lizenz und eine Quellenangabe	Definition of Done

Die konkreten Vorgaben für dein Projekt nennt die Lehrkraft beim Projektstart. Das Team schreibt sie in die Projektdokumentation und übernimmt sie in Sprint 0 in die Definition of Done.

Genauer erklärt: Warum DoD statt Story? Eine Story „Passwörter hashen“ kann der PO nach unten reihen, bis die Zeit aus ist. Steht „Passwörter nur gehasht“ in der DoD, ist keine Login-Story fertig, solange das fehlt. Was nur einmal eingerichtet wird, etwa die Deployment-Pipeline, ist ein Task in Sprint 0 (type::technical-improvement); danach prüft die DoD, dass sie grün bleibt.

Kurz nachgedacht

In der Sprint-Präsentation sagt die Lehrkraft drei Dinge: (a) „Der Export sollte auch als CSV gehen.“ (b) „In der Datenbank stehen die Passwörter im Klartext.“ (c) „Die Suche findet nichts, wenn man Großbuchstaben tippt“, und die Story verlangt das in einem Akzeptanzkriterium. Was passiert jeweils mit der betroffenen Story und wo landet der Punkt?

Auflösung

(a) ist eine Rückmeldung: neue Story ins Product Backlog, die gezeigte Export-Story kann trotzdem abgenommen werden. (b) verletzt die Security-Vorgabe in der DoD: Die Login-Story ist nicht fertig, zählt null Punkte und geht zurück ins Product Backlog. (c) verletzt ein Akzeptanzkriterium: ebenso nicht fertig, zurück ins Product Backlog. Der PO entscheidet, ob (b) und (c) im nächsten Sprint ganz oben stehen.

Empfehlung für Projekte: Git-Workflow light

Dieser Abschnitt ist die Arbeitsvereinbarung in GitLab für deine Projekte (Jahresprojekt, ITP-Projekt, Diplomarbeit), eingerichtet im Sprint 0.

Kurzfassung: Issue → Feature-Branch → Merge Request → Review → dev → Release → main.

flowchart LR
  I["Issue"] --> F["Feature-Branch"]
  F --> MR["Merge Request"]
  MR --> RV["Review"]
  RV --> D["dev"]
  D --> RL["Release"]
  RL --> M["main"]

Dieses Kapitel behandelt Punkt 1, die Projekt-Grundlagen. Die Punkte 2 bis 9, vom Branching-Modell bis zum Release, und die Vorlagen für GitLab folgen in Kapitel 07.

Projektantrag. Am Anfang steht der Projektantrag, den du mit der ITP-Theorie-Lehrkraft abstimmst. Die Projektziele darin sind SMART formuliert: spezifisch, messbar, attraktiv, realistisch, terminiert. „Eine schöne App bauen” ist kein Ziel. „Bis Ende Feber können registrierte Nutzerinnen und Nutzer Termine anlegen und teilen” ist eines.

1. Projekt-Grundlagen

• Labels für Typ und Arbeitsstand verwenden: type::user-story, type::defect, type::technical-improvement, type::release sowie status::in-progress und status::review. Scoped Labels (mit ::) schließen sich innerhalb eines Scopes gegenseitig aus. Ein Issue kann also nicht gleichzeitig „In Arbeit” und „Review” sein.
• Issue Templates verwenden (Vorlagen siehe „Vorlagen für GitLab“ in Kapitel 07).
• Milestones für die Sprints anlegen (Sprint 1, Sprint 2, …), jeweils mit Start- und Enddatum (Plan → Milestones → New milestone). Der Milestone entscheidet, ob ein Issue im Product Backlog oder in einem Sprint steht. Dafür gibt es kein eigenes Label.
• Das Issue Board (in neueren GitLab-Versionen Work Item Board) aktiv nutzen: Die Karte wandert, wenn die Arbeit wandert.
• Die Definition of Done steht samt den Vorgaben der Lehrkraft in der Projektdokumentation und ist verbindlich.

Issue Boards über mehrere Sprints

Wo ein Issue gerade steht, ergibt sich aus drei Angaben: Milestone, Status-Label und ob das Issue offen ist.

Wo steht das Issue?	Milestone	Status-Label	Issue
Product Backlog (gesamt)	keiner	keines	offen
Sprint Backlog, noch nicht begonnen	Sprint N	keines	offen
In Arbeit	Sprint N	status::in-progress	offen
Review	Sprint N	status::review	offen
Fertig	Sprint N	keines	geschlossen

Damit beide Backlogs getrennt bleiben, legst du zwei Boards an (Board-Auswahl links oben auf der Board-Seite → Create new board): eines zum Planen über alle Sprints, eines für die tägliche Arbeit im laufenden Sprint.

flowchart LR
  subgraph planung["Board Planung"]
    direction LR
    PB["Open<br/>Product Backlog"] -- "einplanen" --> S1["Sprint 3"]
    PB -- "vormerken" --> S2["Sprint 4"]
  end
  subgraph sprint["Board Sprint, Scope: Sprint 3"]
    direction LR
    TD["Open<br/>Sprint Backlog"] --> IP["status::in-progress"]
    IP --> RV["status::review"]
    RV --> CL["Closed<br/>Fertig"]
  end
  S1 -. "dieselben Issues" .-> TD

1. Board „Planung“. Open ganz links ist das Product Backlog, oben die nächste Story. Über New list → Milestone → Sprint 3 → Add to board kommen Listen für den laufenden und den nächsten Sprint dazu. Eine Karte nach Sprint 3 zu ziehen setzt den Milestone.

2. Board „Sprint“. Scope auf den Milestone des laufenden Sprints, über New list → Label die Listen status::in-progress und status::review. Open ist jetzt das Sprint Backlog, Closed „Fertig“; geschlossen wird normalerweise per Merge Request mit Closes #42.

3. WIP-Limit setzen. In der Liste status::in-progress über Edit list settings → Work in progress limit → Edit eine Obergrenze eintragen: Teamgröße minus eins, mindestens 1, also z. B. 2 bei einem Dreierteam.

4. Sprintwechsel. Im Sprint Planning bzw. am Ende des Sprints:

   • Nicht fertige Issues im Board „Planung“ bewusst nach Sprint 4 oder zurück nach Open ziehen; GitLab verschiebt beim Schließen eines Milestones nichts.
   • Milestone Sprint 3 zusammen mit dem Release schließen (siehe „7. Releases“ in Kapitel 07).
   • Board „Sprint“ über Configure board auf Sprint 4 umstellen, im Board „Planung“ Sprint 3 durch Sprint 5 ersetzen.

Schritt 4 im Überblick:

flowchart LR
  A["Unfertiges bewusst<br/>nach Sprint 4 oder Open"] --> B["Milestone Sprint 3<br/>schließen + Release"]
  B --> C["Board Sprint:<br/>Scope auf Sprint 4"]
  C --> D["Board Planung:<br/>Sprint 3 weg, Sprint 5 dazu"]

Ohne Board geht das Einplanen auch direkt im Issue, im Feld Milestone oder per Quick Action /milestone %"Sprint 4"; /remove_milestone legt die Story zurück ins Product Backlog.

Genauer erklärt: Warum Milestone statt Label status::sprint? Der Milestone sagt „Sprint 3, vom 3. bis 14. November“ und bleibt erhalten: Die Summe der Weights seiner geschlossenen Issues ist die Velocity. Ein zusätzliches Label wäre dieselbe Information doppelt, bis sie sich widerspricht.

Milestone-Listen, Board-Scope, WIP-Limits und Burndown-Charts gehören zu GitLab Premium, das im HTL-Bereich zur Verfügung steht; in GitLab Free fehlen sie.

Weiterlesen

• GitLab Docs: Issue boards - Listen, Board-Scope und WIP-Limits; Milestones - Sprints anlegen und schließen.

Zusatzmaterialien

• Scrum Guide - lohnt sich, wenn du begründen musst, worin dein Projekt von Scrum abweicht; die Abschnitte „Product Backlog“ und „Sprint Backlog“ zeigen außerdem knapp, wem welches Backlog gehört.

Zum Anhören

Diesen Text kannst du dir kostenlos mit der Vorlesefunktion deines Browsers oder Betriebssystems vorlesen lassen, z. B. in Microsoft Edge über „Laut vorlesen”.

Lernergebnisse: Was du nach diesem Kapitel können solltest

• Erklären: erklären, welche Elemente Scrum light + Kanban aus Scrum und aus Kanban übernimmt, was bewusst weggelassen wird und warum.
• Anwenden: Rollen, Sprinttermine und den Sprint-Rhythmus für ein eigenes Projektteam festlegen und die Velocity pro Projekteinheit rechnen.
• Analysieren: Verstöße gegen die Kanban-Regeln auf einem Sprint-Board erkennen und die nächste richtige Handlung ableiten.
• Analysieren: Product Backlog und Sprint Backlog unterscheiden und Rückmeldungen und Vorgaben der Lehrkraft dem richtigen Ort zuordnen: Product Backlog, Sprint Backlog oder Definition of Done.
• Anwenden: ein GitLab-Projekt mit Labels, Milestones und zwei Issue Boards so aufsetzen, dass es über mehrere Sprints trägt.

Passende Übungen

Dieses Kapitel hat keine eigene Übung. Die 70 Praxisminuten dienen der Vorbereitung des Jahresprojekts: Rollen und Sprinttermine festlegen, die Vorgaben der Lehrkraft in die Definition of Done übernehmen, Labels, Milestones und die zwei Issue Boards im eigenen GitLab-Projekt anlegen. Die nächste Übung, Aufgabe 03 - Jahresprojekt Sprint 0, folgt in Kapitel 07.

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules