Current situation around Covid-19 outbreak has shown us that regardless of economic growth, new challenges, our society has never encountered, might arise — less or more serious. Nevertheless, all these challenges often mean huge problems for companies and they often must come up with innovative solutions to keep the company going no matter what is happening.

A larger problem arises when a situation around the challenge is super unclear and very hard to predict as it was (maybe still is) around the Covid-19 pandemic. For such situations, it is necessary to have a tool that they know they can rely on for being able to prepare for possible scenarios and prepare the company for the future adoptions to upcoming changes.

As Sprints [1] are a great way for inventing new solutions to existing problems and are widely used from tiny companies to large corporations it is definitely a method that suggests itself to be used for such purpose too.

The problem is that design sprints were invented as a tool for coming up with fast and effective solutions to current problems with a certain amount of assurance of knowing how these problems are going to develop in the short/long term. This is not a case of all the problems — e.g., Covid-19 outbreak where it is not sure how the situation is going to develop in a week, let alone months, years. For such purposes, we need to approach different methodologies that are way more suitable. On the other hand, it is not always necessary to reinvent the wheel and we can learn from what we know it works and we can use that as a frame to build upon it.

For such purpose companies could use a concept of Futures Sprint. Futures Sprint has the essence of the classic Sprint that companies across the world are regularly using. On the other hand, as mentioned above, some of the aspects of it have been adjusted to better serve the purpose of helping with coming up with possible solutions for plausible futures.

Its goal is to come up with solutions for most of the possible futures, create prototype of solution for most probable one and test it but also be prepared for other alternative scenarios.

For the sprint itself you need the same tools (post-its, big white papers, whiteboard) and type of participants [2] as for a regular Sprint with one exception, the domain expert.

Facilitator – Facilitates the whole process of design sprint, is responsible for sticking to the time schedule, speeds up the decision process.

The Head — Usually an executive officer who makes the decisions. He/she has the power of deciding which way should the whole team go based on the arguments from all the experts.

Design expert — Knowledge of the design process.

Marketing expert — Person who is going to promote the final outcomes.

Tech expert — Expert who understands how difficult different technical solutions are to develop.

Financial expert — Oversee the financial part of the whole project, knows what is economically feasible and what is not.

Customer Service expert — Understands the customers the best as he/she is the one talking to them on daily basis.

The Domain expert — This is basically the biggest difference from a normal Sprint. As this position is usually optional, in Futures Sprint it is a must. Most of the problems being solved by Futures Sprint are not problems that would be solved on daily basis and the companies often don’t employ experts in such field, it is important to invite also a domain expert who will help the team with answering domain-specific questions.

The goal of this day is to define and understand the problem we are facing and come up with as many possible future scenarios as possible.

Firstly, the team needs to reach an agreement on how far future they want to investigate and design the solutions for. This should be just a rough estimation as the team is going to conclude an exact time interval in future stages.

Unlike in a regular Sprint, you do not have to start with gathering different problems of which you would choose one that you would solve. Instead, you start with agreeing on the definition of the problem the company is facing.

One of the possible methods for that can be to use a mix of the Problem Tree method with the Futures Wheel method. The whole team starts with everybody writing down the definition from their perspective. Once everybody is done, they post their definition on the wall, read all the other definitions and then they vote (using small dot stickies, everyone has two votes) which definition they like the best. Once, they are done, they choose an option with the most votes. This one becomes the central node of the tree and is going to be placed in the middle of the canvas. After that, the team starts creating branches by writing down the sub-problems (on post-its) that are currently being caused by the main problem. They then add them to the canvas too and connect the preceding node to it (e.g., a problem caused by the root problem is going to have an arrow from the root to the new post-it). Once the team is done with all the problems that came to their mind, they start with the future part of the Problem tree method. They as a team now choose a different colour of post-its and write down the sub-problems that might be caused by the existing problems in the future. Again, they post them to the canvas and connect them to their preceding nodes. They continue at least until they reach the date they have stated in a previous step.

This way the team will be able to see a context of all the possible problems that are in there and help them during further methods. Also, they may find out that the main problem has not been initially set correctly and they need to change the root node to a different one.

