An Introduction to Discovery Sprints

We recently launched a Discovery Sprint Guide to serve as an open source reference for others working in the public interest sector. This guide highlights methods to run a discovery phase within an organization to fully understand the problem. We hope that you are able to learn, contribute, and adapt this guide throughout your organizations.

Published in

U.S. Digital Service

9 min readFeb 26, 2021

Discovery sprints are a quick (between 2 to 4 weeks) way for our teams to understand the landscape, the people, and the root causes of any issues of importance to the agency we are supporting. With a small footprint inside the federal government, USDS uses discovery sprints as a tool in our initial conversations with new partners.

The pandemic shined a brighter light on how some of our most critical systems are not meeting people’s needs. At the same time, there is a renewed focus on improving them. The teams forming at the federal, state, and local levels might benefit from our experiences, or could at least avoid repeating our mistakes. We sit down with Kat Jurick and Jenn Noinaj who co-authored the guide to learn more about discovery sprints and their process of writing the guide itself, in hopes that others can document and share some of their own best practices for working within and around public interest technology.

Kat is currently an advisor at USDS. She was the USDS Design Director from 2018 to 2020, and has led, participated in, and staffed many discovery sprints, and she also often facilitates post-sprint retrospectives. Jenn leads the Public Interest Technology Workforce project as a fellow at the Beeck Center for Social Impact + Innovation at Georgetown University. Prior to this role, she was a user experience design expert at USDS, where she both led and participated in multiple discovery sprints.

What is a discovery sprint anyways?

JN: USDS is often invited to find ways technology can fix an issue an organization may have, but technology is rarely ever the solution. Instead, USDS strives to be outcomes-focused. That means understanding what people need, where they’re coming from, and the context in which they’re operating. Coming from a human-centered perspective, it’s imperative for teams to start by understanding where an organization has been and where they are now, before helping them figure out where they want to go.

The purpose of doing a discovery sprint is to help identify root causes, issues, and opportunities; not to try and solve them in the time window of the sprint.

Teams spend the first two weeks interviewing stakeholders and talking to people who engage with the organization (the ‘users’). Depending on the type of engagement, they’ll also observe processes, analyze data, and review code. This process makes sure that any technology that the team introduces or modifies will work for the people it’s intended to serve.

KJ: We use discovery sprints to quickly build an understanding of the status of a complex organization, system, or service. “Discovery” is a common phase in design and development processes, so it’s not unique to USDS. What is unique is how we’ve adapted some of the methods in these processes for the context of government. The federal government has nearly unlimited budgets, complex procurement and vendor arrangements, and a stark division of labor that separates program officers from budget officers from legal and technical teams. That means it is hard to see the whole picture of what is working or not working. Discovery in a public interest sense is about developing a holistic awareness and focusing all these silos on a common approach to a solution.

Why did you decide to write this guide?

JN: USDS conducts discovery sprints to quickly build a deep understanding of an organization and to help our stakeholders uncover and identify opportunities for improvement. I had been on a handful of sprints at USDS and I remember, for my first one, spending a lot of time preparing for the sprint, trying to figure out what needed to be done, and what was expected of me. After a few of them, I started compiling the resources I used and realized they could be helpful for others. This initially started as something that would be shared internally at USDS but after partnering with Kat on this work, we figured that how we run discovery sprints could be a useful tool for everyone, whether that be within government or in other places.

KJ: During my time as Design Director I was responsible for staffing our designers onto discovery sprint teams. I also would frequently run internal team retrospectives when sprints were complete. I saw a lot of the same types of questions and challenges come up repeatedly across different types of sprint efforts. We had been kicking around the idea of updating our internal sprint documentation for a while and it just became clear that we needed to write this guide. Once Jenn and I started to work together and look at the documentation and references to discovery exercises, we realized that there was likely a broader audience for documentation like this. We were both very impressed with the guides that 18F has been publishing, and we took inspiration from them as a place to start from.

JN: And also, let’s be honest — we kept getting pinged and asked about the resources we were using, so one day, we finally threw up our hands and began. I always want to document more but it’s so hard to do when you are heads down on project work. It was nice to take a step back, prioritize, and make the time to document.

Who is this guide for?

