Agile und Scrum – was ist eigentlich der Unterschied? — Praxisnahes Grundlagenwissen für Entwicklungsteams

Einleitung

In diesem Artikel ordnen wir die Beziehung zwischen Agile und Scrum und fassen das Mindestwissen zusammen, das für die praktische Arbeit erforderlich ist. Der Artikel richtet sich an Menschen, die neu in ein Team einsteigen oder ihr autodidaktisch erworbenes Wissen aktualisieren möchten.

Was ist Agile?

In einem Satz

Agile ist keine spezifische Methode, sondern eine „Denkweise" und „Werteorientierung" in der Softwareentwicklung. Der Ausgangspunkt ist das „Agile Manifesto" (Manifest für agile Softwareentwicklung), das 2001 von 17 Softwareentwicklern veröffentlicht wurde.

Die vier Werte

Das Agile Manifesto drückt aus, dass die rechte Seite mehr wertgeschätzt wird als die linke.

Wichtig: Es wird nicht gesagt, dass die linke Seite keinen Wert hat. Beide Seiten haben ihren Wert, aber wir legen mehr Gewicht auf die rechte Seite – das ist die agile Haltung.

12 Prinzipien (Auszug)

Hinter dem Manifest stehen 12 Prinzipien. Man muss sie nicht alle auswendig kennen, aber die drei am häufigsten zitierten sind:

1. Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.
2. Änderungen der Anforderungen sind willkommen, selbst spät in der Entwicklung.
3. Funktionierende Software wird häufig geliefert, im Rhythmus von einigen Wochen bis zu einigen Monaten, wobei kürzere Zeitspannen bevorzugt werden.

„Funktionierende Software in kurzen Zyklen liefern" und „Veränderungen willkommen heißen" – diese beiden Punkte lassen sich als Kern von Agile bezeichnen.

Was ist Scrum?

Verhältnis zu Agile

Genau hier kommt es oft zu Verwechslungen. Als Diagramm dargestellt sieht es so aus:

Agile (Denkweise / Werte)
├── Scrum (Framework) ← am weitesten verbreitet
├── XP (Extreme Programming)
├── Kanban
└── Weitere...

Mit anderen Worten: Scrum ist ein konkretes Framework zur Umsetzung von Agile. Agile ≠ Scrum, und die korrekte Beziehung lautet Scrum ⊂ Agile.

Das Scrum-3-5-3

Scrum besteht aus „3 Verantwortlichkeiten (Accountabilities), 5 Events und 3 Artefakten". In der Version 2020 wurde der frühere Begriff „Rollen" durch „Verantwortlichkeiten" ersetzt, und jedes Artefakt erhielt ein Commitment (Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done).

Die 3 Verantwortlichkeiten

• Product Owner (PO): Verantwortlich für die Maximierung des Produktwerts. Entscheidet über die Prioritäten, was gebaut wird.
• Scrum Master (SM): Unterstützt das korrekte Funktionieren von Scrum. Coach des Teams und Person, die Hindernisse beseitigt.
• Developer: Die Menschen, die das Produkt tatsächlich bauen. Ingenieure, Designer, QA usw.

Die 5 Events

Die 3 Artefakte

• Product Backlog: Eine priorisierte Liste aller gewünschten Arbeiten. Wird vom PO verwaltet.
• Sprint Backlog: Die Liste der Arbeiten für den aktuellen Sprint. Wird von den Developern verwaltet.
• Increment: Das im Sprint fertiggestellte, funktionierende Produkt.

Der Sprint-Zyklus

[Planning] → [Entwicklung + Daily × N Tage] → [Review] → [Retro] → Nächster Sprint

Dieses Wiederholen des Zyklus in einem festen Zeitrahmen ist der grundlegende Rhythmus von Scrum.

Scrum anhand konkreter Beispiele vertiefen

Ab hier schauen wir uns Teile, die durch abstrakte Erklärungen allein schwer zu greifen sind, anhand eines fiktiven Produkts genauer an.

Verantwortlichkeiten vertiefen

Product Owner (PO) — Lenas Tag

Die Aufgabe des PO wird oft mit „Prioritäten entscheiden" in einem Satz beschrieben, ist in der Realität aber viel unübersichtlicher. Ein typischer Tag von Lena, der PO des FitLog-Teams:

