Discovery Sprint: Planung vor der Entwicklung

Was es ist

Der Sprint bündelt die Informationen, die nötig sind, um eine Produktentscheidung zu strukturieren. Er kann das Geschäftsziel, den aktuellen Prozess, Nutzergruppen, verfügbare Daten, bestehende Systeme, vorrangige Journeys und frühe Machbarkeitsfragen untersuchen. Der genaue Umfang wird schriftlich vereinbart und spiegelt die Materialien und Personen wider, die dem Auftrag zur Verfügung stehen. Statt ein langes Dokument um seiner selbst willen zu erstellen, konzentriert sich Discovery auf Entscheidungen: was jetzt untersucht werden sollte, was validiert werden muss, welche Annahmen den Plan tragen und was noch nicht als Zusage behandelt werden sollte. Ein Discovery Sprint kann eine priorisierte Problemstellung, einen Entwurf der User Flows, ein Entscheidungsprotokoll, eine Abhängigkeitskarte und einen empfohlenen Umfang für die nächste Phase liefern. Produktionsentwicklung, finales UI-Design und ein vollständiger Architekturaufbau können als separat vereinbarte Ergebnisse folgen.

Für wen es gedacht ist

Ein Discovery Sprint eignet sich für Teams, die:

• eine Produktidee oder ein betriebliches Problem haben, aber ein klareres Briefing benötigen, bevor sie eine Schätzung für die Entwicklung anfragen
• zwischen mehreren möglichen User Journeys, Funktionen oder Marktprioritäten entscheiden müssen
• Gründer, Product Owner und technische Beteiligte auf dieselben Annahmen stützen müssen
• Abhängigkeiten und Entscheidungslücken erkennen möchten, bevor sie Budget, Aufwand von Dienstleistern oder einen Lieferzeitplan festlegen

Was es zu klären hilft

Discovery hilft zu klären:

• welches Problem, welcher Zielnutzer und welche vorrangige Journey die nächste Phase verankern sollten
• was über den aktuellen Zustand bekannt ist und welche Fragen noch Nachweise, Recherche, Zugang oder eine Entscheidung erfordern
• welche Annahmen, Integrationen, Inhalte, Freigaben und Drittanbieter-Abhängigkeiten die Lieferung beeinflussen könnten
• ob der nächste sinnvolle Schritt ein Blueprint, eine UX/UI-Ausrichtung, ein MVP-Umfang, eine technische Bewertung oder ein anderer Auftrag ist

Was ist enthalten

• Schriftliche Bestätigung der Discovery-Fragestellung, der verfügbaren Materialien, der Beteiligten und der Entscheidungsgrenze
• Strukturierte Prüfung des aktuellen Zustands, der Zielnutzer, vorrangigen Journeys, bekannten Einschränkungen und frühen Machbarkeitsfragen
• Eine Aufstellung von Annahmen, Abhängigkeiten, offenen Fragen und Entscheidungen, die einen benannten Verantwortlichen brauchen
• Eine praktische Priorisierung des Problems und der User Flows, die für die nächste Phase am relevantesten sind
• Verständliche Empfehlungen für einen realistischen, fokussierten nächsten Umfang
• Ein Übergabegespräch, das Erkenntnisse, Grenzen und sinnvolle nächste Schritte erläutert

Was nicht enthalten ist

• Produktionsentwicklung, finales UI-Design, ein vollständiges Designsystem oder ein kompletter Architekturaufbau, sofern nicht separat vereinbart
• Eine Zusicherung von geschäftlichem Erfolg, technischer Machbarkeit, endgültigem Budget, Verfügbarkeit von Dienstleistern oder Liefertermin
• Unbegrenzte Recherche, Workshops, Konzepte, Interviews oder Überarbeitungen über den vereinbarten Auftrag hinaus
• Formelle Rechts-, Compliance-, Investitions- oder Marktforschungsberatung
• Automatische Umsetzung jeder in der Discovery identifizierten Idee

Wann man es wählt

Wählen Sie einen Discovery Sprint, wenn die wichtigste Frage noch lautet, was gebaut werden soll, für wen und warum. Er ist nützlich vor einem MVP, einem größeren Neubau, einem neuen internen Tool oder einer Änderung an einer Customer Journey. Er kann auch helfen, wenn ein Team bereits Schätzungen erhalten hat, die widersprüchlich wirken, weil der zugrunde liegende Umfang noch nicht klar ist. Weniger nützlich ist Discovery, wenn die Produktgrenze bereits feststeht und das Team lediglich eine definierte Funktion geliefert haben möchte; in diesem Fall ist ein fokussierter Entwicklungsumfang möglicherweise besser geeignet. Der Sprint funktioniert vor allem dann gut, wenn relevante Entscheidungsträger teilnehmen können, aktuelle Materialien geteilt werden können und das Team bereit ist, manche Ideen als künftige Möglichkeiten statt als sofortige Zusagen zu behandeln.

Unser Ansatz

Wir beginnen damit, die Entscheidung zu vereinbaren, die der Sprint unterstützen soll. Die Arbeit bewegt sich dann vom aktuellen zum angestrebten Zustand: was Nutzer erreichen möchten, wo das heutige Erlebnis oder der heutige Prozess scheitert und wie eine nützliche nächste Journey aussehen könnte. Wir machen Annahmen sichtbar, statt sie in einem künftigen Entwicklungsplan zu verstecken. Abhängigkeiten wie Daten, Inhalte, Anbieter, Zugänge, interne Freigaben und bestehende Systeme werden mit den Fragen dokumentiert, die sie aufwerfen. Frühe Empfehlungen werden mit ihren Nachweisen und offenen Fragen vorgestellt, damit ihr Gewicht klar ist. Stattdessen trennt die abschließende Übergabe beobachtete Informationen, Arbeitsannahmen, Einschränkungen und nächste Entscheidungen. Das gibt einem Team eine Grundlage, um einen fokussierteren Blueprint, eine Designausrichtung, ein MVP oder eine technische Bewertung zu wählen, wobei späterer Umfang, Aufwand und Zeitplan mit wachsenden Nachweisen verfeinert werden.

Häufig gestellte Fragen

Verwandte Artikel