KJ: USDS works at the federal level, but we’re hoping that other teams can adapt and use the guide. After the Digital Services Playbook was written we found that it had a much broader reach than I think USDS had originally assumed. Recently the concept of civic tech and public sector focused technology work has gotten more attention, even though the work has always been there. The Playbook has become a way for other groups to either use themselves or to come across USDS and then reach out to talk about working together. We also find that sometimes when we propose the concept of a discovery sprint to a new agency partner that it can be challenging to explain the concept, so this guide is a way for us to share our methods and best practices more broadly.

JN: Our list of who this guide is for is long! New digital service teams at the state and local levels, stakeholders at organizations USDS is engaging with to run discovery sprints, students who are thinking about public interest technology as a career path, technologists that are considering a tour of duty with USDS, current USDSers who are new to discovery sprints… Kat and I struggled with how to write this guide at the beginning but settled on the largest audience and so it reads more like a “How to” guide than anything.

Speaking of struggles, what were some of the challenges in writing this and what did you learn from them?

KJ: Like Jenn mentioned, identifying the audience that we were writing for was one of the biggest challenges of this document, and we actually started over a couple of times along the way because of it. The concept of a guide has been on the radar at USDS for a long time and different types of documentation have been done before. The part that Jenn and I added was an approach to try and write for the broadest possible audience that would be interested in learning about our discovery methods.

JN: I would say my three struggles were the audience, the writing, and not having enough time. Both Kat and I have a background in human-centered design so we kept going back and forth on how we should structure the guide and who it should be for. This perspective became both a blessing and a curse. We wanted to make sure this was useful for everyone but, in the end, we knew it would be more beneficial to start somewhere first.

Writing was also… hard. Haha. We knew that we wanted this to be a living document but I think both of us are also perfectionists. To help with that, we made sure to work iteratively and constantly get feedback as we were going. Our push to get it published also helped. Once we got our content up on GitHub and started working in our staging environment, things happened quickly. Seeing the guide online was a good reminder for us of the fact that we were creating this for others to use and build upon.

Lastly, making time to prioritize this work was difficult. To be honest, it was a side project for many months before either Kat and I could dedicate more of our time on it. Now that I’m at the Beeck Center working on professionalizing the public interest technology field, I realize how important it is to spend time documenting as we go or even afterward. This helps build momentum for these types of methods that work and to share best practices with other teams in this space.

How should people use this guide?

JN: This guide is meant to be a “How to” on discovery sprints, based on lessons learned at USDS from conducting them over the past few years. Kat and I hope that people adapt the guide based on their organizational needs and use it as they see fit. To that end, we’ve open sourced this so others can add their lessons learned and their own tips to it over time. We want people to contribute to it so that this becomes a growing resource for everyone to leverage. We’ve also got a section specifically for case studies so others can share their discovery sprint stories and experiences doing them. As this grows, I’m interested in seeing what changes people make to our process and how they adapt our methods to their own situation.

KJ: Like the Digital Services Playbook, and like the fantastic guides that 18F has been producing (De-risking Gov Tech Guide, UX Design Guide, Content Guide). We know that people inside governments are interested in this kind of work and looking for references to help them not have to start from scratch. Jenn and I know from experience that every discovery sprint can be different, so we have tried to bake in some of the “Why” behind our recommendations to help teams find their own paths.

Do you have any last thoughts or comments?

JN: We couldn’t have done this without the help of others! Thank you to Eddie Hartwig, Mark Lerner, and Kathy Pham for being helpful editors, to Drew Gardner and Lisa Chung for their development expertise, and to Melissa Braxton and Julie Strothman at 18F for their advice and words of wisdom.

KJ: Yes! Thank you to the USDSers who wrote earlier iterations of our sprint documentation. Also Chris Given, Hank Knaack, Shannon (Sartin) West, Shelly Smith, Jeff Barrett and Cyrus Sethna for being reviewers and, most importantly, making sure Jenn and I were making sense in what we were writing. And thank you in advance to our future readers and contributors of this work. If you use the guide, we’d love to hear your feedback!

The best of technology.
The best of government.
And we want you.
We’re looking for the most tenacious designers, software engineers, product managers, and more, who are committed to untangling, rewiring and redesigning critical government services. You’ll join a team of the most talented technologists from across the private sector and government.
If you have questions regarding employment with the U.S. Digital Service, please contact us at usds@omb.eop.gov and visit usds.gov/apply.