06 Agile Controlling

Kapitel Übersicht

Kapitel 06 Lesezeit: ~15 Min Quelle: OuP-09_Projekt-Controlling.pdf (Seiten 33-33)

Agile Projekte vs. Klassisches Controlling

Die Herausforderung

Klassische Controlling-Methoden wie EVA, MTA oder KTA basieren auf detaillierten Planungen und festen Meilensteinen. Agile Projektmanagement-Methoden (Scrum, Kanban, etc.) arbeiten jedoch mit:

Iterativem Vorgehen (Sprints)
Variablem Scope (Backlog-Priorisierung)
Empirischem Vorgehen (Lernen und Anpassen)
Selbstorganisierten Teams

Diese Unterschiede erfordern angepasste Controlling-Methoden, die besser zum agilen Mindset passen.

Kernprinzipien des agilen Controllings

Prinzip	Beschreibung
Empirisch statt deterministisch	Messung basiert auf Ist-Daten, nicht auf Plänen
Iteration statt Projektphase	Controlling in kurzen Zyklen (Sprints)
Transparenz statt Berichte	Visuelle Boards, Echtzeit-Status
Fokus auf Value statt Aufwand	Business Value über Budgetverbrauch
Anpassung statt Kontrolle	Flexibilität über Planungsdisziplin

Sprint Burndown Chart

Definition

Ein Sprint-Burndown-Chart ist ein grafisches Instrument zur Visualisierung des Arbeitsfortschritts innerhalb eines Sprints im Scrum-Framework, um den Fortschritt eines Teams während eines Sprints darzustellen.

Ziel

Visualisiert den Arbeitsfortschritt im aktuellen Sprint
Zeigt, wie viel Arbeit zum aktuellen Zeitpunkt noch erledigt werden muss
Lässt erkennen, wie schnell das Team arbeitet (Velocity)
Eignet sich, um Iterationen bzw. Sprints zu kontrollen

Besonderheit

Der Burndown-Chart kann auch für das gesamte Projekt (Product-Backlog) eingesetzt werden → Product Burndown Chart.

Aufbau eines Sprint Burndown Charts

Diagramm-Achsen

graph TD
    subgraph "Sprint Burndown Chart"
        direction TB
        Y["Y-Achse<br/>Verbleibende Arbeit<br/>(Story Points, Stunden, Tasks)"]
        X["X-Achse<br/>Tage des Sprints"]
        L1["Ideal-Linie"]
        L2["Ist-Linie"]
    end

Die beiden Linien

Linie	Bedeutung
Ideal-Linie	Der ideale Verlauf vom Start (gesamter Sprint-Umfang) bis zum Ende (0)
Ist-Linie	Die tatsächliche Entwicklung der verbleibenden Arbeit

Interpretation

Linie steigt nach oben: Neue Arbeit wurde hinzugefügt (Scope Creep)
Linie fällt steiler: Team arbeitet schneller als geplant
Linie flacht ab: Team arbeitet langsamer als geplant
Linie endet nicht bei 0: Sprint-Ziel nicht erreicht

Typischer Verlauf

graph LR
    subgraph "Sprint Burndown (Normaler Verlauf)"
        direction TB
        Y["Arbeit (Story Points)"]
        X["Zeit (Tage)"]
        L1[Start: 40 SP<br/>→ Tag 10: 0 SP]
        L2[Tag 1: 35 SP<br/>Tag 5: 20 SP<br/>Tag 10: 0 SP]
    end

Beispiel: * Sprint-Start: 40 Story Points (SP) * Tag 1: 35 SP verbleibend * Tag 5: 20 SP verbleibend * Tag 10: 0 SP verbleibend (Ziel erreicht)

Typische Muster und ihre Interpretation

Muster 1: Normaler Verlauf (Ideal)

Arbeit
  ^
  | Ideal  Ist
  |   ___   ___
  |  /   \_/   \
  | /           \
  |/_____________\> Zeit
    1 2 3 4 5 6 7

Merkmale: * Ist-Linie folgt Ideal-Linie eng * Endet bei 0 am Sprint-Ende * Keine großen Sprünge

