A Q&A with Jake Knapp
We asked the designers at inUse to contribute all their questions about the Sprint method. And then we gave Jake Knapp a call. Here's what he had to say.
How much research do you have to do before a sprint? Is it possible to start from scratch? I find it hard to start from zero research, if it’s not a very defined problem.
– This depends on the team. I think it's fine to start without research, because the design sprint is one way to conduct your first round of research. Of course, if you can do research ahead of time, you'll be better off—but I don't believe you should wait for it, especially if there are already some strong ideas on the team. I like to harness the team's energy and start sketching and possibly prototyping those early ideas—you'll find out soon enough if they're right, and if they're wrong, they represent a powerful learning opportunity.
In the case where the system/application has a heavy backend, with lots of integrations and a technical legacy, would you recommend to do Sprint? And if yes, how do you make sure it's feasible? So you don’t design amazing artefacts that never can be realized?
– Yes. Be sure to have at least one person—preferably a few—in the room who knows the limitations of your tech. Interview those folks during "Ask the Experts" and be sure you have sprint questions identifying specific risks (For example, "Can we handle new data types?" "Are new integrations feasible?").
– All of that is not to say that you shouldn't be optimistic in your sprint and risk-leaning as you consider solutions. Strike a balance where you ask those legacy experts to help you understand what is and isn't feasible, but you still encourage the team to be bold and take risks on their solutions, provided they believe those solutions could be built.
I was in a sprint a while back and it was the most fun I ever had at work, but I was exhausted by the end of the week. Do you recommend doing sprint after sprint, every week or can you do it more as a focused effort?
– Sprints are fun but also very hard work and it's not a good idea to do them every single week—at some point you have to go back to execution mode. Doing back-to-back sprints, two or sometimes three in a row, can help you build confidence as you refine a solution and act on what you learn in your tests. Even in those situations, I would recommend spending less than the full five days on the follow-up sprints if possible. And avoid more than three sprints in a row if you can.
What “level of problems” do you think the method is best adapted for?
– The design sprint was created and optimized with big problems in mind—things like completely new products, marketing campaigns, redesigns, or new features. If there is a lot of time, money, or opportunity at risk if you build or do the wrong thing, or if you need help getting a stuck project started, then use a design sprint. The process can work on smaller projects, but it's important to make sure the design sprint doesn't become a "solution for everything".
How does design sprints work with the classic agile development process, both in timing and in material?
– Ideally at the start of a new project, before the team has begun execution, and ideally with the engineering team involved in the design sprint. You can think of it as a sort of sprint zero. It can be very hard to get agile teams to slow down and stop writing code just to make sure you're building the right thing... but of course, it is better to wait one, two, or three weeks and build the right thing than to hurry up and spend months building the wrong thing.