Once the team is done with the problem definition, the next step is to start analyzing what possible futures might actually happen. For this purpose, we can select from countless options of problem futures forecasting methods like Forecasting, Future Mapping, or others. The facilitator might choose whichever method fits their needs best. The only requirement is that the outcome of the method(s) has to have as many possible future scenarios written down on post-its as possible.

That is because the last step before the end of the day is to create a huge canvas of three parts — Possible, Plausible and Probable — where the team places all the scenarios they have come up within the previous step to a corresponding category.

At the end of the day, the whole team should have a clear vision of the problem they are trying to solve and to have an idea about different future scenarios.

The second day, on the other hand, is not that far from the original Sprint concept — to come up with possible solutions to the problems and futures we have come up with yesterday. The only difference is that during the Futures Sprint the team does not have the luxury of being able to choose one specific problem and creating a solution to that. This time, the goal is to come up with as many solutions as possible to all the created futures we have put to the three-category canvas.

Again, in this case, the more the better. We can use choose from methods like Crazy 8, Brainstorming, Brainwriting to methods like LEGO Serious Play. The goal is to have a wide range of possible solutions from the ones that solve only a small part of one possible future to broad solutions that would solve multiple future scenarios. Each of these solutions is then written on a post-it and added to the appropriate scenario on a three-category canvas.

Lastly, the team then agrees on the probability of each of these scenarios actually happening. They write a capital number from 1 to 10 on each of these post-its of 1 meaning a super low probability of the scenario happening and 10 a scenario that is going to happen for sure.

The goal of this day is to choose a solution that is going to be prototyped in the following days.

For choosing the ideal candidate we will use the numbers from the previous day. The goal is to select 7 top solutions that have the best probability/effectiveness ratio. To make this easier, you can create a scale with two axes — probability and effectiveness — and post a post-it of each of these solutions in there. Top 7 from the high probability and high effectiveness quadrant are the selected ones. For each of these solutions, the team is going to sketch a storyboard and post them on a wall.

Again, at this point, multiple ways of decision processes might be used. One of the solutions is to start by giving every member three dot stickers which they will use to put on storyboard frames they find most interesting, without talking to each other. Once finished, every member goes through one storyboard of their choice (all should be discussed in the end), describes it, comments their opinions on it and discusses it with others. The team is allowed to do changes to the solutions and storyboards based on the discussion.

Once this argumentation is done, the final voting comes. Every member gets a dot sticker (of a different colour than in the last step) and the Head gets three of them. Everyone then votes for their favourite solution. This solution will be then used in the following days to be prototyped.

Unlike in a regular Sprint, the rest is still a highly valuable material. The team writes the scenarios — problems — solutions down into a durable form (electronic document of your choice) and keeps it for the future. If the chosen scenario is not going to come true, the team can always easily access the already researched information and use it for different solutions.

From now on, the scenario of the sprint is pretty much the same as in a regular Sprint.

On Day 4, the team creates a prototype of the solution. Keep in mind that the prototype should be usable, but it does not have to be perfect. The team only has limited time.

The final day is dedicated to the testing of a prototype. The goal is to try if it actually makes sense and to learn from the users’ feedback. Based on Nielsen’s model [3], it should be enough to interview around 5 users as it should show you approximately 85% of all potential problems of the prototype. Usually, this task of testing would come under the designer’s competence while it is highly advised for others to watch the testing happen (ideally not in place, so that the respondent is not under additional pressure). To see how the prototype is used is not only a reward for the whole team’s hard work but also very important for the executives to see what change the team has come up with in practice and how they work.

The Futures Sprint should serve as a tool for teams who are facing an unprecedented challenge that is hard to forecast. The tool provides them guidance throughout the 5-day process to ideate possible scenarios of the future, come up with solutions for such scenarios and create a prototype for the most probable one to give a company an instrument against an unpredictable future.

[1] Knapp, J., Zeratsky, J., & Kowitz, B. (2016). Sprint: How to solve big problems and test new ideas in just five days.

[2] Lo, G. (2021, January 26). What’s a Design Sprint and why is it important? - UX Planet. Medium. https://uxplanet.org/whats-a-design-sprint-and-why-is-it-important-f7b826651e09

[3] Nielsen, J. (2012, June 3). How Many Test Users in a Usability Study? Nielsen Norman Group: UX Training, Consulting, & Research. https://www.nngroup.com/articles/how-many-test-users/