Preparing for the Sprint

Problem statement
Before the sprint officially begins at a kick-off meeting, someone will want to engage with the organization where the work will be done in order to develop a clear problem statement, identify stakeholders to work with, and set expectations.

At USDS, a discovery sprint is often initiated at our leadership-level and then handed off once the sprint team lead is determined.

Sprint team lead
Identify your sprint team lead as early as possible since that person will serve as the main point of contact with the organization’s leadership. Sprint team leads are responsible for stakeholder relationship management as well as preparing for and guiding the sprint team through every stage.

During these pre-meetings, work with your key stakeholders to come up with a concrete description of the problem the organization is facing. This helps to get a sense of the type of sprint it will be. It’s also important to ask questions of the organization to clarify the scope of the sprint. The type of sprint—whether the organization is trying to procure or build software or if it is an emergency response to get an existing system back on its feet—will help ensure the right resources are on the team. It also makes sure that the team’s focus is clear and helps with scoping the work for the sprint.

A good problem statement will include a description of the people at the receiving end of the tool or service, what they’re trying to accomplish, and the implications for not addressing any known issues (number of people affected and how severely, budget concerns, etc). The problem statement should center around describing the issue rather than outlining any proposed solutions. For example, “The organization wants to increase participation in vaccine trials related to a public health crisis. They currently have a 1% acceptance rate when they call participants. Even small improvements could dramatically speed up the vaccine development process and ensure that it is effective for all Americans. Improvements beyond the immediate crisis could also improve the organization’s 22,000 ongoing medical trials.” The purpose of a discovery sprint is a new perspective, so it is entirely possible that the problems identified at this stage may not end up being the same as what the discovery sprint reports back at the end.

We break the rest of the preparation stage into three main components: staffing, planning, and kick-off. The sprint kick-off gets the organization and sprint team together to understand the organization’s questions and sets expectations for the duration of the sprint.

Staffing

Because the intent of a discovery sprint is to put fresh eyes on an issue, a discovery sprint team should be made up of people who do not bear direct responsibility for solving any uncovered issues.

At USDS, sprint staffing is done by the leadership team. A call will go out for volunteers who have an interest in participating in a sprint in general, a specific needed skill, or the upcoming sprint topic specifically. Due to other project commitments and responsibilities, it can sometimes be challenging to pull a team together quickly. As a rule, we try not to begin a sprint until the team is fully staffed.

The sprint team is the heart of a successful sprint. Sprint teams are necessarily small, usually 4-6 people. Sprint teams need to move quickly, often including actual travel requirements, and, the larger the team, the more communication and coordination is needed. The makeup of a particular team will depend on the specifics of the problem they will be solving. A typical team has the following skillsets:

Project leadership (the sprint team lead)
Product management
Design expertise (e.g. user research, user experience, content, visual, etc)
Technical expertise (e.g. engineering, systems, security, data science, etc)
Policy or legal expertise (e.g. what USDS calls “bureaucracy hackers”)
Procurement knowledge
Communication and presentation skills

Some individuals may possess several of these skills. For example, the sprint team lead might be a designer or the policy team member may also be a software engineer. The important thing is to ensure each skill is represented by at least one person. That said, we acknowledge that staffing is rarely perfect due to staff availability, so there may need to be some hard choices at this stage.

At USDS, we do not have any teams that exist to only run sprints. Instead we staff discovery sprints with people who are rolling off of larger or long-term projects. Doing this allows team members to focus on new work quickly. It’s also an opportunity for cross-pollination by bringing together a needed set of skills to make up a strong sprint team. We also keep in mind that if a sprint turns into a longer-term engagement with the organization, we want to staff folks to work on things that they are passionate about.

Team cohesion

Once your team is staffed and decided on, you should get together before the kick-off. Get to know each other and who is good at what, decide what tools you will use for communication, swap contact info, and so forth. By the time you arrive at the kick-off meeting together you should appear to your partners and stakeholders as a cohesive and collaborative team with a strong leader.

Practice your elevator pitch: make sure everyone has a consistent message of who the team is and why you’re there
Decide how you will explain what you do: many folks in the government will not know exactly what a product manager, UX designer, site reliability engineer, and so on do. How can you explain this to them without getting too technical?

Identifying your partners

It is important to note that sprint team members are often experts in their skill sets but not necessarily in the space being researched (the stakeholder organization or their challenges). It is imperative that, as the sprint begins, the team is able to partner with individuals at the organization that are subject matter experts to ensure the right solutions are being proposed.

The sprint team lead should work with the stakeholder organization to identify the following people:

Senior Executive Sponsor: They provide high-level leadership support for the effort and receive the sprint deliverables. They will be instrumental in providing top-level support and often hold the responsibility for the solution and implementation efforts that will potentially follow. We often use the term “air cover” or “top cover” for this stakeholder.
Sprint Champion: The sprint team’s key day-to-day partner within the organization that’s tasked with making this effort successful. Their work is affected by the problems that the discovery sprint team will be investigating.
Administrative Contact: Someone with time dedicated to supporting the effort that the sprint team can interact with on a day-to-day basis to answer questions or get assistance with building access, booking rooms, office supplies, IT resources and other time-sensitive logistical matters. Access to a company directory and calendars is important for keeping a sprint from running beyond the allotted time frame. It’s helpful if this person works for a senior stakeholder and is often tied to the Senior Executive Sponsor.
Topic Stakeholders/Subject Matter Experts: An initial list of people inside the organization or adjacent to it who currently own a piece of the problem or the solution. This list will expand over the course of the sprint, as you uncover other people to talk to.
End Users: The actual people who touch or who are affected by the tools/services in question. Inside the organization, “users” can refer to the internal team using enterprise tools, as well as the public, who will ultimately receive the services those tools provide.

