Running a 3 hour Feature Design Sprint requires a rework of the most popular sprint formats, namely Google’s Design Sprints. As this is crafted to unpack a Feature, it doesn’t need to be as involved as a full workshop.
Working within a 3 hour window is a big challenge with a larger feature. However, the team really connected with the shorter Sprint as we kept it engaging and fun throughout its timespan.
The slides below show the semi-flexible schedule I kept to. We started with the introduction and overview, explaining what the team would expect at each section.
There are many mini games you can play to get people on the same page and break down those uncomfortable workshop barriers. In this Sprint I focused on Superpowers, where each person writes down a Superpower which sums them up – and then one by one present it to the group.
Feature & Funky 4’s
Once we’ve covered an in depth look at the feature, we go over the Business and Customer Why’s, and what problems we are trying to solve. We then dive into Funky 4’s (a modified “Crazy 8’s”) in which each person comes up with 4 solutions from obvious to outside-of-the-box.
Vote & Share
After the break we go around the room one-by-one presenting the solutions. If we’re ahead of time I’ll suggest that each person present all 4 of their solutions to the group. Typically the voting is by individual solution – but to break the mould (and avoid popularity votes) I took the themes that were presented and created a voting board.
Theme Groups & Solutions
In this Sprint the participants separated into 3 teams around the 3 themes that raised the most votes. While working through their solutions, they were asked to keep validating them agains the Business and Customer Why.
Once the multiple solutions have been created, we have a small presentation and then document the Next Steps. This includes working out which area we need to talk to (Marketing, Legal, Business etc) and how we can set this up for UX testing as soon as possible. In this Sprint, the solutions were quite high level and needed to be transformed into usable wireframes before testing.