Interpretation: Sprint verläuft wie geplant.

Muster 2: Scope Creep (Linie steigt auf)

Arbeit
  ^
  | Ideal      Ist
  |   ___      ___
  |  /   \____/   \__
  | /               \___
  |/__________________\> Zeit
    1 2 3 4 5 6 7

Merkmale: * Linie steigt während des Sprints nach oben * Neue Arbeit wurde hinzugefügt

Interpretation: * Change Requests während des Sprints * Nachträgliche Anforderungen * Aufgaben wurden unterschätzt

Maßnahme: Prüfen, ob der Sprint-Ziel noch erreichbar ist, ggf. Re-Priorisierung.

Muster 3: Flacher Verlauf (Team zu langsam)

Arbeit
  ^
  | Ideal
  |   ___
  |  /   \________
  | /            \
  |/              \> Zeit
    1 2 3 4 5 6 7
      Ist-Linie

Merkmale: * Ist-Linie fällt langsamer als Ideal-Linie * Arbeit bleibt zum Sprint-Ende übrig

Interpretation: * Team arbeitet langsamer als erwartet * Aufgaben komplexer als geschätzt * Störungen oder Blockaden

Maßnahme: Prüfen, ob Tasks aus dem Sprint entfernt oder neu priorisiert werden können.

Manner 4: Steiler Verlauf (Team zu schnell)

Arbeit
  ^
  | Ideal
  |   ___
  |  /   \_____
  | /
  |/___________\> Zeit
    1 2 3 4 5
    Ist-Linie

Merkmale: * Ist-Linie fällt schneller als Ideal-Linie * Sprint-Ziel früher erreicht

Interpretation: * Aufgaben einfacher als erwartet * Team sehr produktiv

Maßnahme: Prüfen, ob zusätzliche Aufgaben aus dem Backlog aufgenommen werden können.

Muster 5: Zickzack-Verlauf

Arbeit
  ^
  | Ideal        Ist
  |   ___     ___/\/\___
  |  /   \___/          \
  | /                    \
  |/______________________\> Zeit
    1 2 3 4 5 6 7 8 9

Merkmale: * Linie schwankt stark auf und ab * Keine klare Entwicklung

Interpretation: * Aufgaben werden ständig hinzugefügt und entfernt * Unsicherheit im Sprint * Schlechtes Estimating

Maßnahme: Sprint-Refining verbessern, Klärung der Anforderungen vor Sprint-Start.

Velocity Tracking

Was ist Velocity?

Die Velocity (Geschwindigkeit) ist ein Maß dafür, wie viel Arbeit ein Team in einem Sprint erledigen kann.

Definition

\[Velocity = \sum (Story\ Points\ der\ im\ Sprint\ fertiggestellten\ User\ Stories)\]

Typische Entwicklung

graph TD
    subgraph "Velocity Tracking über mehrere Sprints"
        direction TB
        S1[Sprint 1<br/>Velocity: 20 SP]
        S2[Sprint 2<br/>Velocity: 25 SP]
        S3[Sprint 3<br/>Velocity: 22 SP]
        S4[Sprint 4<br/>Velocity: 28 SP]
        S5[Sprint 5<br/>Velocity: 24 SP]
        Avg[Average: 23,8 SP]
    end

Anwendung der Velocity

Sprint-Planning: Wählen Sie Tasks basierend auf der durchschnittlichen Velocity
Release-Planning: Schätzen Sie, wann alle Features im Backlog fertig sein werden
Trend-Analyse: Erkennen von Produktivitätsveränderungen

Stabilisierung der Velocity

Phase	Merkmal
Start-Phase	Velocity schwankt stark (Team lernt, wird eingespielt)
Stabilisierungsphase	Velocity beginnt sich zu stabilisieren
Stabile Phase	Velocity konstant (zuverlässige Prognose möglich)

Best Practice

Ignorieren Sie die Velocity in den ersten 3-5 Sprints. Das Team ist noch in der Forming-Phase. Nutzen Sie erst danach die durchschnittliche Velocity für Prognosen.

