I have a boy toddler, so excavators are always on top of my mind. Excavators move a lot of rubble and dirt around. They put a construction site into its initial shape. They’re big, crude, and noisy. They can traverse soft and loose ground.
Excavators are also an apt metaphor for design sprints. Sprints are great for getting everyone to the same level of understanding or changing the direction of a project—beliefs and strongly held assumptions are sometimes harder to move than stones and dirt. Sprints also work well when you don’t have all the details.
Excavators and design sprints are magnificent and versatile tools. However, they are not appropriate for every kind of job. You wouldn’t use an excavator to decide on the location of a construction site nor would you use it to paint the inner walls of a house. You also wouldn’t use design sprints to find a problem to solve or to make minor visual changes in a digital user interface.
I’ve dissuaded people from organizing and running design sprints many times, and I’m proud of that accomplishment. I understand the excitement. Sprints are fun activities over a few days with a lot of sketching and post-its, but they’re a waste of everyone’s time if conducted without a clear goal or at the wrong time of a project. So, when is it appropriate to run a design sprint?
In my experience, most of these conditions have to be met to run a sprint successfully:
- You want to test a concrete idea in the shortest time possible.
- You’ve done preliminary research to remove some assumptions and get a better understanding of the problem.
- You want to bring project stakeholders to the same level of understanding.
- You want to elicit ideas and expertise of other people (hopefully various roles that bring diverse perspectives).
- You can prototype an idea from the sprint in one day.
Are modifications or exception possible? Of course. However, I wouldn’t recommend them for teams new to running design sprints because modifications can become excuses to avoid steps that are hard or challenging. For example, “we’ll only do the first exploratory part and not test at the end because we know what will work for our users” is a common and probably the most dangerous variation.
A design sprint is just one of many design methods—a tool in your toolbox. Use it appropriately.