Delivering the Sprint Findings
During the discovery sprint, your team will have amassed a lot of data in multiple types of formats. It is important to create artifacts of what was covered during the sprint as a “leave-behind” for your stakeholders. We recommend writing your documents at a level of depth that doesn’t require you to be in the room with the reader. We’ve seen reports go dormant and get picked up later as the organization shifts in priorities.
Sprint deliverables
Typically, we produce some or all of the following deliverables:
-
An executive summary (2 pages max) that identifies the sprint challenge and scope, the research the team did, and the high-level findings and recommendations. This is often shared with stakeholders in advance of the rest of the report.
-
A sprint report (5 - 10 pages) that goes to the sprint stakeholders and organization’s leadership. The report often includes the executive summary, observations, anonymous quotes, recommendations and potential next steps.
-
A formal slide presentation (optional) that summarizes the report, since the findings are delivered in person to the same group of stakeholders that were present for the kick-off meeting at the beginning of the sprint.
-
A quick prototype (depending on the organization’s needs) may be created to illustrate a proof of concept. This is rare and will vary based on the scope and goals of the discovery sprint.
Make sure to leave a proper amount of time to create these deliverables as these will live on long after the team disbands. These items are the results of the sprint.
Start the first draft of the sprint report early
We have found that it’s really never too early to start writing an outline or draft of your report deliverables. Even after the first couple of days of interviews you should start to have some good data and maybe an outline of the story that you will be telling. In your end-of-day team check-ins talk about what you saw and heard, what you learned, amd what you feel like you still don’t know. Use those insights and questions to drive the next day’s work. The sprint team lead should take notes that can become the start of an outline. During week two of the sprint you should start to write and edit your work.
A good discovery sprint report captures the current state of affairs, unearths gaps and opportunities, and sets clear recommendations for action moving forward. Recommendations should be actionable and address the severity of issues and potential impacts. The scope of the effort both in rough time and resources necessary should also be included for each recommendation. The report should also distinguish between things the organization could do now and long-term potential work. You won’t have been able to dig deeply into every aspect of the organization during your 2 weeks, so it’s fine to include unknowns and areas you would have liked to explore but didn’t get a chance to.
Recommendations do not need to be technology fixes. Discovery efforts frequently uncover opportunities to move or empower existing staff or additionally hire missing roles or expertise (either directly or via vendor contracts). Organizational changes could be just as useful as building or buying more software or hardware. That said, government systems advance by the decade, so it is also possible that something that was an expensive custom-built solution, that hasn’t aged well, may now be replaceable with off-the-shelf solutions. The other type of recommendation you may make are policy changes. This can happen for two reasons: one, available technology may have advanced beyond the limits of the current federal policy, and, two, over time an organization may be constrained by their interpretation of an existing policy and a fresh review may reveal new, potential approaches.
See the writing guide for in-depth details on writing the discovery sprint report.
Final report review
A fresh pair of eyes for a final edit is always recommended. Make sure that members of your leadership team review the final drafts of deliverables before they are considered “done” or ready to deliver. This can also include a review from the public relations, policy, or legal teams from your organization. Lastly, it’s helpful to have a plain language expert review the report to ensure it’s easy to read and understand.
At USDS, we have occasionally run into situations where a sprint report can have unintended audiences or consequences. We now make it a best practice to loop in reviewers before we deliver the report to stakeholders.
Readout and presentation to stakeholders
Ideally the sprint team lead should have pre-scheduled the executive stakeholders for a readout meeting date as close to 3 or 4 weeks out from the kick-off date as possible. This will ensure that momentum stays high during the sprint and that the sprint team is able to deliver their findings while everything is top of mind.
During the sprint readout, walk through your findings, answer any questions the organization might have, and discuss next steps. You should print out a few paper copies to bring to the meeting. At the onset, make acknowledgments - thank leadership and the staff you worked with for their time and efforts.
You should then walk through what you did, your research, and how you came to the findings and opportunities. You should NOT walk through the report itself. Use this time to share stories that you heard during research to cement why you proposed the findings and recommendations. It is important that you understand where the organization is coming from and delivers the results of the sprint in a way that resonates with them. The research you have done should inform this.