Product Burndown Chart

Definition

Der Product Burndown Chart zeigt die verbleibende Arbeit im gesamten Product Backlog über die Zeit.

Unterschied zu Sprint Burndown

Aspekt	Sprint Burndown	Product Burndown
Umfang	Ein Sprint (2-4 Wochen)	Gesamtes Projekt
Detailgrad	Tasks (Stunden/Story Points)	User Stories (Story Points)
Frequenz	Täglich	Meilensteinweise / Sprint-Ende
Ziel	Sprint-Goal erreichen	Release-Zeitplan

Aufbau

Arbeit (Story Points)
  ^
  |
  |   ___
  |  /   \_______________________________________________
  | /                                                     \
  |/                                                       \> Zeit
    Sprint 1  Sprint 2  Sprint 3  Sprint 4  Sprint 5  Sprint 6
      120        95         70         45         20          0

Interpretation

Sinkende Kurve: Arbeit wird erledigt
Stufenweise: Neue Anforderungen werden hinzugefügt
Endet bei 0: Alle Anforderungen sind erfüllt
Endet über 0: Release-Ziel nicht erreicht

Burnup Chart

Definition

Ein Burnup Chart zeigt zwei Kurven:

Scope: Gesamter Umfang des Backlogs
Done: Bereits erledigte Arbeit

Vorteil gegenüber Burndown

Der Burnup Chart macht Änderungen im Scope sichtbar, die im Burndown Chart als "Anstieg" interpretiert werden könnten.

Aufbau

Arbeit (Story Points)
  ^
  |              Scope (Gesamtumfang)
  |              _____________
  |             /             \__________
  |            /                        \
  |           /                          \
  |          /                            \
  |         /                              \
  |        /                                \
  |       /                                  \
  |      /                                    \
  |     /                                      \
  |    /                                        \
  |   / Done (Fertig)                            \
  |  /___________________________________________\
  |______________________________________________> Zeit
    120  110  100   90    80    70    60     50

Interpretation

Scope-Linie: Zeigt, wie sich der Gesamtfang verändert (z.B. durch neue Anforderungen)
Done-Linie: Zeigt, wie viel Arbeit bereits erledigt ist
Lücke: Der Abstand zwischen Scope und Done zeigt die verbleibende Arbeit

Praktisch

Im Sprint 4 wurden 10 Story Points hinzugefügt (Scope-Curve steigt). Im Burndown-Chart würde dies wie Scope Creep aussehen. Im Burnup-Chart ist klar erkennbar: Der Umfang wurde erweitert.

Cumulative Flow Diagram (CFD)

Definition

Das Cumulative Flow Diagram visualisiert den Arbeitsfortschritt in einem Kanban- oder Scrum-Board über die Zeit.

Aufbau

Anzahl Items
  ^
  |  Release
  |  _______
  | /       \
  |/         \________
  |                 \________
  |                          \________
  |  Testing
  |  __________
  | /          \__________
  |/                     \________
  |  In Progress
  |  _______
  | /       \_______
  |/               \__________
  |  To Do
  |  _______________________
  |/                           \_________
  |________________________________________> Zeit
    T1  T2  T3  T4  T5  T6  T7  T8  T9  T10

Informationen aus dem CFD

Aspekt	Information
Lead Time	Zeit von "To Do" bis "Release"
Cycle Time	Zeit von "In Progress" bis "Release"
Work in Progress (WIP)	Breite der "In Progress"-Zone
Bottlenecks**	Bereiche, in denen sich die Zone verbreitert
Trend	Entwicklungen über die Zeit

Bottleneck-Erkennung

Anzahl Items
  ^
  |
  |  Testing
  |  _______
  | /       \
  |/         \________
  |                 \________
  |  In Progress
  |  __________
  | /          \_______
  |/                  \________
  |                   XXXXXXX  <--- Bottleneck

Wenn sich eine Zone (z.B. "Testing") verbreitert, bedeutet dies, dass sich Items dort stauen → Bottleneck.

Lead Time vs. Cycle Time

Definitionen