• Morgen: Sichtet Nutzungsdaten des letzten Releases, identifiziert Screens mit hoher Absprungrate. Sortiert Anfragen, die vom Customer-Success-Team eingegangen sind.
• Nachmittag: Trifft sich mit Stakeholdern (Marketing, Führungsebene) und gleicht Q3-Geschäftsziele mit dem Product Goal ab.
• Zwischendurch: Antwortet sofort auf Entwicklerfragen wie „Diese Spezifikation – wäre diese Implementierung leichter umzusetzen, was meinen Sie?"
• Wöchentlich: Verfeinert das Backlog und konkretisiert die Akzeptanzkriterien für die obersten Einträge.

Der entscheidende Punkt: Der PO trägt sowohl den „Nutzerwert" als auch den „Geschäftswert". Um eine fundierte Entscheidung zu treffen, welches Feature zuerst kommt, muss er User Research, Datenanalyse und Führungsgespräche miteinander verbinden.

Scrum Master (SM) — Beispiele für Thomas' Interventionen

Der SM wird oft als „Moderator von Meetings" betrachtet, aber das Wesentliche ist ein Coach, der die Selbstorganisation des Teams herausarbeitet. Was Thomas, der SM des FitLog-Teams, tatsächlich tut:

• Bemerkt, dass Entwicklerin A im Daily Scrum täglich sagt „Gestern habe ich wieder diesen Bug untersucht", und spricht sie im 1-on-1 an: „Kommst du nicht weiter? Brauchst du Hilfe?"
• Beobachtet, dass zwischen PO und Developern bei der „Interpretation der Spezifikation" immer wieder Missverständnisse entstehen, und bringt dieses Problem in der Retro auf die Agenda.
• Stoppt direkte „Bitte dringend helfen!"-Anfragen anderer Abteilungen an die Developer und macht die Regel „Anfragen laufen über den PO" wieder klar.
• Schlägt vor, die Form der Scrum Events zu überdenken, wenn sich das Team eingespielt hat (z. B. das Format des Daily Scrum ändern).

Der SM ist eine Rolle, die nach außen hin wenig zu tun scheint, aber die Umgebung des Teams kontinuierlich gestaltet. „Der SM wirkt neuerdings ziemlich beschäftigungslos" kann ein gutes Zeichen sein, dass das Team beginnt, selbstorganisiert zu laufen.

Developer — Was bedeutet „selbstverwaltend"?

Im Scrum Guide 2020 wird das gesamte Scrum Team als selbstverwaltend (self-managing) beschrieben. Bei den Developern zeigt sich Selbstverwaltung konkret wie folgt:

• „Was" im Sprint getan wird, wird in Absprache mit dem PO entschieden, aber „wie" es umgesetzt wird, entscheiden die Developer.
• Aufgaben werden nicht von oben zugeteilt, sondern von den Developern selbst gezogen.
• Schätzungen werden von den Developern vorgenommen (nicht vom PO oder Vorgesetzten).
• Die Verantwortung, die Qualitätsstandards (Definition of Done) einzuhalten, liegt bei den Developern.

Wenn iOS-Developer Lukas bemerkt „Diese API antwortet zu langsam und schadet der UX", spricht er sich direkt mit Backend-Developer David ab, um es zu verbessern – diese Art von horizontaler Zusammenarbeit, die sich natürlich ergibt, ist das Zeichen eines gesunden Scrum Teams.

Events vertiefen

Sprint Planning — Reales Ablaufbeispiel

Das Sprint Planning des FitLog-Teams für einen 2-Wochen-Sprint läuft so ab (Dauer ca. 4 Stunden):

Teil 1: Warum ist dieser Sprint wertvoll? (Sprint Goal festlegen)

PO Lena: „Ich möchte unser Ziel für diesen Sprint so formulieren: ‚Nutzer können den Verlauf ihrer Trainingsaktivitäten der letzten 30 Tage in einem Diagramm sehen.' Die Recherche letzten Monat hat gezeigt, dass Nutzer mit höherer Retention häufiger das Diagramm-Feature nutzen."

Das Sprint Goal wird am besten als zu erreichender Zustand ausgedrückt, nicht als Feature-Liste.

