Discovery vs. Sprint Zero — was wann nötig ist

Discovery und Sprint Zero werden in App-Projekten regelmäßig durcheinandergeworfen — manchmal vom Auftraggeber, der die Phasen nicht kennt, manchmal vom Anbieter, der „Discovery” als Verkaufstrick einsetzt. Sie sind zwei verschiedene Phasen mit unterschiedlichem Ziel, unterschiedlichem Output und unterschiedlicher Notwendigkeit. Diese Klarstellung spart in der Praxis regelmäßig zwei bis vier Wochen Projektzeit.

Die zwei Phasen — kurze Definition

Beide passieren vor dem ersten Feature-Code, lösen aber zwei verschiedene Probleme:

• Discovery (1–3 Wochen). Klärt, was gebaut wird. Output: validiertes Problem, Top-5-Use-Cases, MoSCoW-Schnitt, Stack-Empfehlung, Erfolgs-Kriterien. Ergebnis ist ein Dokument, kein Code.
• Sprint Zero (1 Woche). Richtet ein, womit gebaut wird. Output: Repos, CI/CD-Pipeline, Designsystem-Skelett, Datenmodell-Erstentwurf, Auth-Setup, Tracking-Konzept. Ergebnis ist eine startklare Codebasis, kein Feature.

Discovery ist die Frage „bauen wir das Richtige?” — Sprint Zero ist die Frage „können wir morgen produktiv schreiben?”. Wer beide vermischt, beantwortet keine der beiden sauber. Mehr zur Phasen-Logik insgesamt im Sub-Guide Wie läuft eine App-Entwicklung ab?.

Was Discovery konkret liefert

Eine ordentliche Discovery erzeugt fünf Artefakte:

• Problem-Spec in einem Satz. „Endkunden in Branche X verlieren pro Woche Y Stunden, weil Z.” Nicht „wir wollen eine App machen”.
• Top-5-Use-Cases mit Aha-Moment. Welcher Klick-Pfad zeigt der ersten Nutzer:in, dass das Problem gelöst wird?
• MoSCoW-Liste. Must-have, Should-have, Could-have, Won’t-have-this-time. Mit klarer Definition, was „Must” wirklich heißt — siehe MVP oder direkt komplett.
• Stack- und Plattform-Empfehlung. Welche Codebasis, welche Plattform-Strategie, welche externen Dienste — mit Begründung, nicht aus Mode.
• Erfolgs-Kriterien. Woran erkennst du in drei Monaten, ob V1 funktioniert? Wenn die Antwort „Nutzer:innen verwenden es” lautet, fehlt die Schärfe.

Was Discovery nicht liefert: pixelgenaue Mockups, finale Daten-Modelle, vollständige Test-Pläne. Das wäre Sprint-Zero- oder Build-Arbeit, in der falschen Phase mit zu wenig Information.

Was Sprint Zero konkret liefert

Sprint Zero produziert eine Codebasis, in der Feature-Arbeit ab dem nächsten Tag laufen kann. Konkret:

• Repos und CI/CD. Build, Test, Lint, automatisches Deployment in eine Staging-Umgebung. Code-Review-Prozess definiert.
• Designsystem-Skelett. Token-System (Farben, Typografie, Spacing), Basis-Komponenten (Button, Input, Card). Im Idealfall sowohl in Figma als auch im Code.
• Datenmodell-Erstentwurf. Entitäten, Relationen, Migrations-Pipeline, erste Seed-Daten.
• Auth- und Tracking-Setup. Identity-Provider gewählt und integriert, Crash-Reporting eingerichtet, erste Analytics-Events instrumentiert.

Sprint Zero produziert ein leeres Haus mit Strom- und Wasseranschluss. Discovery produziert den Bauplan dafür, was im Haus passieren soll. Wer das Sprint-Zero-Setup auf „nebenher in Woche 1 des Builds” verschiebt, bezahlt das in Woche 4 mit verstopften Pipelines und uneinheitlichen Komponenten.

