What a discovery sprint is
A discovery sprint is a short, time-boxed phase at the start of a software project where the team researches the problem before writing production code. It ends with a shared understanding of the users, the constraints, the risks, and a plan for what to build first. It also produces an estimate grounded in evidence instead of hope.
The idea is well established in public-sector digital work. The UK Government Digital Service manual puts it simply: before you commit to building a service, you need to understand the problem that needs to be solved. It also says plainly that you should not start building your service in discovery.
Why discovery lowers project risk
Software projects rarely fail because the code was hard. They fail because the team built the wrong thing, missed a constraint, or discovered a critical integration problem halfway through. Each of those is cheap to find in a conversation and expensive to find after months of development.
Discovery moves the expensive surprises to the front, when changing direction costs a few meetings rather than a rebuild. It also gives the people paying for the project a clear decision point. The GDS manual notes that it is not a failure to stop at the end of discovery if the research shows that is the best course. A discovery that saves you from a bad project has done its job.
Discovery also improves estimates. An estimate made before anyone has seen the current process is a guess with a number attached. After discovery, the team can point to the specific integrations, data volumes and user groups behind each part of the estimate, and you can see which assumptions would change the price if they turned out to be wrong.
What happens during a discovery sprint, step by step
Every discovery sprint is shaped to the problem, but most include the same core activities.
- Kickoff: agree on the goal, the decision the sprint must support, who the stakeholders are, and how success will be measured.
- Stakeholder interviews: leadership, the people who will run the system, and the people who will maintain it.
- User research: watch real users do the current task, in their real setting, with their real tools. Ask what they do, not just what they want.
- Process mapping: draw the current workflow end to end, including the workarounds and spreadsheets nobody mentions in the first meeting.
- Technical review: inventory existing systems, data, integrations, hosting and security requirements, and test the risky assumptions, such as whether an API really returns what the documentation says.
- Constraints: legal, regulatory, accessibility and records requirements, budget limits, and deadlines that cannot move.
- Prototyping: clickable sketches of the riskiest screens, tested with users to check understanding before anyone writes production code.
- Synthesis and readout: findings, a recommended scope for the first release, a phased roadmap, and an estimate.
Who should take part
A discovery sprint needs a small core team and access to the right people at the right moments. On the client side, that means a sponsor who can make decisions, a day-to-day contact who knows the current process, and time with real users. On the delivery side, it usually means a lead engineer and someone focused on research and design. Both need to hear the users directly, not through a summary.
Bring in the people who usually appear late and cause surprises: IT staff who run the systems you need to connect to, whoever handles security and privacy, and, for public bodies, the records custodian and the procurement office. Their constraints are cheaper to learn in week one than in month six.
Keep the group small enough to move quickly. A large steering committee turns discovery into a series of status meetings. Short, regular readouts to the sponsor, with decisions recorded as they are made, work better than one big presentation at the end.
What you should have at the end
A good discovery sprint ends with documents you could hand to any competent development team, not just the one that ran it.
- A one-page problem statement everyone has agreed to.
- Descriptions of the main user groups and what they need to get done.
- A map of the current process and the proposed one.
- A list of systems to integrate, with the known risks for each.
- A prioritized backlog for the first release, with what is deliberately left out.
- An estimate with its assumptions written down, and a clear recommendation to proceed, change course or stop.
How long a discovery sprint takes
Length depends on the size of the problem. The GDS service manual says around 4 to 8 weeks is typical for a government service discovery. For a focused business application with one main user group, a much shorter discovery is often enough. The point is to time-box it, so research does not expand to fill the calendar.
Keep the team small and the decision-makers close. Schedule user sessions in the first days, since recruiting and calendars are usually the slowest part. A discovery that cannot reach its users, or whose findings wait weeks for a meeting with the sponsor, loses most of its value.
Discovery for government projects
Public-sector discovery has extra constraints to surface. Accessibility rules apply from the first prototype. Records law decides how data must be kept, exported and eventually disposed of. Security requirements shape hosting and authentication choices. Procurement rules may decide how the build phase can be bought, which affects how the discovery findings should be written.
A discovery report that documents these requirements clearly can also strengthen a solicitation. When an agency understands its own problem, its statement of work is sharper, and the responses it receives are easier to compare.
Common objections to a discovery sprint
"We already know what we need." Sometimes that is true, and discovery will be quick. More often, the people requesting the software are not the people who will use it daily, and the first user interviews change the plan.
"It delays the build." It delays the first line of code, but it usually shortens the time to a useful release because the team stops building features that get thrown away.
"It costs money that does not produce software." It produces the plan and the evidence behind it. A fixed-price discovery is also a low-risk way to test whether you want to work with a development firm before signing up for a larger build.
How Foundry Peak runs discovery
Every Foundry Peak project begins with discovery, sized to the problem. For business clients that often means a short, fixed-scope engagement with on-site sessions in Northwest Florida or remote sessions elsewhere. For government clients we add records, accessibility and security requirements to the constraints review. Either way, you own the findings and can use them with any team.