Teil 2: Was kann in diesem Sprint erreicht werden? (Auswahl der Backlog Items)

Zu den vom PO präsentierten Top-Items schätzen die Developer per Planning Poker und wählen eine Menge, die ihrer Kapazität entspricht.

Teil 3: Wie soll die ausgewählte Arbeit abgeschlossen werden? (Aufgabenzerlegung)

Die Developer zerlegen die ausgewählten Backlog Items in konkrete Tasks.

Developer Lukas: „Wenn ich das Item ‚Diagramm-Anzeige-Screen' aufschlüssle, ergeben sich 4 Tasks: API-Design, iOS-Implementierung, Android-Implementierung und E2E-Test. Ohne das API-Design können wir nicht parallelisieren, also sollte David am ersten Tag konzentriert daran arbeiten."

Daily Scrum — Gut vs. Schlecht

❌ Schlechtes Daily (wird zur Statusmeldung)

„Gestern habe ich an der API-Implementierung gearbeitet. Heute schreibe ich Tests. Es gibt keine Hindernisse."
„Ich habe die Screen-Implementierung vorangetrieben. Heute mache ich weiter."
…… (15 Minuten lang gleichförmig)

Das ist ein Statusbericht, keine Inspektion und Anpassung.

✅ Gutes Daily (Inspektion und Anpassung)

Developer Lukas: „Die Diagramm-Rendering-Bibliothek ist schwerer als erwartet. Um das Sprint Goal zu erreichen, möchte ich den Wechsel zu einer anderen Bibliothek prüfen. Ich brauche 2 Stunden für weitere Recherche nach dem Planning."
Developer David: „Dann kann ich meine API-Implementierung um einen Tag vorziehen und dir Unterstützung geben."
Developer Lukas: „Lass uns die Details zu zweit in 30 Minuten danach klären."

Der richtige Zweck ist ein Ort, an dem die Planung für den heutigen Handelns im Hinblick auf das Sprint Goal aktualisiert wird.

Sprint Review — Mehr als nur Demo

Ein verbreitetes Missverständnis beim Review ist „Demo der funktionierenden Software und fertig". Ein echtes Review ist ein Dialog mit Stakeholdern.

• Developer demonstrieren das funktionierende Increment
• Stakeholder probieren es aus und geben Feedback
• Externe Informationen werden geteilt: „Die Marktlage hat sich verändert", „Die Reaktion der Zielnutzer war anders als erwartet"
• Darauf basierend wird das Product Backlog für das Kommende angepasst

Das Review dient also nicht nur der „Inspektion der Vergangenheit", sondern auch als „Eingabe für die Zukunftsplanung".

Sprint Retrospective — Tipps, um leeres Ritual zu vermeiden

Retros werden oft als „man macht KPT (Keep/Problem/Try)" betrachtet, aber jedes Format ist in Ordnung. Das Format je nach Teamsituation zu wechseln ist sinnvoll, aber das ist ein Mittel, kein Zweck.

Varianten, die das FitLog-Team ausprobiert:

Und: Tries auf genau einen beschränken und zu Beginn des nächsten Sprints damit anfangen. „Alles gleichzeitig angehen" ist dasselbe wie nichts zu tun.

Artefakte vertiefen

Product Backlog — Die richtige Granularität von Items

Product Backlog Items (PBIs) werden häufig im User Story Format geschrieben:

Als [welche Art von Nutzer]
möchte ich [was tun]
damit [warum ich das tun möchte]

Gutes PBI-Beispiel für FitLog:

Titel: Diagramm zur Trainingsfortschritt der letzten 30 Tage anzeigen

Als Nutzer, der regelmäßig joggt, möchte ich eine Grafik meiner Laufdistanz der vergangenen 30 Tage sehen, weil ich meine Motivation durch die Visualisierung meiner Bemühungen aufrechterhalten möchte.

Akzeptanzkriterien:

• Ein „Verlauf"-Tab wird auf dem Startbildschirm hinzugefügt
• Die tägliche Laufdistanz der letzten 30 Tage wird als Liniendiagramm angezeigt
• Tage ohne Daten erscheinen als Lücke im Diagramm
• Antippen des Diagramms navigiert zum Detailbildschirm des jeweiligen Tages