Begriff	Definition
Lead Time	Zeit von der Aufnahme in das System (To Do) bis zur Fertigstellung
Cycle Time	Zeit, die tatsächlich an der Arbeit verbracht wird (In Progress bis Done)

Beziehung

Lead Time = Cycle Time + Wartezeit

           ┌─────────────────────┐
           │  Wartezeit          │
┌─────────┐ ┌─────────────────────┐ ┌─────────┐
│  To Do  │ │    In Progress     │ │  Done   │
└─────────┘ │                    │ └─────────┘
           └─────────────────────┘
           ←── Lead Time ────────→
                  ←── Cycle Time ─→

Wichtigkeit

Kurze Lead Time: Schnelles Reagieren auf Kundenanforderungen
Kurze Cycle Time: Hohe Effizienz der Bearbeitung
Große Differenz: Hohe Wartezeiten (Ineffizienz)

Agile Controlling-Methoden im Vergleich

Methode	Einsatz	Fokus	Vorteile
Sprint Burndown	Sprint-Level	Fortschritt im Sprint	Einfach, visuell
Product Burndown	Projekt-Level	Release-Fortschritt	Überblick über Projekt
Burnup Chart	Projekt-Level	Scope + Fortschritt	Scope-Änderungen sichtbar
CFD	Kanban/Scrum	Prozess-Performance	Bottlenecks erkennbar
Velocity Tracking	Sprint-Level	Team-Produktivität	Prognose-Fähigkeit
Lead/Cycle Time	Prozess-Level	Effizienz	Prozessoptimierung

Praktische Anwendung

Sprint Review-Checkliste

Sprint Review - Burndown-Analyse
================================

Sprint: #5 (15.01. - 31.01.2026)
Velocity: 24 SP

Burndown-Analyse:
----------------
- Ziel erreicht? [x] Ja  [ ] Nein
- Ist-Linie folgt Ideal-Linie? [x] Ja  [ ] Nein
- Scope Creep erkannt? [ ] Ja  [x] Nein
- Team-Geschwindigkeit stabil? [x] Ja  [ ] Nein

Probleme erkannt:
----------------
- Tag 7: Task neu hinzugefügt (Begründung: kritischer Bug)
- Tag 12: Ausfall Teammitglied (kein Auswirken auf Ziel)

Maßnahmen für nächsten Sprint:
-----------------------------
- Vor Sprint-Start: Klärung aller Anforderungen
- Reserve-Kapazität für unvorhergesehene Aufgaben (10%)

Dashboard-Template

graph TD
    subgraph "Agile Controlling Dashboard"
        direction TB
        SB["Sprint Burndown"]
        PT["Product Burndown"]
        VT["Velocity Trend"]
        CFD["Cumulative Flow"]
    end

Zusammenfassung

Agile Controlling-Methoden unterscheiden sich grundlegend von klassischen Methoden:

Klassisches Controlling

Detaillierte Planung
Feste Meilensteine
EVA, MTA, KTA
Projektphasen

Agiles Controlling

Empirisches Vorgehen
Iterative Zyklen
Burndown/Burnup, Velocity
Sprints

Kerntools

Tool	Zweck	Frequenz
Sprint Burndown	Sprint-Fortschritt	Täglich
Product Burndown	Release-Fortschritt	Sprint-Ende
Velocity Tracking	Team-Produktivität	Sprint-Ende
Burnup Chart	Scope + Fortschritt	Sprint-Ende
CFD	Prozess-Performance	Täglich

Empfehlung

Nutzen Sie Sprint Burndown Charts für das operative Controlling im Sprint
Ergänzen Sie sie durch Product Burndown Charts für strategische Projektplanung
Verwenden Sie Velocity Tracking für Prognosen und Release-Planning
Ergänzen Sie bei Bedarf Burnup Charts für mehr Transparenz bei Scope-Änderungen
Nutzen Sie CFD für Kanban-Projekte zur Erkennung von Bottlenecks

Im nächsten Kapitel lernen Sie die Ursachenanalyse von Abweichungen kennen – ein essenzieller Aspekt für die effektive Steuerung von Projekten.