Sprint in der mobilen Entwicklung: Wesen, Dauer und Planung

Was ist ein Sprint in der Entwicklung?

Sprint ist ein Timebox mit fester Dauer, an dessen Ende das Team ein gebrauchsfertiges Produktinkrement liefert. Das Konzept des Sprints ist die Grundlage von Scrum, wird aber auch in anderen Agile-Frameworks verwendet. In der mobilen Entwicklung ist ein Inkrement ein Build der Anwendung, der auf einem Gerät installiert, getestet und den Stakeholdern gezeigt werden kann. Ein Sprint kann nicht verlängert werden — wenn Aufgaben nicht abgeschlossen sind, werden sie in den nächsten Sprint verschoben.

Das Hauptmerkmal eines Sprints ist die feste Dauer. Das Team ändert das Sprint-Ziel nach der Genehmigung nicht. Dies bietet Vorhersagbarkeit: Die Stakeholder wissen, wann sie das Ergebnis erhalten. Innerhalb des Sprints entscheidet das Team, wie die Arbeit verteilt wird. Der Scrum Master schützt das Team vor externen Eingriffen — dem aktuellen Sprint werden keine neuen Aufgaben hinzugefügt. Laut Scrum Guide 2025 ist dies die einzige Möglichkeit, ein nachhaltiges Entwicklungstempo beizubehalten.

Ein Sprint besteht aus vier obligatorischen Ereignissen: Sprint Planning, Daily Scrum (tägliche Synchronisation), Sprint Review (Ergebnispräsentation), Sprint Retrospective (Prozessanalyse). Dazwischen liegt die Hauptarbeit: Aufgabenimplementierung, Tests, Code-Review. Dauer jedes Ereignisses ist direkt proportional zur Sprintlänge: Für einen 2-wöchigen Sprint dauert Planning 4 Stunden, Review 2 Stunden, Retro 1,5 Stunden, Daily 15 Minuten. Insgesamt nehmen die Rituale etwa 8 Stunden pro Sprint in Anspruch — 10 % der Arbeitszeit des Teams.

Scrum-Rituale des Sprints

Scrum-Rituale (Zeremonien/Ereignisse) sind strukturierte Teamtreffen innerhalb des Sprints. Sprint Planning zu Beginn, Daily Scrum jeden Tag, Sprint Review und Retrospective am Ende. Alle Ereignisse haben ein Timebox. Der Scrum Master stellt die Einhaltung des Timebox und des Fokus sicher. Das gesamte Scrum-Team nimmt an jedem Ritual teil: Product Owner, Scrum Master, Entwickler. Die Ausnahme ist das Daily Scrum (nur Entwickler nehmen teil, PO und SM sind optional).

Die Verbindung der Rituale zu den Sprint-Phasen: Planning gibt die Richtung vor (was und wie wir tun), Daily synchronisiert (wer macht was, welche Blocker gibt es), Review zeigt das Ergebnis (was wurde gemacht, was nicht), Retrospective verbessert den Prozess (wie der nächste Sprint besser wird). Die Retrospective auszulassen ist der häufigste Teamfehler: Wenn Fristen knapp sind, wird zuerst Retro geopfert. Dies führt zu Stagnation der Prozesse und Wiederholung derselben Fehler. Die Forschung von Scrum.org (2025) zeigt, dass Teams, die alle 2 Wochen Retro durchführen, die Velocity um 35 % schneller verbessern.

Sprint Planning: Iterationsplanung

Sprint Planning ist ein Teamtreffen zu Beginn des Sprints, bei dem festgelegt wird, was und wie gemacht wird. Der Product Owner stellt priorisierte Aufgaben aus dem Product Backlog vor. Das Team schätzt die Kapazität (verfügbare Zeit unter Berücksichtigung von Urlaub, Meetings, technischen Schulden) und wählt Aufgaben aus, die es während des Sprints abschließen kann. Das Ergebnis von Planning sind das Sprint Goal (Sprint-Ziel) und das Sprint Backlog (Aufgabenliste). Das Sprint Goal wird als kurzer Satz formuliert: „Bestellbildschirm und Zahlungsintegration via SBP implementieren.”