❌ Schlechtes PBI-Beispiel: „Diagramm-Feature implementieren" ← unklar für wen und zu welchem Zweck

PBIs sollten idealerweise dem INVEST-Prinzip genügen (Independent / Negotiable / Valuable / Estimable / Small / Testable).

Sprint Backlog — Verbindung zum Product Goal

Das Sprint Backlog ist keine „Aufgabenliste", sondern ein Plan aus drei Elementen:

1. Sprint Goal (warum): Der in diesem Sprint zu erreichende Zustand
2. Ausgewählte PBIs (was): Items aus dem Product Backlog
3. Ausführungsplan (wie): Aufgabenzerlegung und Vorgehensweise

Sprint Goal: Nutzer können den Trainingsfortschritt der letzten 30 Tage im Diagramm einsehen
├─ PBI 1: Verlaufsdiagramm-Anzeige-Screen [8 pt]
│   ├─ Task: API-Endpunkt-Design
│   ├─ Task: iOS-Implementierung
│   ├─ Task: Android-Implementierung
│   └─ Task: E2E-Test
├─ PBI 2: Navigation zur Detailansicht per Diagramm-Tap [3 pt]
│   └─ ...
└─ PBI 3: Verbesserung der Anzeige bei leeren Daten [2 pt]
    └─ ...

Increment — Die „Definition of Done (DoD)"

Das Increment wird als „funktionierendes Produkt" beschrieben, aber was als fertig gilt, muss im Team klar definiert werden. Das ist die Definition of Done (DoD).

DoD-Beispiel des FitLog-Teams:

• Code Review mit mindestens 2 Approvals
• Unit-Test-Coverage von mindestens 80 %
• E2E-Tests bestanden
• Barrierefreiheitsprüfung abgeschlossen (VoiceOver / TalkBack)
• PM hat Akzeptanzkriterien geprüft und OK gegeben
• Entwurf der Release Notes erstellt

Was die DoD nicht erfüllt, gilt als „unfertig" und wird in den nächsten Sprint übertragen. 5 zu 100 % fertige Features auszuliefern ist besser als 10 Features zu 80 % anzuhäufen – das ist die Scrum-Denkweise.

Velocity — Die „Geschwindigkeit" des Teams messen

Wer bis hierher gelesen hat, fragt sich vielleicht: „Was war das [8 pt] neben den PBIs?" Das führt zum Thema Velocity, das für den praktischen Betrieb von Scrum wichtig ist.

Definition

Velocity ist die Gesamtgröße der Backlog Items, die ein Team pro Sprint abschließt. Sie wird allgemein wie folgt definiert:

Velocity = Summe der Story Points der PBIs, die in diesem Sprint die Definition of Done erfüllt haben

Wichtig dabei:

• Nur abgeschlossene PBIs werden gezählt (80 % fertig = 0)
• Die Einheit sind in der Regel Story Points (SP) (keine Stunden)
• Gemessen pro Sprint; häufig als gleitender Durchschnitt über mehrere Sprints betrachtet

Was sind Story Points?

Story Points stellen die relative Größe von Arbeiten dar. Anstatt absoluter Werte wie „Personentage" oder „Stunden" schätzt man durch Vergleich mit einer Referenzaufgabe: „Wie groß ist das im Vergleich zu jener Basisaufgabe?"

Häufig verwendet wird die Fibonacci-Folge (1, 2, 3, 5, 8, 13, 21...). Die zunehmenden Abstände spiegeln wider, dass „größere Aufgaben mehr Unsicherheit haben und eine feinere Unterscheidung keinen Sinn ergibt".

Schätzungsreferenz des FitLog-Teams:

Beispiel: Velocity-Verlauf des FitLog-Teams

Schauen wir uns die Ergebnisse des FitLog-Teams der letzten 6 Sprints an:

Sprint 1: 18 pt (abgeschlossene PBIs: 5 + 5 + 3 + 3 + 2)
Sprint 2: 22 pt (abgeschlossene PBIs: 8 + 5 + 5 + 2 + 2)
Sprint 3: 25 pt (abgeschlossene PBIs: 8 + 8 + 5 + 3 + 1)
Sprint 4: 23 pt
Sprint 5: 26 pt
Sprint 6: 24 pt
─────────────────────
Durchschnitt der letzten 3 Sprints: 24,3 pt ← aktuelle Velocity

