There’s More Than One Way to Run a Design Sprint
Expanding the design sprint methodology with an open source toolkit
Standing at the whiteboard with a pile of brightly colored sticky notes in my hand, I have a sneaking suspicion I might have bitten off more than I can chew. My blue sky sprint challenge of “Reimagining Display Advertising” sounded so inspiring and exciting two weeks before. I look to the team and say “OK, maybe we need to do a little more narrowing down. Let’s take a 10 minute break.” While the team is getting coffee, I go to our Google Sprint Methods resource and scan through the Define section. I need a method that will help the team get clarity on what the offering should be, after comparing the Future Tweet method to the Experience Definition statement, I’m ready to bring the team back together. “OK folks, we’re going to use the Experience Definition method, and then an Executive Summary. I think this will help us paint a picture of what our solution should be.”
Since 2014, I’ve learned a lot about how to scope a Sprint better — clearly it takes more than three days to transform an entire industry. But I still refer back to that set of 50 methods compiled by Nadya Direkova for the inaugural class of the Google Sprint Master Academy. When I’m faced with leading a Sprint for a new space or a challenge that requires a hybrid type of Sprint, I find myself reaching out to colleagues or searching other repositories online and even creating new methods if needed. I know many other Sprint Masters are doing the same, so we decided to redesign the Design Sprint Kit as an open source repository of methods and recipes to help everyone run better sprints.
The Google Design Sprint methodology is based on the principle of flexibility. We approach each Sprint by first understanding the goals and deliverables for the product and team, and then we craft our agenda to drive the desired outcomes. The length of time and methods used will differ depending on the challenge statement and goals that the Sprint Master and team agreed upon. Sprint Masters inside Google are working hard to get effective outcomes quickly and often need to compress or flex the Design Sprint process into various lengths of time.
This means our Sprint Masters have to be critical thinkers, they have to build strong facilitation skills, and they need good tools and resources to support them as they take on new challenges. The methods that we use in our Sprints are collected from various sources, a few were developed inside Google or brought in and changed over time, but most of them come from somewhere else. In the spirit of giving credit to the creators of these methods, the open source site will be a compilation of resources from inside and outside of Google for Sprint Masters.
We’re inviting the community to submit methods or recipes (method-sets) that they have used or developed in their work which might be helpful to others.
