A discovery sprint is a short, focused stretch of work, usually one to two weeks, that happens before anyone commits to building. Its job is to replace guesses with decisions: what the software must do, for whom, how it will be built, what could go wrong, and roughly what it will cost.
The name borrows from the design sprint, a five-day process Jake Knapp created at Google in 2010 and later ran with startups at GV; it is described in the 2016 book Sprint by Knapp, John Zeratsky, and Braden Kowitz. A design sprint tests one big idea with a prototype. A discovery sprint for a software project goes wider, because it has to produce a plan a team can build from.
The seven things you should hold at the end
1. A product brief
A few pages that state the problem, the users, the goals, what is in scope, what is explicitly out of scope, and how success will be measured. If two people on your side read it and disagree about what it means, it is not finished.
2. User flows
Diagrams of how each type of user moves through the product, step by step, including where they come from and what happens when something goes wrong. Flows expose missing screens and awkward hand-offs long before code does.
3. A prioritized backlog
The features written as small, testable items, in priority order, with a line marking what goes into the first release. Everything below the line is still recorded, so nothing is lost and nothing sneaks back in.
4. Wireframes or a prototype for the risky parts
Not every screen needs a design at this stage, but the flows that carry the most risk or the most money should exist as wireframes or a clickable prototype, ideally tried by a few real users.
5. A technical approach
An architecture sketch showing the main parts and how they connect, the hosting plan, the integrations and how each will be accessed, and an outline of the data. Significant choices are written down as short decision records, with the reasons, so they can be revisited later without guesswork.
6. A risk register
Every serious risk listed with how likely it is, how much it would hurt, and what will be done about it. The best discoveries go further and test the biggest risk during the sprint itself, for example by calling a third-party API that the whole project depends on.
7. An estimate range and a plan
Effort as a range, not a single number, with every assumption written next to it, plus a release plan and a recommended way to work together. An estimate without assumptions cannot be challenged, and an estimate you cannot challenge is not worth much.
| Deliverable | Answers the question | Mainly used by |
|---|---|---|
| Product brief | What are we building, and why? | Everyone |
| User flows | How will people actually use it? | Design, development |
| Prioritized backlog | What comes first? | Product owner, team |
| Wireframes or prototype | Will people understand it? | Users, design |
| Technical approach | How will it be built and run? | Development |
| Risk register | What could derail it? | Leadership, team |
| Estimate and plan | What will it cost, and when? | Leadership, finance |
How to tell whether discovery worked
- You could hand it to another team. The documents should be clear enough that a different studio could quote and build from them.
- You know what is not in the first release, and you agreed to it in writing.
- The riskiest assumption was tested, not just listed.
- The estimate has assumptions you can argue with, and the range is narrower than when you started.
What discovery is not
It is not a hundred-page requirements document that tries to predict every detail; those go stale before the first sprint ends. It is not a sales exercise with a fixed price for work nobody understands yet. And it is not wasted if you decide not to build: learning that an idea will not pay for itself, for the cost of a week or two, is one of the cheapest lessons in software.
What it asks of you
A few working sessions with the people who own the problem, quick answers to questions as they come up, access to the systems and data involved, and introductions to a handful of the people who will use the software. Most of the writing happens on our side; your part is the knowledge only you have.
Key points
- Expect seven outputs: brief, flows, backlog, wireframes, technical approach, risks, and an estimate with a plan.
- Estimates come as ranges with written assumptions.
- Good discovery tests the biggest risk instead of only listing it.
- The output should be useful even if you never build with us.
Sources
- GV, "The Design Sprint" (gv.com/sprint); Jake Knapp with John Zeratsky and Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (Simon & Schuster, 2016).
- Michael Nygard, "Documenting Architecture Decisions" (Cognitect blog, 2011).