Planning and sprint logistics

There are a number of arrangements and contacts that need to happen ahead of time to make a sprint run smoothly. The sprint team lead should work with the organization’s partners to identify someone who can help coordinate logistics for the team.

Schedule

Timing: Before you get too far into planning, make sure to discuss actual calendar dates with your primary stakeholders. Scheduling too close to a big annual meeting, the beginning or end of the budget cycle, or between Thanksgiving and the end of December when many people take extended vacation can kill a sprint’s momentum.
Availability: The entire sprint team should make sure that they have at least three consecutive weeks to dedicate full-time to the sprint. The first two weeks are often used for research with one week for follow-ups and writing, and another for final sprint delivery and readouts to stakeholders. Communicate the team’s timeline to the organization’s partners to ensure they are aligned and know what to expect. Keep a shared team calendar if possible.
Travel: Confirm which team members can travel and make sure everyone has set up the appropriate travel accounts and documents prior to starting the sprint. Whenever possible, you should go to your stakeholders. If it is not feasible, read the section on remote sprints.

One of the core values of USDS is, “Go where the work is.” We have found that there is no substitute for going to where your discovery participants are.

Contacts: Work with the organization’s leadership to determine who would be best to talk to during the sprint. Ask for a high-level org chart annotated with contact information so the team can understand how the organization is structured. Note that, in government, the published versions of org charts are often out of date.
Interviews: Start by setting up initial interviews with critical stakeholders early on in the sprint. Scheduling often needs to happen well in advance since it can be hard to get on their calendars. Additionally, before the start of the sprint, schedule some user interviews for the first few days of the sprint so you can hit the ground running when it begins. As the sprint progresses, you’ll continue to add to your interview calendar as you uncover more people to talk to. For more details on conducting interviews, see the interview guide.
Final briefing: Begin the process of scheduling the final briefing meeting where you’ll present your results, as soon as you can. This helps immensely with a sense of urgency towards the conclusion of the research, the report delivery, and can organically help prevent scope creep.

Access

Building access: Identify where the organization works. If there are multiple locations, get a physical map of where the organization is located to help everyone determine where they need to go. Everyone on the team should be able to access the organization’s buildings. If interview locations are far from each other, you can try to be efficient for planning your interviews.
Workspace: When working on-site it is helpful to obtain at least two rooms where the organization is located: one room for the team to work out of and one or more another room to conduct interviews, if needed. The team room is typically a large conference room where everyone can fit. This space should be reserved for the duration of the sprint plus a few extra days and should have the appropriate supplies: network access, whiteboards, post-its, paper, markers, etc. We typically recommend that you conduct interviews where the stakeholders sit and where the users are but having a back-up interview room helps if they’re in an open floor plan.
Network / phone: Work with the organization to determine how to get internet access. Additionally, some buildings have limited or no cell coverage so know ahead of time how the team will coordinate meetings.

We’ve found that most federal agencies will not allow outside equipment to connect to their networks so tethering to phones or wifi hotspots might need to be employed.

Clearance: Obtain any NDAs the team needs to sign in order to be effective and see all the work. This is often negotiable but planning for this beforehand allows the team to avoid having to make concessions about the scope of the sprint or getting held up before they can even start.

Within government, a few agencies require security clearances before the team can start. The sprint team lead should work with the agency to determine what’s needed.

Data / systems: Collect any available background materials, technical diagrams, problem statements, and other materials relevant to the content of the sprint and distribute them to the sprint team ahead of time. Request access to potential systems and tools the organization uses that the sprint team might want to investigate.

Software and tools

Communication: Make sure everyone on the team has everyone else’s phone numbers and emails. Determine what tools the sprint team will use to communicate with one another and ensure that all sprint team members can access those tools.
Document repository: Many sprint teams use Github to keep project documents. If so, create a team folder in the appropriate Github repo for the sprint team. If possible, some teams might be able to use Google Suite. Be careful about what happens to any sensitive information you may acquire, not only for the duration of the sprint, but what happens to it after.

The kick-off meeting

The kick-off meeting is the first time a large group comes together for the discovery sprint. It usually takes place in-person, to the extent possible, at the stakeholder’s organization. In the room are the key stakeholders, all members of the discovery sprint team, and, most importantly, the executive sponsor from the organization. Ideally, a kick-off is 90-120 minutes to give time for both planning and discussion. The kick-off lets the sponsors meet the discovery team and to describe, in their own words, their current situation and refine the problem statement. This is meant to be a back and forth conversation, not a presentation-type meeting.

We include this first meeting as part of the planning stage because it needs to happen before the sprint begins. At the kick-off, it is essential for everyone in the room to hear the head of the organization reiterate that stakeholder interviews will be happening, that they are a priority, and that the effort is supported from the top of the organization.

A sample kick-off agenda
It is important to use the sprint kick-off to set sprint expectations and outcomes for the organization, stressing to them that the team is there to collaborate with them and provide an outside, neutral, 3rd-party assessment. You should help the organization understand that the team is engaging for a short amount of time and will use that time to meet with as many stakeholders as possible. What makes sprints so successful is that the result of the sprint is not an “audit” but objective observation followed by actionable information and recommendations for the organization’s leadership to address the items they’ve identified.

Here is an example agenda for the sprint kick-off:

Introductions
Organization’s description of the problem
Review of the “First 48-hours” proposed schedule of interviews
A commitment to the dates on the sprint timeline
Q&A from the sprint team to the organization
Q&A from the organization to the sprint team
What the organization should expect at the end of the sprint
Note: We recommend setting the meeting date for your readout at the end of the sprint during the kick-off while you have the key stakeholders in the room. That way, scope creep is less likely.