Wann Discovery nötig ist

Drei Konstellationen, in denen Discovery sich rechnet:

1. Mehrere Stakeholder mit unterschiedlichen Visionen. Geschäftsführung sagt A, Vertrieb sagt B, eigene Endkunden sagen C. Ohne Discovery baut das Team eines davon und verärgert die anderen zwei.
2. Unklare Wettbewerbslandschaft. Es gibt Anbieter, die das Problem teilweise lösen — aber niemand hat geprüft, was die genau machen, was sie weglassen, wie deine Differenzierung aussehen muss.
3. Erst-App des Auftraggebers. Wer noch nie eine App gebaut hat, hat keine Intuition für Scope-Disziplin, Plattform-Trade-offs oder Datenmodell-Tiefe. Discovery ist dort nicht Luxus, sondern Versicherung.

In allen drei Fällen sind die zwei bis drei Wochen Discovery-Aufwand der günstigste Posten im gesamten Projekt — sie verhindern Scope-Crash mitten im Build.

Wann du Discovery überspringen kannst

Genauso ehrlich: drei Konstellationen, in denen Discovery der falsche Schritt wäre.

• Wiederholungs-Build im selben Domänen-Kontext. Du hast bereits eine App in dieser Branche gebaut, das Problem ist klar, der Stack ist bewährt, die Spec besteht aus dem alten Backlog plus Delta-Updates.
• Klar geschriebenes Lastenheft mit validierten Use-Cases. Auftraggeber hat schon Endkunden-Interviews gemacht, Scope ist hart geschnitten, Ziel-KPI ist definiert. Hier wäre Discovery doppelte Arbeit.
• Validierter No-Code-Vorgänger. Es gibt einen Bubble- oder Retool-Pilot, der seit Monaten von echten Endkunden genutzt wird. Die Discovery hat in der Realität bereits stattgefunden — der Custom-Build muss „nur noch” das umsetzen, was sich bewährt hat. Mehr dazu in Custom-Dev vs. No-Code/Low-Code.

In allen drei Fällen geht es direkt in den Sprint Zero. Discovery wäre Zeitverschwendung — und eine, die du oft nur erkennst, wenn du sie unnötig durchgemacht hast.

Was schiefgeht, wenn beide vermischt werden

Zwei Anti-Pattern, die wir regelmäßig sehen:

• Discovery wird zu Sprint Zero gedehnt. Aus „wir sind in Discovery” werden vier Wochen, in denen das Team Mockups baut, Architektur-Diagramme zeichnet und drei Stack-Optionen vergleicht. Output: viel Papier, wenig Klarheit, und im Build immer noch keine startklare Codebasis. Discovery sollte ein Dokument abliefern, nicht ein Setup.
• Sprint Zero wird ohne Discovery gestartet. Das Team setzt Repos auf, Designsystem läuft, Auth-Provider ist gewählt — aber niemand hat geklärt, ob das Datenmodell zur Domäne passt. Drei Wochen später wird der erste Use-Case spec-falsch implementiert, und das Setup muss um die Hälfte umgebaut werden. Mehr zu Spec-Tiefe versus Prototyp im Sub-Guide Spec vs. Prototyp.

Sauberer Schnitt: Discovery liefert Dokumente, Sprint Zero liefert eine Codebasis. Beide haben ein klares End-Datum und ein konkretes Demoable.

Wenn du gerade entscheidest, ob dein Projekt Discovery braucht: beschreib uns die Situation in drei Sätzen — was die App tun soll, ob es einen Vorgänger oder ein Lastenheft gibt, wie viele Stakeholder mitreden — über das Kontaktformular. Wir antworten in 24 Stunden mit einer ehrlichen Einschätzung, ob Discovery sich bei dir rechnet. Mehr Kontext: Wie läuft eine App-Entwicklung ab? für die Phasen-Logik insgesamt, Spec vs. Prototyp für die Discovery-Output-Frage.