Velocity ist die Geschwindigkeit des Teams, gemessen in Story Points pro Sprint. Durchschnitt der letzten 3–5 Sprints. Laut Scrum.org (2025) hat ein Team von 5 mobilen Entwicklern (3 Android + 2 iOS) eine Velocity von 25–40 SP pro 2-wöchigem Sprint. Planning verwendet die Velocity als Obergrenze — sie nehmen 10–15 % weniger für unvorhergesehene Aufgaben (Code-Review, Incidents, Hilfe für andere Teams). Kapazität vs. Velocity: Kapazität sind „Personenstunden“, Velocity sind „Story Points“. Die Kapazität berücksichtigt Urlaub, Krankheit, Meetings. Die typische Verlustrate beträgt 25–30 % der Arbeitszeit, die für Nicht-Code-Aktivitäten aufgewendet wird.

Planning ist in zwei Teile gegliedert: „was“ (PO beschreibt Aufgaben, Team klärt) — 2 Stunden, und „wie“ (Team zerlegt und schätzt) — 2 Stunden. Für mobile Projekte wird bei „wie“ diskutiert: Kompatibilität mit Android-/iOS-Versionen, Notwendigkeit von Feature Flags, Auswirkung auf APK-/IPA-Größe, neue Berechtigungen. Planning-Poker-Technik wird zur Schätzung verwendet: Jeder Entwickler gibt seine Schätzung in Story Points (1, 2, 3, 5, 8, 13). Eine Abweichung von mehr als 2 Einheiten löst eine Diskussion der Gründe aus. Dies deckt versteckte Risiken in der Planungsphase auf, nicht mitten im Sprint.

Sprint-Ausführung: Daily Standup und Tracking

Daily Scrum (Standup) ist ein tägliches 15-minütiges Meeting zur Team-Synchronisation. Jeder Teilnehmer beantwortet drei Fragen: „Was wurde gestern gemacht?“, „Was plane ich heute zu tun?“, „Welche Blocker habe ich?“ Das Daily ist kein Statusbericht für den Manager, sondern ein Werkzeug zur Selbstorganisation des Teams. Wenn sich im Daily herausstellt, dass zwei Entwickler an derselben Aufgabe arbeiten — ist das ein Signal zur Umorganisation. Wichtig: Das Daily löst keine Probleme, sondern identifiziert sie — zur Lösung wird nach dem Daily ein separates Meeting einberufen.

Scrum Board (Sprint-Board) ist eine Visualisierung des Sprint Backlog. Spalten: To Do / In Progress / In Review / Done. Jede Aufgabe bewegt sich über das Board. Das Burndown Chart ist ein Diagramm der verbleibenden Arbeit nach Sprint-Tagen. Der ideale Burndown ist eine gerade Linie von total SP bis 0. Der tatsächliche Burndown ist ein stufenförmiges Diagramm unter Berücksichtigung des Aufgabenabschlusses. Ein fallender Burndown (unter der idealen Linie) bedeutet, dass wir im Rückstand sind. Problemsignal: Wenn bis zur Sprintmitte weniger als 30 % der Aufgaben erledigt sind — ist eine Anpassung erforderlich. Möglicherweise wurden Risiken nicht berücksichtigt oder Aufgaben überschätzt.

Für die mobile Entwicklung wird das Sprint-Tracking durch spezifische Faktoren beeinflusst: Build-Zeit (Android-Projekt-Build in CI kann 30+ Minuten dauern), Warten auf App Store / Google Play Moderation (wenn ein Build über TestFlight an Tester released werden muss), Kompatibilität mit verschiedenen Geräten (Tests auf 10+ Modellen benötigen Zeit). Tipp: Planen Sie 1 Tag Puffer am Ende des Sprints für finale Tests und den Release-Build ein. Dies reduziert das Risiko eines unvollständigen Sprints um 40 % laut Mind the Product (2025).

Sprint Review und Retrospective

Sprint Review ist eine Demonstration des Inkrements für die Stakeholder. Das Team zeigt einen funktionierenden Anwendungs-Build, keine Folien. Die Dauer beträgt 2 Stunden für einen 2-wöchigen Sprint. Der Product Owner überprüft die Einhaltung der Acceptance Criteria. Die Stakeholder geben Feedback, das das Product Backlog beeinflussen kann. Review ist kein Bericht, sondern ein Dialog: Stakeholder können Fragen stellen und Änderungen vorschlagen. Wichtige Regel: Sprint Review handelt vom Produkt, nicht vom Prozess. Zeigen Sie, was erreicht wurde, nicht wie es gemacht wurde.

