A discovery sprint for a public service is a short, structured piece of work where a cross-functional team studies how residents actually experience a problem, tests what the team believes about it, and leaves with a decision, a documented problem statement and a named owner. If you have never run one, this guide covers how to run a discovery sprint for a public service in roughly two weeks, using the format that works for teams without a dedicated research budget.
Public services are expensive and politically visible to change. A benefit renewal that quietly fails is not a product metric problem, it is a resident who loses housing support. Discovery compresses the expensive phase, and it gives decision-makers something defensible to point at when the budget conversation comes back.
One warning before you start. “Discovery sprint” means two different things. To a software team it is a requirements-gathering activity that feeds a delivery sprint. To a managed service provider it is a sales qualification call. Nothing in what follows relates to either. This is service discovery: human-centred design applied to a public service challenge, closer to the TOPC sprint toolkit from the Centre for Public Impact or a GDS service assessment than to an agile ceremony.
Table of Contents
- What You Need
- A single decision the sprint has to support
- A right-sized problem focus area
- The people, with named roles
- Research materials prepared in advance
- Logistics: time, access, money and trust
- How to Run a Discovery Sprint for a Public Service Step by Step
- 1. Set one clear sprint decision
- 2. Recruit the right participants
- 3. Prepare the problem and research materials
- 4. Run structured user research
- 5. Map the service experience
- 6. Test and prioritise opportunities
- 7. Make the decision and document the next move
- Common Mistakes
- Frequently Asked Questions
- How long should a discovery sprint last?
- Who should attend a discovery sprint for a public service?
- Do we need to interview members of the public during discovery?
- What if stakeholders disagree about the best solution?
- How do you protect confidential information during a discovery sprint?
- What should happen after a discovery sprint ends?
- Conclusion
What You Need
Five things have to be in place before the sprint starts. Missing any one of them turns a discovery sprint into a very expensive meeting with sticky notes on it.
A single decision the sprint has to support
Write the decision on one page, in a sentence, and share it with everyone involved. “Do we build a self-serve portal for housing applications” is a decision. “Housing is a priority” is not. The decision statement should name the decision owner, the date by which it gets made, the constraints the answer has to respect, and the kind of evidence that would change the answer.
If a senior sponsor arrives with a solution attached, park it. Note the solution, keep it visible, and treat it as one candidate option rather than the frame. Sponsors who pick a solution before research is exactly how a public service ends up building the wrong thing for two years.
A right-sized problem focus area
The problem focus area is the boundary of what the sprint will look at, and it is the single most useful scoping tool in this whole method. It needs to be specific enough to research in two weeks and wide enough to matter.
Weak: “digital inclusion”. Strong: “how residents without a smartphone and reliable broadband submit an adult social care assessment, and what happens to their applications when they cannot”. One names a topic, the other names a person, a task and a failure point.
The people, with named roles
Typical sprint teams run eight to twelve people. Bigger and you lose the ability to hear a quiet frontline view; smaller and the perspective narrows. People in the room for the full sprint are not the same as people you interview, and both lists matter.
| Role | What they own | Time in the sprint |
|---|---|---|
| Executive sponsor | Removes blockers, protects the budget, holds the political line | Briefing and decision session |
| Service owner | The decision, the constraints, the service metrics | Full sprint |
| Facilitator | The process, the time-boxing, neutral on outcomes | Full sprint |
| Frontline staff | How the service works today, including the workarounds | Full sprint where possible |
| Service users or community partners | Lived experience, recruitment, interpretation of findings | Research sessions and review |
| Data officer or analyst | Data inventory, demand data, quality caveats | Half to full sprint |
| Accessibility specialist | Access requirements, inclusive research, testing criteria | Full sprint |
| Delivery or tech partner | Feasibility read on the options, legacy system constraints | Later stages |
| Product owner (to be named) | Takes the outcome forward after the sprint | From the midpoint review |
Name a product owner early even if the person is not confirmed. If the sprint finishes and nobody owns the outcome, the work dies quietly, usually within a quarter.
Research materials prepared in advance
The facilitator assembles these so the team argues with evidence rather than memory: a one-page service brief, current service performance data, a data inventory showing what exists and how good it is, an interview guide, a participant consent and confidentiality note, and a source list participants are invited to challenge.
A data inventory is worth the half day it takes. List each dataset the service generates, who holds it, what quality problems exist, and whether it can be shared outside the department. Half of what a service team assumes about its own demand turns out to live in a spreadsheet somebody maintains by hand.
Logistics: time, access, money and trust
| Format | Length | Team size | Use it when |
|---|---|---|---|
| Focused workshop | 1 day | 6 to 8 | A single known question about an existing service, not a service redesign |
| Classic sprint | 5 working days | 6 to 8 | You need a decision fast and the problem is reasonably well understood |
| Extended sprint | 10 working days | 8 to 12 | A contested or unclear problem where residents must be recruited properly (recommended for public services) |
| Programme | 4 to 20 weeks | 10 to 15 | Multiple services, heavy co-design, or a commitment to build and launch inside the same piece of work |
Money is the constraint that stalls most public-service sprints, so plan it early. Compensating community participants is not optional. People on low incomes, shift workers and carers cannot absorb an unpaid two-hour session plus travel, and skipping compensation skews your sample toward whoever can afford to be in the room. Budget roughly in the tens of pounds per session, plus a wider range for harder-to-reach groups, and route it through your existing expenses or community engagement budget rather than waiting for a new fund.
Also sort out accessibility before invitations go out: interpreters booked in advance rather than on the day, translated materials, a quiet room for sessions that need one, transport or remote access for anyone who cannot travel, and the flexibility to run sessions outside nine-to-five for people with caring or shift work. A sprint that hears only from residents who can attend a Tuesday afternoon is not research, it is confirmation.
How to Run a Discovery Sprint for a Public Service Step by Step
Seven stages, and the order matters because each one produces the input the next one needs. Skipping straight to stage six is the most common way these fail.
1. Set one clear sprint decision
Start by converting the broad service challenge into one decision the sprint must support: whether to develop a prototype, change an existing process, redirect funding, or commission further research on a new channel. Name the owner of that decision and the date it gets made, because a decision without a date is a discussion.
Record the constraints the answer has to live inside: statutory duties, existing system limits, budget envelope, staffing, union agreements, anything already mandated by policy. Then write down what evidence would count as useful, which means being explicit about what would prove the current approach is fine. Without that symmetry, the team unconsciously researches only what it wants to hear.
You know this stage worked when the sponsor can answer, in one sentence, what the sprint decides and when.
2. Recruit the right participants
A public-service sprint needs a mix that most private-sector discovery exercises do not: frontline staff who handle the exceptions, subject-matter experts who know the policy, service users or representatives of the affected community, an accessibility specialist, delivery staff, and the decision-maker.
Frontline staff are non-negotiable. The people doing the work know where the process breaks, and they rarely write it down. A journey mapped without them shows the official process, which is the one that works for the easy cases.
Preparing a mixed-familiarity group takes work. Send the brief a week ahead with three specific questions, tell service users only that the session is about their experience and that they will be paid, and brief the facilitator on the policy context. Compensate community participants, including their preparation time, and recruit through the organisations those residents already trust rather than through open sign-ups on a council webpage, which mostly returns digitally confident people.
One sponsor, and no more than two, should be present for the research sessions. If every executive attends, the frontline staff stop speaking and the service users read the room.
3. Prepare the problem and research materials
The service brief should be one page and cover the current user pathway, the service performance data, the pain points already known, the relevant policy and statutory duties, the team’s assumptions stated plainly so they can be attacked, and the open questions the sprint needs to close.
Assumptions get their own visible list. “Residents abandon because the form is long” is an assumption. “Our call centre handles about a third of reassessments” might be a fact, and the data officer should be able to confirm it in the first morning.
Write the interview guide as open questions about behaviour, not opinions about a solution. Personas, if you use them, come from the evidence you are about to gather rather than from a workshop in which confident people describe a hypothetical resident. And put a source list in the room: every claim about the service, where it came from, who supplied it. People find gaps in that list faster than you expect, and those gaps are findings.
4. Run structured user research
Short interviews beat long ones. Fifteen minutes with a service user beats an hour in a workshop with stakeholders, because the person has time to describe the last time they did the thing rather than what they think should change. Add contextual observation wherever you can, ideally watching someone complete the task on their own device, and hold feedback sessions where several residents react to the same service step.
The prompts that work ask about behaviour and consequence: what made you call instead of using the online form, what you did when the site refused your login, how many times you had to explain your situation, what you told your landlord, what you gave up on. Never ask whether people like a predetermined idea, because the polite answer is yes.
On volume, product practitioners commonly use roughly five user conversations per week as a floor for credible evidence. Over a ten-day sprint that means somewhere between eight and twelve sessions with service users, plus a similar number with frontline staff. More sessions rarely beat better recruitment; ten people from four different postcodes and two who do not own a smartphone are worth more than fifteen from the same support group.
Watch for the recruitment bias problem, because it is the one that quietly invalidates a sprint. If every participant is digitally confident, the sprint will conclude that the problem is awareness, and the people who cannot complete the service will be absent from every conclusion the team draws.
5. Map the service experience
Synthesis happens the morning after the research, while the specifics are fresh. Cluster what you heard into themes, then build a shared service blueprint: the steps a resident takes, what they think and feel at each step, what the resident does that the service never sees, what staff do behind the counter, which systems and forms sit in the way, and where the process fails.
The work that gives the blueprint its value is marking the evidence. Use three states on every element: we heard this directly, we inferred it, we do not know. A blueprint that blurs those three states is how a sprint turns two anecdotes into a strategy, and it is very hard to unpick afterwards.
Also record the back-channel work. Residents keep spreadsheets, screenshots and notes. Frontline staff keep unofficial records. Those workarounds tell you where the real demand is and what the service costs to run underneath the official process.
6. Test and prioritise opportunities
Turn findings into a short list of opportunity statements, each one a sentence connecting an observed problem to a possible response, with the evidence that supports it attached. Then prioritise using five lenses rather than a spreadsheet nobody trusts: impact on service outcomes, feasibility within your constraints, risk if you get it wrong, effect on equity between different groups, and fit with existing commitments.
Equity as its own lens is what separates a public-service sprint from a private one. An option that improves the average wait time while making life harder for the group with the least power to complain should not rank highly, and it will not if you score it deliberately.
Treat a prototype as a question rather than a proof. Sketches, paper flows, a clickable mock-up, a scripted walkthrough with staff, or a manual workaround run for a week will each test something different. A polished prototype convinces the room and tests almost nothing, because people critique it politely.
Rank the options by what they would take to be wrong: a two-hour sketch tested with five residents, or a six-month build. Do the cheap falsifications first.
7. Make the decision and document the next move
Hold the decision session separately from the sprint, ideally within a week of it ending while the evidence is still warm. The facilitator sorts the board into four columns: facts we gathered, interpretations we drew from them, ideas worth carrying forward, and commitments with a name and a date against each one.
The written record needs the chosen direction, the options rejected and why, the owner, the timeline, the success measures, the main risks, and the next piece of research or delivery. Circulate it to everyone who contributed, including the residents and community partners who gave their time. Publish a short summary where your authority normally publishes things, because a service that explains what it learned builds more trust than one that quietly ships a change.
Measure against service outcomes, not software output. Abandonment rates on applications, time from application to decision, the volume of avoidable calls, the number of people helped without a phone call, the error rate that causes a correction notice. Those are the numbers the elected member will remember, and they are the ones that tell you whether the discovery work mattered.
Common Mistakes
These seven failures account for most public-service discovery sprints that produce nothing useful, and each has a straightforward correction.
Starting with a predetermined solution. The sponsor presents an app, the sprint becomes a demo day, and research becomes a formality. Correct it at the briefing: the proposed solution goes on the board labelled “candidate, not decision”, and nobody presents it until stage six.
Confusing stakeholder preference with user evidence. A council director who prefers an app is not a data point. Put every stakeholder preference in a separate column from what residents told you, and only let the first column merge into the second when a resident says the same thing unprompted.
Inviting only senior leaders. The session is polished, well-informed about nothing, and produces a blueprint of the official process. Correct the list by asking each service to nominate two frontline staff who handled a difficult case last week, and protect their time in the diary so it is not quietly reassigned.
Over-researching and never deciding. A sprint that produces a hundred-page report and no decision has failed, however good the research was. Time-box the whole thing and end stage seven with a decision or an explicit no-decision and the evidence needed to reverse it.
Excluding the people the service fails. Recruiting through the council website delivers the digitally confident and reproduces the bias the sprint was meant to remove. Recruit through community organisations, compensate participants, and check your sample against who actually struggles with the service today.
Treating accessibility as a final check. Accessibility reviewed after the sprint cannot change the outcome, only the cost of it. Build access requirements into recruitment, the research sessions, the prototype criteria and the success measures from day one, and let the accessibility specialist hold a veto on testing with inaccessible materials.
Running a sprint when you should not. Some situations do not need discovery. A policy decision already mandated by statute, a purely technical fault with a known fix, a legal deadline with no discretion, or a service that has been researched twice already. Running a sprint there produces theatre and burns the goodwill you will need next time.
One implementation tip worth keeping: put the decision meeting in the diary before the sprint starts. A scheduled date with a named decision owner at the other end is the cheapest thing you can do to protect a sprint from ending in a report nobody reads. It also forces the service owner to decide what the sprint is for, which is the question you wanted answered in the first place anyway.
Frequently Asked Questions
How long should a discovery sprint last?
Five working days works when the problem is reasonably well understood and the decision is urgent. For most public services, plan ten working days: five for research and synthesis, five for prioritising, testing and the decision session. Recruitment of residents usually sets the floor, not the analysis. One-day workshops suit a single narrow question about an existing service, not a service redesign.
Who should attend a discovery sprint for a public service?
Eight to twelve people: a service owner, a facilitator, frontline staff, a subject expert, an accessibility specialist, a data officer, a delivery or tech partner, one or two sponsors, a community partner, and service users or representatives of the affected community. Service users should be interviewed or tested with rather than asked to sit through the full sprint, and compensation for their time should be budgeted.
Do we need to interview members of the public during discovery?
Yes, if the service touches the public at all. Everything else tells you how the service is supposed to work. Aim for eight to twelve conversations with residents across a ten-day sprint, recruited through organisations those residents already trust rather than through an open council sign-up. Without resident contact, the sprint can only confirm what the team already assumed when the work started.
What if stakeholders disagree about the best solution?
Separate the disagreement into its parts, because it is usually three disagreements wearing one coat. There is a factual disagreement, which gets resolved by evidence; a values or priority disagreement, which the sponsor decides openly; and a preference disagreement, which is recorded and not treated as a finding. Write the rejected options and the reason into the decision record so the argument does not restart in a later meeting.
How do you protect confidential information during a discovery sprint?
Use anonymised or synthetic data wherever possible, agree a confidentiality rule with participants at the start of every session, and keep identifiable case details out of sticky notes and wall displays. A short data sharing agreement with any partner organisation covers what leaves the building and how it is destroyed. If the sprint touches personal data, health records or legally privileged material, involve your data protection officer before the first session, not after.
What should happen after a discovery sprint ends?
Circulate the decision record within a week, name a product owner who has authority over the roadmap and budget, and publish a short plain-language summary of what you learned. Book the follow-up work as a delivery plan with success measures tied to service outcomes such as application abandonment or wait time. If no owner can be named, treat the sprint as an honest research exercise and say so, rather than leaving a prototype nobody maintains.
Conclusion
Start with one page and one sentence: the decision this sprint has to support, who owns it, and by when. Then invite the decision owner, the two frontline staff who handled a hard case last week, the delivery lead, the accessibility specialist and the residents who actually struggle with the service today.
Book the decision meeting before you send the invitations. Everything else in the sprint is preparation for that room, and a room with a date in it is the difference between discovery and a very well-documented way of changing nothing.