Das Team schafft ca. 24 Punkte pro Sprint.

Verwendung von Velocity

Wenn sich die Velocity stabilisiert hat, ergeben sich folgende Einsatzmöglichkeiten:

1. Kapazität im Sprint Planning einschätzen

PO Lena: „Die Kandidaten-PBIs für den nächsten Sprint summieren sich auf 32 Punkte."
Developer Lukas: „Da unser letzter Durchschnitt 24 Punkte beträgt, ist es realistisch, die obersten 26 Punkte (8+8+5+3+2) zu übernehmen."

Statt „wir kriegen das irgendwie hin" ermöglicht das eine faktenbasierte Einigung.

2. Release-Pläne vorhersagen

Wenn das gesamte Product Backlog 180 Punkte umfasst und die Velocity 24 Punkte beträgt, ergibt sich die Schätzung 180 ÷ 24 = ca. 7,5 Sprints bis zur Fertigstellung.

Damit lässt sich Stakeholdern begründet erklären: „Wir können voraussichtlich Ende Q3 releasen."

3. Schätzgenauigkeit kontinuierlich verbessern

Wenn sichtbar wird, dass „auf 5 Punkte geschätzt, tatsächlich aber 10 Punkte Aufwand nötig waren", entsteht daraus Material für die Retro-Diskussion.

Häufige Anti-Patterns

Velocity ist nützlich, aber beim falschen Einsatz kann sie ein Team zerstören.

❌ Anti-Pattern 1: Velocity als KPI

„Dieser Monat muss die Velocity höher sein als letzten Monat", „Weniger als das andere Team bedeutet Faulheit" – das ist die schlimmste Verwendung.

Velocity ist ein teamspezifischer Relativwert, und ein teamübergreifender Vergleich ist bedeutungslos. Druck auf das Team, die Velocity zu steigern, führt nur dazu, dass Schätzungen aufgebläht werden – die echte Produktivität bleibt gleich (oder sinkt sogar).

❌ Anti-Pattern 2: Story Points = Zeit

Wenn man anfängt, „1 Punkt = 4 Stunden" als feste Umrechnung zu verwenden, verlieren Story Points ihre Bedeutung. Die Vorteile relativer Schätzung (Unsicherheit ausdrücken, Diskussion effizienter gestalten) gehen verloren, und es degeneriert zu einer simplen Aufwandsschätzung.

❌ Anti-Pattern 3: Teilpunkte für unfertige PBIs anrechnen

„Ein 8-Punkte-PBI ist zu 70 % fertig, also rechnen wir 5,6 Punkte an" – das darf nicht sein. PBIs, die die Definition of Done nicht erfüllen, zählen 0 Punkte.

Grund: Velocity ist eine Kennzahl zur Vorhersage, wie viel im nächsten Sprint abgeschlossen werden kann. Laufende Arbeiten einzuberechnen verfälscht die Vorhersage.

❌ Anti-Pattern 4: Werten direkt nach Teamveränderungen vertrauen

Wenn Mitglieder hinzukommen oder gehen oder sich der Tech-Stack ändert, wird die Velocity zurückgesetzt. Nach dem Aufbau einer neuen Teamkonstellation gilt als Faustregel: erst 3–4 Sprints durchführen, dann den Durchschnitt neu berechnen.

Die Option, Velocity nicht zu verwenden

In letzter Zeit verzichten immer mehr Teams auf die Verfolgung von Velocity. Als alternative Kennzahlen bieten sich an:

• Throughput: Anzahl abgeschlossener PBIs (keine Punkte, gleiche PBI-Granularität beibehalten und zählen)
• Cycle Time: Zeit von der Aufnahme bis zur Fertigstellung eines PBIs
• Lead Time: Zeit von der Erstellung bis zur Fertigstellung eines PBIs

Besonders in Kombination mit Kanban oder für reife Teams, die den Schätzaufwand reduzieren möchten, können diese Kennzahlen effektiver sein.

Wichtiges Glossar

Scrum/Agile hat viel eigene Terminologie, und ob man sie kennt oder nicht, beeinflusst die Kommunikationseffizienz im Team erheblich. Wir vertiefen sie anhand realer Beispiele.

