Our experience of The Sprint

About two years ago, Jake Knapp, John Zeratsky and Braden Kowitz from Google Ventures published “ The Sprint.” They describe a methodology that helps you answer critical business questions, develop ideas, or tackle problems in just five days, and last year Jake Knapp shared his insights in a fireside chat at Zalando.

Last week, we had the chance to see it in action. In this article, we will not go into the details about how the Design Sprint works, since it’s already described perfectly in the book. We will rather share another valuable asset with you: our experience and learnings.

Why Design Sprint?

Our team started work on a new replenishment process and since Design Sprints were already successfully used at Zalando, we decided to give them a try. We had already tested some crucial assumptions for the new process we were working on with an excel prototype, and now wanted to craft the look of the customer interface to allow for deeper learnings.

Setup and Preparations

The Team

We recruited a multi-functional group of eight people across the department plus two facilitators. It’s quite a large group, but we aimed for involving the whole developer team in the discovery as early as possible to get everyone on the same page in terms of knowledge and decision-making. The following colleagues were involved:

• Five engineers
• One process specialist
• One UX designer
• One product manager
• Two producers to facilitate the workshop

Learnings:

• It’s hard to find a week where everyone who you would like to participate can get rid of all meetings and appointments. But it’s definitely worth it!
• Get a strong facilitator. You will not be able to manage the sprint and to contribute to the workshop at the same time.

The War Room

According to the guidance, we booked a room in our office for the whole week. Unfortunately, it had terrible acoustics and turned out to be too small, so after the first day we moved to a bigger and more comfortable one.

Learnings:

• Test your room before you start the sprint! Make sure it’s not too noisy and it’s big enough. Your team should easily fit in, together with the big whiteboards and all kinds of supplies. Don’t hesitate to change it if it doesn’t feel right: your team will thank you! Apart from that, you will need all your energy to focus on the sprint and not to waste any brainpower on room complaints.

What did we do and what did we learn?

Day 1: Knowledge Sharing and Alignment The first day was dedicated to setting the frame. We introduced the roles of Decider and Facilitator, aligned on the long-term goal, invited several experts from different teams for interviews, mapped the new process and formulated some open questions.

Status: Finally we get to do a Design Sprint!

** Learnings:**

• Make sure to formulate the sprint questions correctly. Otherwise, you’ll have to come back to it in the middle of the sprint, and will possibly lose a lot of energy clarifying it. Look for critical hypotheses you can verify or falsify. This might put you out of your comfort zone, but you’ll only learn something new if you risk being wrong.
• Map the process on a deeper level! We did it high-level in the beginning, but realised in the middle of the sprint that we had to go deeper. It was extremely difficult to come up with the storyboard without a common understanding of the different process steps. After some trial-and-error, we decided to step back and invest time in re-doing the process map.

** Day 2: Sketching Solutions **Having a common baseline of knowledge, we shared some ideas that we particularly liked on other products (“Lightning Demos”) and could incorporate into our product. Then we started to sketch our solutions. Google Ventures suggests some approaches how to structure the sketching process, and all of them are based on individual work. There is no exchange or feedback planned for this half of the day, everyone just develops their own idea.

Status: This idea is going to be good...

Learnings:

• Explain the purpose of the Lightning Demos. This is an extremely helpful exercise, but sometimes you end up pitching your idea instead of just showing and explaining it.
• Individual sketching might not always be the 100% right solution. Since there was no exchange on ideas, we felt like we lost the momentum of combing great concepts or getting inspired by the work of others. Next time we would either exchange or mix the suggested way of sketching with an iterative method such as rapid wire-framing. Day 3: Review and Decide On Wednesday we reviewed the ideas drawn by the team, and decided what we are going to prototype. After the Decider voted, we started to build a storyboard for our prototype. As mentioned already, at this point of time we ran into several issues: it was not clear what exact question should be answered by the end of the week, and we missed a detailed process map. We had to make a mind switch from, “We can test everything” to “We have to find the most important hypothesis.” It was very difficult to accept that limitation and align on one statement. Nevertheless, we overcame the difficulties. We aligned on one hypothesis to test and drew a detailed process map. After this was accomplished, we came up with good results, but it was definitely emotionally the most exhausting day of the sprint! Status: Roller coaster of emotions!

Learnings:

• The Decider is the best role ever. Having a dedicated Decider role definitely has its advantages especially when there is a time constraint. Our Decider did an awesome job by not just making the decision about which prototype we should build, but also explaining the background and his thoughts to the group.
• Make sure everyone knows the process. As mentioned already, after we realized that we were not on the same page we had to spend some time on redoing the process map. Day 4: The Prototyping Here you go: after just 3 days you start building things! Okay, not really building, since the prototype is just a facade. But it looks pretty much like a real product!

Learnings:

• Assigning different roles really helped to get everything together in time. Everyone knew what they were responsible for, and working on for the next few hours.
• Don’t get lost in details. The main challenge appeared to be the decision on how to spend our time. We concluded: Users don’t really care about how exact your numbers are or if your buttons looks awesome, they focus a lot more on the workflow and how the data is displayed. So we invested more energy in the look of the interface and neglected the correctness of the data. Day 5: The Moment of Truth The most exciting part of the workshop: Your team watches how real users interact with the prototype! This day is definitely the hardest one for the interviewer. You have to be well prepared to talk to users for five hours and be watched by the rest of the team.

Learnings:

• Live testing is awesome! Getting real-life feedback was a great experience and provided a lot of insights. If you are planning on doing a design sprint, invest some time in advance to find users and align on time slots.
• Get some feedback from the team. While this wasn’t part of the design sprint concept we think it’s important to always gather feedback and take away learnings for the next sprint to come.

What now?

We are very satisfied with the return on time invested. It was a great experience with solid results we can further test along the way. It can be very difficult to find a consensus within the team due to different opinions and approaches. The Design Sprint turned out to be very useful not only for building and testing prototypes, but also for getting the buy-in from the whole team, the management, and the users, and therefore increase everyone’s passion about the topic. Additionally, doing a design sprint is an efficient and low-budget way to find out whether you are actually building the right product for your users or if you need to re-think your approach.

We hope we have encouraged you to try a design sprint for whatever problem you are facing right now.

Come work with us! Have a look at our jobs page.