sprint.usds.govDiscovery Sprint Guide

An official website of the United States government Here’s how you know Here’s how you know Official websites use .gov A .gov website belongs to an official government organization in the United States. Secure .gov websites use HTTPS The https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites. Menu Sprint Guide Interview Guide Writing Guide Case Studies About this guide What a sprint is Sprint timing Example scenario Preparing for a sprint Conducting the sprint Delivering the sprint findings Wrapping up the sprint Running remote sprints How sprints fail Glossary & other resources About this guide The U.S. Digital Service (USDS) works on technology improvement projects impacting people served by the United States government. Since 2014, USDS has partnered with dozens of federal and state agencies to build more than 160 successful digital products. In our initial interactions with a government agency, we will often run what we call a Discovery Sprint. This guide intends to explain the discovery sprint process and share best practices to help teams adapt and run their own discovery sprints. What is the purpose of a discovery sprint? Discovery sprints are a useful method to quickly build a common understanding of the status of a complex organization, system, or service. They create paths toward solutions by identifying specific, actionable next steps for the people at the organization who will carry that work forward. When we say quickly” we mean that almost all of the work is completed in 2-4 weeks. A small cross-functional team of engineers, designers, product managers, procurement and subject matter experts partner with an organization’s personnel to quickly explore an organizational problem or challenge. The purpose of a discovery sprint is to identify root causes, issues, and opportunities, not to solve them in this time window. During a discovery sprint the team will interview stakeholders at every level of the organization as well as end-users. They will also dig into available data, look at code in production, and observe processes. As a methodology, discovery sprints are not new – they stem from best practices in Human-Centered Design. At USDS the organizations we typically engage with are federal agencies but, for this guide, we use the word organization” as a placeholder for any group you would be doing your sprint work with. You can find definitions of other terms we use throughout this guide in the glossary . When is the right time to run a discovery sprint? There’s never a bad time to run a discovery sprint, though we typically see them happen during these different phases on a project: Before a new tool, service or product is built When an existing tool, service or product is actively broken, or no longer meeting current or aspirational technology standards When key stakeholders change and a fresh perspective is useful to plan for or prioritize a new roadmap Discovery sprint scenario Let’s take the example of a federal agency somewhere. Your discovery team has been brought in because the process of filing paperwork to help people receive a benefit they are entitled to is slow”. One part of the Agency ecosystem is on the verge of spending $6 million on new servers in an effort to solve this problem. On the face of it, this looks like a pretty cut-and-dry technology problem. However, the agency leadership wants a gut check and has invited your team in to advise them. The discovery team spends time talking with the office that is making the decision to spend the money and, while they are there, they also spend time talking to the offices that are both up and downstream from the group that has brought them in. It turns out that the team that is filing the paperwork at the beginning phase of the process waits one week for a response and then, if they haven’t gotten an answer, they refile the paperwork again to move the request to the top of the pile.” They do this because the paperwork delay can result in people missing out altogether on receiving benefits. The discovery team then goes and spends a couple of days in the office that is receiving the paperwork. This group overhauled their workstream 9 months ago and they are now batch processing incoming requests three days a week. This has improved their processing time by a measured amount and they are extremely proud of this. They don’t know why they seem to get so many duplicate requests though. When your team talks to the citizens applying for the benefit, they learn that applicants find the paperwork onerous and the process of filling out the form, printing and signing the form, and scanning the document to be time consuming and confusing. If their information changes when they move, they have to start over from scratch because there is no way to make updates to an in-process application. Once forms are submitted, there’s no easy way for someone to get status updates, or to know where they are in the queue. In the scenario above, each team is absolutely doing as much as they can, to the best of their abilities for their stakeholders. In this case, the report written at the end of the discovery sprint can highlight the process of both teams, the struggles of everyday people trying to navigate the process, identify some opportunities, and make recommendations of what to do next. The report may also advise that spending money on servers at this stage is a solution that is unlikely to fix the challenges that the offices at the agency are facing. Return to top All recent changes to this siteGithub Privacy...