Planning Poker

Was es macht

Planning Poker ist eine Technik, bei der das gesamte Team Story Points für PBIs schätzt. Statt dass ein erfahrener Ingenieur entscheidet „das sind 5 Punkte", legen alle Mitglieder gleichzeitig eine Karte auf und erzielen gemeinsam Konsens.

Warum das „Poker"-Format?

Um den „Ankereffekt" zu verhindern, bei dem man sich von der lautesten oder erfahrensten Person mitreißen lässt. Wenn jemand zuvor sagt „das sind doch 8 Punkte, oder?", fällt es anderen Mitgliedern schwer, „ich denke, es sind 3" zu sagen. Alle legen gleichzeitig ihre Karten auf – so wird das verhindert.

Ablauf (FitLog-Team-Beispiel)

Karten verwenden die Fibonacci-Folge (0, 1, 2, 3, 5, 8, 13, 21, ?, ☕). „?" bedeutet „weiß nicht", „☕" bedeutet „ich brauche eine Pause".

Schritt 1: PBI erläutern

PO Lena: „Als nächstes: ‚Push-Benachrichtigungen als Erinnerung senden'. Wenn ein Nutzer eine Zeit eingestellt hat und an diesem Tag noch keine Trainingseinheit eingetragen hat, bekommt er eine Benachrichtigung."

Schritt 2: Fragen und Antworten

Developer Lukas: „Kann der Benachrichtigungstext angepasst werden?"
PO Lena: „Nein, ein fester Text ist in Ordnung."
Developer David: „Planen wir, die bestehende Benachrichtigungsinfrastruktur auf der Server-Seite zu nutzen?"
PO Lena: „Ja, wir gehen von der bestehenden Infrastruktur aus."

Schritt 3: Alle legen gleichzeitig Karten auf

Schritt 4: Höchste und niedrigste Karte erklären lassen

Niedrigste, David: „Auf der BE-Seite ist es nur eine zusätzliche Anfrage an die bestehende Benachrichtigungsinfrastruktur, daher 3."
Höchste, Sarah: „Auf Android müssen 3 Dinge implementiert werden: Nutzereinstellungen speichern, periodischer Job und Benachrichtigungs-Handling. Beim letzten Mal ähnliche Arbeit hatte ich viel Mühe, daher 13."

Schritt 5: Erneute Abstimmung nach Diskussion

Nach der Diskussion konvergieren alle Richtung „8". Finales Ergebnis: 8 Punkte.

Hinweise

• Nicht zu schnell abstimmen: Karten erst zeigen, nachdem F&A die Annahmen angeglichen hat
• Abweichler nicht beschuldigen: Abweichungen entstehen durch Informationsunterschiede; diese zu teilen ist das Ziel
• Nicht zu viel Zeit aufwenden: Ziel 5–10 Minuten pro PBI. PBIs, auf die man sich nicht einigen kann, gehen zurück ins Refinement.

Backlog Refinement

Was es macht

Refinement ist die kontinuierliche Aktivität der Pflege des Product Backlogs. Konkret:

• Zu große PBIs aufteilen
• Akzeptanzkriterien für Top-PBIs konkretisieren
• Veraltete PBIs entfernen
• Schätzungen durchführen (wird oft als Planning-Poker-Session genutzt)

Wann es stattfindet

Der Scrum Guide definiert es nicht als eigenständiges Event, aber die meisten Teams reservieren wöchentlich 1–2 Stunden. Viele Teams planen es in der Mitte des Sprints.

Definition of Ready

Ein Konzept, das in der Praxis manchmal im Kontrast zur DoD diskutiert wird, ist die Definition of Ready. Die Idee: Wenn ein PBI durch Refinement den Ready-Zustand erreicht, kann es ins Planning mitgenommen werden.

Definition-of-Ready-Beispiel des FitLog-Teams:

• Im User-Story-Format verfasst
• Mindestens 3 Akzeptanzkriterien vorhanden
• Alle Teammitglieder verstehen den Inhalt
• Auf 8 Punkte oder weniger aufgeteilt
• Bei externen Abhängigkeiten wurde mit der abhängigen Seite abgestimmt