Sprint Retrospective ist ein internes Teamtreffen zur Analyse des vergangenen Sprints. Format: Start Doing (was anfangen zu tun), Stop Doing (was aufhören zu tun), Continue Doing (was weiterhin tun). Die Dauer beträgt 1,5 Stunden für einen 2-wöchigen Sprint. Die Retrospective ist ein sicherer Raum zur Diskussion von Problemen. Regel: In der Retro werden keine technischen Details besprochen (dafür gibt es technische Meetings). Nur Prozess, Kommunikation, Werkzeuge, Kultur. Der Scrum Master moderiert das Meeting und stellt sicher, dass jeder Teilnehmer spricht.

Das Ergebnis der Retrospective sind 1–3 Verbesserungen für den nächsten Sprint. Wenn das Team das Problem „Code-Review dauert zu lange“ identifiziert hat — Action Item: „SLA für Review festlegen — 4 Stunden. Wenn Review nicht rechtzeitig erfolgt, erinnert der Entwickler in Slack.” Action Items müssen spezifisch, messbar und einer bestimmten Person zugewiesen sein. Laut Atlassian (2025) verbessern Teams, die ihre Retro-Action-Items umsetzen, die Velocity um 15–25 % in 3–4 Sprints. Teams, die dies nicht tun, stagnieren.

So wählen Sie die Sprintdauer

2 Wochen sind der Standard für die mobile Entwicklung. Die optimale Balance zwischen Vorhersagbarkeit und Flexibilität. Genug Zeit für: Planung, Implementierung von 3–5 mittleren Funktionen, Tests, Ergebnispräsentation. 1 Woche ist für Teams mit hoher Prozessreife und CI/CD. Erfordert schnelle Entscheidungen, minimale Bürokratie. Geeignet für Start-ups in der Frühphase, die schnell experimentieren müssen. Nachteil: hoher Overhead für Rituale (jede Woche Planning + Review + Retro = 7,5 Stunden).

3–4 Wochen sind für komplexe Projekte mit Hardware-Integration (Wearables, IoT, BLE-Geräte), langer Store-Moderation oder großen Migrationen (z. B. Übergang von RxJava zu Coroutines). Lange Sprints geben mehr Zeit für Tests, erhöhen aber das Risiko des „Wasserfall-Effekts“ — das Team verliert an Agile-Flexibilität. Empfehlung des Scrum Guide: 1 Monat nicht überschreiten. Wenn der Sprint länger ist, gibt es im Review zu viel Kontext und die Stakeholder können kein qualitativ hochwertiges Feedback geben.

Typische Sprint-Probleme

Problem 1: Scope Creep. Mitten im Sprint fügt der Product Owner eine neue „dringende und wichtige“ Aufgabe hinzu. Das Team stimmt zu — und der Sprint scheitert. Lösung: Das Sprint Goal ist ein Vertrag. Jede Änderung erfordert eine Überprüfung des Sprint Goal, was nur in Notfällen möglich ist. Die neue Aufgabe geht ins Product Backlog und in den nächsten Sprint. Wenn die Aufgabe wirklich kritisch ist, wird das alte Sprint Goal aufgehoben, der Sprint neu geplant, aber dies ist eine Ausnahme, keine Praxis. Scope Creep häufiger als einmal in 3 Sprints ist ein Zeichen für einen schwachen Product Owner.

Problem 2: Unvollständige Aufgaben. Am Ende des Sprints sind 50 % der Aufgaben In Progress, 20 % In Review, nur 30 % Done. Gründe: überschätzte Kapazität, unterschätzte Komplexität, ungeplante Bugs. Lösung: Analysieren Sie den Grund im Retro. Wenn Sie systematisch nicht hinterherkommen, erhöhen Sie nicht die Anzahl der Aufgaben im Planning, sondern reduzieren Sie sie. Teams, die 20 % weniger Aufgaben übernehmen, zeigen eine höhere Abschlussrate (80 %+ gegenüber 50–60 %). Checkliste für Planning: Für jede Aufgabe Acceptance Criteria, Definition of Ready und Abhängigkeiten zu anderen Aufgaben prüfen.

Problem 3: Formales Retro. Das Team führt Retro nur pro forma durch — 15 Minuten, allgemeine Phrasen, keine Action Items. Lösung: Ändern Sie das Format jedes Retros. Methoden: Sailboat (was bremst, was beschleunigt), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Weisen Sie Action Items mit Fristen und Verantwortlichen zu. Überprüfen Sie zu Beginn des nächsten Retros die Erledigung der vorherigen Action Items. Laut Atlassian (2025) generieren Teams, die verschiedene Retro-Formate verwenden, 50 % mehr nützliche Erkenntnisse.