There are different versions of short design sprints, with each company customising their sessions. I’ve heard of 2-day and 1-day sprints, and even 2-hour sprints. At Relab, we can do 3-day or 4-day versions of the design sprint for our clients as needed, when there is no need for the full 5-day version. I’ll explain the difference, and which one is right for you.
Running a design sprint is one of the best ways to do a cross-team collaboration and produce a good solution. But it is resource and time intensive – at least for a week. You’ll need to clear everyone’s schedule, from management to designers and developers to marketers, and basically locking everyone up in a room for 5 days. And the preparation for it would run weeks before.
The prospect of a shorter design sprint sounds more attractive, especially with more people working from home, and in different time zones. Remote sprints can work, and we have done them successfully, but condensed sprints have always been around as an alternative.
Well, one of the selling points of a design sprint is you get a user-validated prototype as an output. This gives you assurance to take it to development and then, hopefully, a successful market launch.
In my opinion, the two stages you can’t afford to do away with are prototyping and user testing. Those two are an absolute must, because that is the whole point of a design sprint – to prove an idea is valuable to our customers. Without it, you’re just doing a long brainstorming meeting. Your idea is not tested and remains a hypothesis.
The trick to condensed sprints is to know what you can do without, that won’t compromise the final product. Let’s start with a 5-day design sprint. This is what it looks like.
Essentially, the 4-day sprint combines Day 1 and Day 2 into just one day. You will be mapping the goal and generating ideas on the same day. There are a few circumstances when you could afford to do this:
They’ve done them before and understand exactly what is needed and how the sessions are run. Part of the lag in a design sprint is briefing the participants on the agenda and rules and explaining each session as they are run. You can afford to cut down a lot of time if everybody already knows what to expect and understand the process.
Experienced facilitators know how to run a sprint efficiently and navigate the process without compromising the result. They can deal with changes and setbacks and adjust accordingly. They know when to stay on a discussion, and when to move forward. In fact, I would argue that the facilitator is the crux of a successful shorter sprint.
Designing a feature will require less time than designing a new product from scratch. With a feature, you have a history of use cases, feedback, and research to guide you. It’s up to you, but I wouldn’t recommend tackling a full product in just one condensed sprint. You can tackle it part by part if it’s complex, but not in 1 short sprint. You’re better off spending the full 5 days on it.
Here is how a 4-day sprint would look like. As you can see, Day 1 consists of activities you would do in the first two days of a standard sprint. The following days follow the full sprint recipe. Day 2 is for voting and storyboarding, Day 3 is for prototyping and finally, user testing on Day 4.
This version of the design sprint is reserved for iteration sprints only. An iteration sprint is one where you’re reviewing, improving, or fixing a solution that was already done in a previous sprint. You’re basically iterating for a better solution, to get it closer to what the user wants and needs, taking in the feedback and results from previous sessions.
Generally, I don’t use this sprint version for new clients, who are not familiar with design sprints and working with us for the first time. We always tend to start with the standard 5-day version for new clients.
How does a 3-day sprint look like? We can drop goal and focus setting because we’ve done that in a previous sprint. On the first day, we’ll jump straight into ideation, voting, and then storyboarding. This works because we already have a working solution, we just want to build a better one. And finally, the second and third days are for prototyping and user testing.
As you can see, the design sprint isn’t a rigid and inflexible process. You don’t have to follow the recipe to a tee to call it a design sprint. You can adapt it according to your unique challenges, teams, processes, and timelines. If you’re still achieving your goal of getting user feedback on your prototype, then it doesn’t matter how you get there.
I’ve heard of people stretching their sprint to longer than a week, due to scheduling and resourcing issues or simply because that’s how their processes are run or how the teams are organised. Of course, the longer it is, the more it defeats the purpose of a sprint. It’s why we call it a sprint, not a marathon.
At the end of the day, it’s entirely up to you. If it works for your teams, then just run with it.