Design Sprint: Take Your Time to Save Time!
What you definitely need to consider before running a Design Sprint
This article is intended to give you some clues as to whether running Design Sprint is suitable for solving your challenge or problem. As an Agile Coach and facilitator of Design Sprints, I am asked about this again and again.
In our company, we coaches get requests quite often to run a Design Sprint in 1–2 weeks. Practically every checklist for a Design Sprint says that everything stands and falls with the preparation. Nevertheless, a colleague and I agreed to facilitate a Concept Sprint (similar to a Design Sprint) with only one week of preparation. There were good reasons for accepting this assignment. However, this experience was — well, very insightful.
That is why I would like to show in this article, why the preparation of a Design Sprint, including the choice of a suitable challenge, is at least as crucial for its success as the execution of the Sprint itself. Furthermore, I will show that the selection of the Design Sprint team members and the voluntary nature of participation in a Sprint are essential as well.
This article does not claim to be an all-encompassing guide, but focuses on the insights we have gained from this particular Concept Sprint.
In this specific case — in a very technical field — we conducted a Concept Sprint. Most of the content of this article applies equally to Concept Sprints and Design Sprints. The term Design Sprint is more widespread and more common, so for simplicity I will just use the terms Design Sprint or Sprint.
If you want to read up on what a Design Sprint is, you can find my very short summary and further links, as well as a short overview of the differences between Design and Concept Sprints here: What Is a Concept Sprint and What Is the Difference to a Design Sprint?
Here you can find a detailed description of a remote Design Sprint at idealo (in German).
Motivation behind this article
In the one week of preparation before the above-mentioned Sprint, it turned out that many relevant topics had not been clarified or prepared and could not be prepared in the short time available. And even during the Sprint, we realized that we had made false assumptions, such as that the team was already technically and content-wise on the same page or that it was clear to everyone why a Design Sprint should be run. This could have been clarified and avoided with a proper clarification of the assignment in advance. But there was no time for that. We jumped in anyway to support this important project.
I am not talking about the preparation time for us as facilitators here, but for the others involved. For the facilitation, we could easily access existing material (Miro boards) from previous Design Sprints, as the Sprint was run remotely. Of course, there is always some adaptation to be made, and although this was a lot of work, this was feasible and not the problem. Nevertheless, it is of course a good idea to request the facilitation of a Design Sprint as early as possible, as we coaches are not necessarily available at such short notice.
Our above-mentioned wrong assumptions were probably caused by the very good experience with another previously conducted Design Sprint with a preparation time of two weeks only. In this case, however, the team was very motivated and already fully involved in the topic, the challenge was very qualified, the goal was clear and everything necessary had already been prepared in advance by the Product Owner.
I have had many very positive experiences with Design Thinking workshops, as well as Design Sprints, which were energetic, motivated and, most importantly, produced a lot of results. Is a Design Sprint exhausting and challenging? Yes! For everyone! And that is in a positive sense, with enthusiasm and the experience of having created something of real value in a short time.
But this said last Sprint was more than exhausting. It was partly frustrating for everyone involved und not very energetic. I am convinced that more could have been achieved had the conditions been better.
Such unfortunate experience can be avoided. And as I wish everyone only wonderful and successful Design Sprint adventures, I am writing this article. While writing it, I have my colleagues in mind, who ask for Design Sprint support, and to whom I can suggest reading this article before we talk. Like I just had another meeting with colleagues last week, who want to run a Design Sprint in 1–2 weeks. Since I gave them a draft of this article to read in preparation for our discussion, we were able to get straight into the important questions. :)
When does it make Sense to do a Design Sprint?
Must Have: A good Design Sprint Challenge
First of all, you should clarify whether a Design Sprint is the right choice for your topic/project.
The following questions will help you to find out:
- Is the problem/question big enough? Jake Knapp states:
“The bigger the challenge, the better the Sprint.” (Knapp 32) - Are we moving into high risk territory, is the problem complex and are we dealing with high uncertainty?
- Is the implementation expected to require a large budget and/or time?
- Is the problem to be solved sufficiently understood and is it clear enough what the challenge is?
Is the answer “yes” to all questions? Then a Design Sprint can be a great way to develop and validate ideas/solutions. (Read more here: „What’s a good Design-Sprint Challenge?“).
One week of Design Sprint is very short
There are critical voices that say that a 5-day Sprint is far too short and can only be a part of product discovery, because a Design Sprint is only a compressed version of a product discovery activity such as ideation, creation (prototyping/concepting) and validation. When going through these very short phases within a Design Sprint, in contrast to an extended product discovery, you naturally have to make many cutbacks and you cannot do everything in these 5 days (Herbig).
This is precisely why very good preparation and — depending on the result — also more or less follow-up activities are necessary. The necessary and suitable people for the Sprint (Design Sprint team, stakeholders, experts, users) must be selected early on and be available when they are needed.
Based on our last experience, I will go into some very important aspects regarding the preparation of a Design Sprint and the Design-Sprint team.
1. Do you have enough Time & Capacity for Preparation?
You probably know such situation: An important, big project with a lot of focus is supposed to start, time is tight and as if that’s not enough, there are long holidays of important people upcoming. Nonetheless, a Design Sprint shall be run before the holidays — is that reasonable, good and feasible?
If the facilitator comes in rather shortly before the Sprint, such steps must have already been taken:
- The challenge and what is to be achieved (the goal) is clear.
- Background information and data are available.
- The Design-Sprint-team members have already been chosen and the roles of the Sprint participants are clear.
- The team is familiar with the topic.
- Interview partners, experts and stakeholders are identified and readily available.
- A Design-Sprint-preparation meeting with the team and the facilitator has been scheduled for the week before the Sprint.
In any case, one week is very, very short and if all this is still completely unknown, the preparation can easily increase to several weeks, especially for product owners and deciders.
I will now go into the points that most struck us in the last Sprint.
Establish a common Understanding of the Problem before the Sprint
During the Design Sprint, 80% of the time is spent in the solution field, i.e. searching for and testing solutions. Only 20% of the time is spent on the shared understanding of the problem. Therefore, these tasks have to be done beforehand: Research, gathering of all relevant information and previous solution approaches, clarification of what the Sprint challenge is. It may also be necessary to conduct stakeholder and/or user interviews relevant to the problem in advance. On the first day of the Design Sprint, everything is summarized only once again so that everyone has everything relevant in sight. There is no time for long discussions or for establishing understanding. It is very important that the Design Sprint team is absolutely aware about the challenge, the goal of the Sprint, and that everyone knows why we run the Sprint. The result of the Sprint stands and falls with the goal and the formulation of the challenge.
Establish a common Understanding on the Subject Matter before and in the Sprint
Is everyone technically and with regard to the subject matter on the same level? If not, we should definitely plan enough time before or during the Sprint for “getting on the same page”, because there is hardly any time for this within the Sprint.
During the Sprint, on the first day, we have the step “Drawing the Map”, which is the visualization of current state and final goals regarding the user flow through the product or service, a process, or an architecture. Especially when it comes to very technical or already very elaborate topics, it is tempting to use existing visualizations (e.g. architecture diagrams) instead of building a new map with all Sprint-team members involved, and thus get a common understanding on the subject. If you use existing material, chances are high that you get the impression that “everything is clear”, that everyone understands them, and important questions may not be asked: Because one does not want to hold up the group, because it is not possible to identify straight away where there are ambiguities, or because someone simply does not want to exposure oneself for not understanding exactly what is being presented.
In our case, we thought we were safe but the actual lack of clarity fell on us later: We had to spend time during the Sprint to establish the common understanding and then catch up on the technical discussion. Therefore, in the future we will never use existing elements again. We will make sure that we schedule enough time for the team to build the map during the Sprint so that the common understanding is established right away. It is important that the map is created with all of the Sprint Team members.
Thus, I recommend that you plan enough time for the map, make sure that all the necessary information is available and that the team members feel technically and thematically well equipped for the Sprint. The trick here is to prepare the participants well without overloading them with too much data.
Does everyone know what they have to expect?
Unfortunately, we did not have the opportunity to meet the team in the short time before the Sprint to prepare them for the week. Next time I would insist on a Sprint-intro session. Having such a session is important so that everyone knows what to expect and what the week will (roughly) look like. It should made clear that the Sprint week will be very intense and demanding. Therefore no one should plan meetings or working on non-Sprint tasks before and after the Sprint days. They should be made aware that they should take good care of themselves: Get good and healthy food beforehand, nerve food if necessary, plan activities away from the screen for your breaks, etc.
The roles of the participants in the Design Sprint should be clarified well in advance
Are the roles of the participants clear?
If not, the following questions should be answered:
- Who are the “makers” (the people who get creative and do the work in the Sprint) and what skills do they bring with them?
- Who is the decider? If the product owner (PO) is not the decider, what does he/she contribute?
- Who facilitates the Design Sprint?
- Who are the experts, people affected (e.g. users of the product/service or affected teams etc.), and stakeholders which should be interviewed and give feedback?
In a Design Sprint, for example, no project manager role is foreseen. In our context, however, some projects are led by project managers and not by POs. Therefore, the question is what role does the project manager play in a Sprint if he or she does not have the decision-making role?
In our case, we assumed that the project manager would be part of the Sprint team because she had a lot of knowledge about the topic and about previous projects on this topic. But on the Friday before the Sprint it turned out that she did not see herself in the Sprint team and the decider role was held by someone else. Without further ado, it was decided that she would only participate as a stakeholder, i.e. not be present for the entire Sprint. This led to resentment. Certainly, with more time to prepare, this would have come up earlier and another, better solution could certainly have been found.
And finally, do all participants know why they and others are there? This sounds trivial, but if the team is thrown together and is then meeting for the first time on the first day of the Sprint, no introduction round will help to completely clear up any confusion. And again, there is no time in the Sprint to deal with such matters for long.
Provide clarity on who is being interviewed and for what purpose
For the stakeholder and expert interviews, the relevant people should be selected in advance, if possible together with the Design Sprint team. In any case, everyone should know why they are being interviewed. For example, is it about requirements, constraints or technical input? If it is clear early enough who the stakeholders are and what stake (interest or claims) they have in the project, it can be clarified before the Sprint what can be asked of them or what input they will give.
Of course, it is also important that the stakeholders, experts and users are available for interviews and presentations*. A Design Sprint is tightly scheduled, so all relevant people should be invited to the interviews and presentations early enough.
* In our Concept Sprint there were no real user tests, our prototypes were architecture maps, and the “users” were affected teams. Our “test” was a session with stakeholders, people from affected teams, and experts in which the Sprint team presented the result and asked for feedback.
2. Are the right people in the team?
Are all the relevant people and thus relevant skills on board? Is the Design Sprint team committed 100% to the Sprint?
Ideally, 5 to 9 people are involved in a Sprint:
- One Decider
- One Product Owner — in many cases the PO takes on the role of the decider
- Maker — the Design-Sprint team should be cross-functional, including people from areas relevant to the problem (e.g. other departments or teams)
- Facilitator(s)
When selecting Design Sprint team members, the question of voluntariness and motivation must be asked
Do the potential Design Sprint team members want to participate in the Sprint? Do they have the needed skills? Do they have the capacity? Do they have curiosity and openness about the topic?
If this is not the case, a Design Sprint should not be run.
Especially in complex areas (and that’s where we are when we conduct a Design Sprint), it is necessary to work with experts, creative minds, experienced people, idea-havers, who are enthusiastic about a challenge and like to venture into new territory and are not deterred by uncertainties. If the Sprint team members are not participating voluntarily, the enthusiasm will be low and the Sprint week will be seen as a burden that keeps them away from their actual work. A lack of voluntariness is achieved if, for example, the Sprint team members are chosen only for capacity or if a team as a whole is assigned to run a Sprint because the topic basically suits the team, but not all team members are really interested in it.
It can be a good idea to cast the team for the Design Sprint. Announce your project, announce what the Sprint Challenge is, what skills are needed and in what timeframe the people are needed so that those who want to participate can apply to take part. Make sure that those who want to participate are released from their regular duties for the project. This way you can probably get the best people together for your Sprint.
100% presence of the Design-Sprint-team members
All participants should be available for full days throughout the week — no “hop on, hop off”. Getting everyone back on the same page takes time, and it is frustrating when not everyone can participate in the whole process, missing parts and thus not being as effective as those who are there for the whole time.
Introducing the Design Sprint members to each other before the Sprint makes the team productive faster
Within a Design Sprint there is not much time for the team members to get to know each other. Even though the Sprint itself has a very team-building effect due to the intensive collaboration, it is a great advantage if the first meeting has already taken place the week before in order to get into productive work more quickly.
After the Sprint
When planning a Design Sprint, it is essential not to forget the follow-up. This includes, for example, the review and integration of feedback, possibly even a Design Sprint iteration, validation of hypotheses, coordination, refinement, and creating a backlog etc.
And it is important to get into implementation as quickly as possible after the Design Sprint in order not to lose motivation and momentum.
But enough about that for now, this topic would be worth writing another Blog Article.
Conclusion
When everyone works very hard and with good vibes — and yes, fun! — very good results are achieved, then that is great. In our case, the Sprint was nowhere near as motivating and energizing as it could have been due to the much too short preparation time and the resulting insufficient or late clarification. We had results in the end — but I have the impression that more could have been achieved. The Design Sprint team worked very hard even though not all team members were 100% available, not all relevant people were in the team, although the team was not sufficiently prepared and not everyone was convinced that a Design Sprint would be the right thing to do. There was a lack of voluntariness and there was resistance. During the Sprint we had to overthrow quite some things and in the end we deviated strongly from the classic set-up. The short preparation time, as well as the execution of the Sprint, was extremely strenuous for all participants and in parts even frustrating. In spite of all this, I find it remarkable and praiseworthy that the team found approaches to solutions that were worked on afterwards. But at what cost. And in the end, it doesn’t feel very good, it has an unsatisfying aftertaste. Honestly: I don’t want to experience such a Design or Concept Sprint again — for my sake and for the sake of the team.
In a nutshell, our two most important lessons were:
Be prepared well enough and
make sure that the team is committed (willing and able).
So why did we agree to the assignment? On the one hand, it was the importance of the project, the will to support, the joy of Design Sprints and perhaps also some hubris.
On the other hand, we Agile Coaches had just changed our way of working with our clients from permanent support to assignment-based collaboration. Since such changes are not always enthusiastically welcomed, we didn’t want to start with two “No’s” to the same client, because there had already been a request that we had to reject.
Maybe, after many good experiences where we always managed to get it all worked out nicely, I had to “touch the hot plate” once to bring myself back down to earth. So next time I will again have to clearly demand everything necessary or refuse a request.
I would be glad if this article would help to understand why we Agile Coaches sometimes say “no”, why we ask a lot of questions and why we tell you that you also need to take time for an assignment. This is not meant to be torture, but is necessary. ;)
If you are thinking about doing a Design Sprint, this article may help you to decide if and when you can do one. If so, I would be delighted!
And dear colleagues, if you have questions, ask! You can contact me or write an e-Mail to the Agile Coaches at idealo.
References
- Knapp, Jake. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Redline, 2016. (amazon link)
- Design Sprint remote: Wie Covid-19 neue Wege der Product Discovery und Delivery ermöglicht (German)
- What Is a Concept Sprint and What Is the Difference to a Design Sprint?
- What is a Design Sprint and why you should care
- What is a good Design-Sprint Challenge?
- What kind of Problems can you solve with a Design-Sprint?
- When a Design Sprint isn’t the answer
- The Design Sprint hammer
- Frequently asked questions about design sprints.
- How to assemble your design sprint team
- The Dirt: 10 Things to know when planning a Design Sprint
Design Sprint Checklists
Do you love agile product development? Check out our vacancies.