Das INVEST-Prinzip (Vertiefung)

Die 6 Eigenschaften, die ein gutes PBI erfüllen sollte – jeweils mit Beispielen.

User-Story-Hierarchie — Theme, Epic, Story, Task

Das Product Backlog ist eine eindimensionale Liste, aber in der Praxis denkt man oft in 4 Ebenen.

Theme: User Engagement verbessern
└─ Epic: Mechanismen zur Förderung der Trainings-Kontinuität
   ├─ User Story: Verlauf der letzten 30 Tage im Diagramm einsehen [8 pt]
   │  ├─ Task: API-Implementierung
   │  ├─ Task: iOS-UI-Implementierung
   │  └─ Task: Android-UI-Implementierung
   ├─ User Story: Erinnerungsbenachrichtigungen empfangen [8 pt]
   └─ User Story: Anzahl aufeinanderfolgender Trainingstage anzeigen [3 pt]

Als PBIs im Backlog erscheinen hauptsächlich Epics und User Stories.

Burndown Chart / Burnup Chart

Burndown Chart

Ein Diagramm, das den Verlauf der verbleibenden Arbeit während eines Sprints visualisiert. Es zeigt, wie sich der tatsächliche Fortschritt im Verhältnis zur idealen Linie (einer gleichmäßig abnehmenden Linie) verhält.

Verbleibende pt
24┤●
22┤  ●
20┤    ●─ Ideallinie ────
18┤      ╲╲
16┤        ●(Ist-Wert, leicht im Rückstand)
14┤          ●
12┤            ╲
 0┤──────────────●
    Tag1 Tag3 Tag5 Tag7 Tag10

Wenn der Ist-Wert dauerhaft über der Ideallinie liegt → Warnsignal für das Sprint Goal. Frühzeitig gegensteuern (Scope reduzieren, Unterstützung anfordern).

Burnup Chart

Ein Diagramm, das erledigte Arbeit und Scope auf getrennten Linien zeigt. Da es bei Scope-Änderungen übersichtlicher als ein Burndown ist, wird es häufig für die Verfolgung von Release-Plänen eingesetzt.

MVP und MMP

MVP (Minimum Viable Product)

Das minimale Produkt, das zur Validierung einer Hypothese benötigt wird. Ein Konzept, das durch Eric Ries' „The Lean Startup" bekannt wurde.

FitLog-MVP-Beispiel: „Nutzer öffnen die App, tragen manuell ihre Laufdistanz ein und können frühere Einträge in einer Liste sehen." Keine Diagramme, Benachrichtigungen oder Social Features. Damit wird die Hypothese validiert: „Werden Menschen für eine Trainings-Tracking-App bezahlen?"

MMP (Minimum Marketable Product)

Das minimale Produkt, das auf dem Markt verkauft werden kann. Eine Stufe reicher als das MVP. MVP richtet sich an interne/begrenzte Nutzer, MMP an die allgemeine Öffentlichkeit.

Timebox

Scrum Events haben maximale Zeitgrenzen. Das ist die Timebox.

Wirkung der Timebox:

• Verhindert Ausufern von Diskussionen: Begrenzte Zeit erzwingt Fokus auf das Wesentliche
• Verhindert Meeting-Aufblähung: Verlängerungen zulassen führt zu unbegrenztem Wachstum
• Früher fertig ist OK: Wenn das Ziel erreicht ist, darf das Meeting kürzer sein

Spike

Zeitboxed Work zur technischen Recherche oder Auflösung von Unsicherheiten. Ein Begriff aus XP, der auch in Scrum weit verbreitet ist.

Einsatzsituationen:

• „Unklar, ob das mit der neuen Bibliothek umsetzbar ist" → 1-Tag-Timebox zur Validierung
• „Die Refactoring-Kosten dieses Teils des bestehenden Codes sind nicht abschätzbar" → halben Tag recherchieren
• „Unklar, ob die API-Antwortzeit die Anforderungen erfüllt" → Prototyp bauen

Das Ergebnis eines Spikes ist Wissen, kein Code. Der zur Validierung geschriebene Code wird grundsätzlich verworfen.

WIP-Limit (Work In Progress Limit)

Eine Regel, die die Anzahl gleichzeitig laufender Arbeiten begrenzt. Stammt aus Kanban, wird aber zunehmend auch in Scrum-Teams übernommen.

Beispiel: „Maximal 3 Items gleichzeitig in der 'In Progress'-Spalte"

Wirkung:

• Fokus auf Abschluss: 3 Items vollständig fertigstellen ist wertvoller als 5 halb voranzutreiben
• Engpässe werden sichtbar: Wo es steckt, wird klar
• Reduziert Multitasking-Kosten: Kontextwechsel senkt die Produktivität erheblich

Technische Schulden (Technical Debt)

Ein von Ward Cunningham geprägtes Konzept, das die Situation mit Schulden vergleicht: Durch eine Abkürzung auf Kosten zukünftiger Wartbarkeit entsteht ein Zustand, für den später Zinsen (Mehraufwand) gezahlt werden müssen.

Arten:

• Bewusste Schulden: „Deadline geht vor, schlampig implementiert, später refactorn" – wissentlich gemacht
• Unbewusste Schulden: Entstehen durch mangelndes Wissen oder Designfehler
• Umgebungsbedingte Schulden: Entstehen relativ, wenn Umgebungstechnologien veralten (Legacy)

Weitere nützliche Begriffe

Häufige Missverständnisse und Stolperfallen

„Keine Dokumentation" ist falsch

Manche Teams interpretieren das Agile Manifesto „funktionierende Software vor umfassender Dokumentation" falsch und stürmen mit null Dokumentation voran. Richtig ist: Die für den Betrieb notwendige Dokumentation wird geschrieben.

„Kein Planen" ist auch falsch

Das Verlassen auf „Reagieren auf Veränderung" als Ausrede, um die Planung aufzugeben, ist ebenfalls falsch. Scrum hat Planung auf mehreren Ebenen (Product Goal, Sprint Goal, tägliche Planung). Agile bedeutet nicht kein Planen, sondern adaptives Planen.

Das Daily Scrum wird zum Statusbericht

Ein Daily Scrum, das sich in eine Fortschrittsberichterstattung an PM oder Management verwandelt hat, hat seinen ursprünglichen Zweck verloren. Das Daily ist ein Ort der Inspektion und Anpassung durch Developer, für Developer.

Die Sprint-Länge ändert sich ständig

„Dieses Mal sind wir busy, also 3 Wochen" oder „Lass uns 1 Woche ausprobieren" – diese Wechsel machen es unmöglich, Velocity (Teamgeschwindigkeit) zu messen. Die Sprint-Länge sollte fest sein.

Fälle, in denen Agile/Scrum nicht passt

Es ist kein Allheilmittel. In Situationen wie den folgenden kann ein anderer Ansatz geeigneter sein:

• Anforderungen sind vollständig fixiert und Änderungen treten kaum auf (z. B. regulatorische Compliance)
• Bereiche, in denen Sicherheit extrem wichtig ist und inkrementelle Releases nicht erlaubt sind
• Wenn das Team extrem groß ist und die Koordinationskosten überwiegen

Da es jedoch Skalierungsmethoden für großflächiges Scrum gibt (LeSS, SAFe usw.), ist es voreilig, sofort zu schlussfolgern: „Zu groß dafür."

Zusammenfassung

• Agile ist eine Denkweise und Werteorientierung. Der Kern ist „funktionierende Software in kurzen Zyklen liefern" und „Veränderungen willkommen heißen".
• Scrum ist ein repräsentatives Framework zur Umsetzung von Agile.
• Scrum besteht aus „3 Verantwortlichkeiten, 5 Events und 3 Artefakten" und wiederholt Sprints fester Länge.
• Nur die Form zu kopieren führt zu leerem Ritual. Werte verstehen kommt zuerst, das Framework danach.

Das Ziel ist nicht „Scrum zu machen", sondern „kontinuierlich wertvolle Produkte zu liefern". Das Framework als Werkzeug für diesen Zweck zu betrachten ist, glaube ich, der Schlüssel zu einer dauerhaften Beziehung damit.

Literatur

• Manifest für agile Softwareentwicklung
• Scrum Guide 2020
• Jeff Sutherland, „Scrum: Die Kunst, doppelt so viel in halb so viel Zeit zu erledigen"