Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days
Sprint: Summary and Review
Keywords: Decision-making, Design, Facilitate, Map, Meeting, Product development, Prototype, Research, Teamwork, Workshop
Please Note: There are links to other reviews, summaries and resources at the end of this post.
A sprint is a five day intensive workshop to help teams find new approaches for problems in the business world. Although the method could probably be adapted to suit any type of challenge, it’s primarily geared toward product development and design
The book is divided into five days in order to show the activities that will take place on each day and to give a sense of the pacing of the sprint. At the end of each section, there are practical recommendations and tools for facilitators including interview tips, checklists and the like. The reader should not skim past these facilitation notes. They consist of practical advice for staying organized and keeping the group on task. Even the experienced facilitator will probably appreciate the inclusion of the facilitation notes. There are a myriad of details to take into account when putting together a project like a sprint, and having reminders to cover all of the logistics is certainly useful.
There is a fair amount of important information hidden in the front matter. The whole “sprint” idea that the book is based on is explained in the introduction. Readers who skip the introduction will miss this important context. Appendices include concluding notes, numerous checklists, several pages of frequently asked questions and extensive acknowledgements.
This is an easy read, with the kind of clear and accessible language one expects from a how-to book. The many pop culture references, however, are likely to make the book seem dated sooner rather than later.
This is an eminently practical guide. As impossible as it may seem on the surface, teams that follow this method closely will be able to make significant progress on any challenge within five days. No problem, we are assured, is too big for a sprint. Following this method gives a work group many helpful tools for generating alternative solutions and for testing them in an extremely short time frame. The value of such a method should be apparent to any manager or executive.
James Freeman founded Blue Bottle Coffee. It was a successful company, but Freeman wanted to improve Blue Bottle’s online store. So a team, including Freedman, the online store programmer, the COO, the CFO, the communications manager, the customer service lead and the executive chairman, committed an entire week to a sprint. They met on Monday, beginning by talking about customer experience and how to help customers select between the different types of coffee. By Wednesday, they had generated many different solutions to the problem. The three best ideas were prototyped in mocked-up websites, and customers were interviewed to see how they liked the prototypes. By Friday, they had solid information on which to base their decisions. Blue Bottle created and launched their new website, and online sales growth doubled.
Sprints are a great way to kick off long-term projects like a new website, but they are good for a wide range of circumstances:
- Managing risk by doing a reality check before starting a large project.
- Generating fast solutions in light of an approaching deadline.
- Facilitating innovation and providing inspiration to help you find a fresh approach.
Sprints take a lot of focused energy and a lot of work. They are not for minor problems; sprints are good for big problems.
It’s good to first solve the customer-interfacing part of a problem, and then track back to the technological systems. The customers are the people who will hopefully make the decision to buy your product, so take care of them first and let everything else follow. Dealing with the surface like this helps you answer the big questions, before you commit to doing something.
Ocean’s Eleven is a great movie about a gang of criminals who orchestrate an elaborate heist. The gang works well together as a team, and they each have specialized skills. Sprints are like good capers: teams use their skills and resources to take on a challenge.
There are people with different roles on a team, the most important of which is probably the “Decider.” The Decider in a sprint is the person who ultimately decides whether to go through with an option. These are usually busy people, but given their role, their presence in the meeting is crucial. The authors suggest that the person designated as the Decider will often reject the first invitation to join a sprint, so they offer some helpful suggestions for how to win over the Decider. When it comes to selecting the Decider, this person needs to have expertise, vision and authority. If the actual boss can’t attend, they need to send someone to represent their interests. This person must be authorized to make decisions.
The teams should be a mix of people with different areas of expertise. Besides a Decider, some other roles you might need to include:
- The Finance Expert.
- The Marketing Expert.
- The Customer Expert.
- The Tech Expert.
- The Design Expert.
You’ll probably want to bring in other experts occasionally to present information to the team. It’s good to bring these people on Monday, when things are just starting and you’re laying a foundation. You’ll also probably want to invite troublemakers — the kind of people who might be argumentative because they really care about the project, not just because they’re jerks who like to argue. Finally, you need a Facilitator. This person should be able to look at things neutrally and be objective. The Facilitator and the Decider usually shouldn’t be the same person.
You sprint schedule will be 10 a.m. to 5 p.m. every day over the course of one week, with an hour-long lunch in there somewhere, except for Friday, on which you will begin a bit earlier at 9 a.m. In order to be extremely focused, you can only meet in the sprint for so long each day. People waste a lot of time transitioning from one activity to another, so time management is important.
There are a few basic rules that everyone should know and follow:
- Laptops, phones and tablets are strictly forbidden. They suck energy. You can look at these things during the break, but if you seriously cannot wait, at least leave the room where everyone is working.
- Tend to the practical logistics of the meeting space. Get at least one big whiteboard, if not more. There are several different kinds from which to choose; your needs and your budget will determine what’s best for you.
- Stock up on office supplies before you start: paper and pens, whiteboard markers and erasers, etc.
- Be sure to get a timer — it will be a very important tool during the sprint week.
- Finally, you might as well order snacks while you’re at it. You have got to keep up the team’s energy, after all. And coffee. (There’s a suggested shopping list in the appendix so you don’t forget anything.)
When there was an explosion on board the Apollo 13 spacecraft, it was touch and go for a while about whether the craft and crew would successfully return to earth. In the film made about Apollo 13, there was a scene in which the flight director drew a simple diagram on the board, illustrating how the spaceship was to circle the moon and then return to earth. This diagram helped everyone in Mission Control stay focused on the goal, even when things got chaotic.
Sometimes we get lost in the weeds. When a problem arises, you want to fix it right away. But don’t panic — the first thing you must do is take a step back and analyze the situation. Similarly, when you have a sprint, spend the first day getting organized and collecting information. Don’t try to solve the problem today.
Your first task is to set a long-term goal that everyone on the team can get behind. The goal might be obvious at the outset, or it might emerge after much discussion. And it’s okay if the goal is ambitious. The sprint will help you make progress toward your goal even if you dream big. Channel the Apollo 13 film, and write the goal at the top of a whiteboard. Keep it there for the entire week of the sprint to help everyone stay focused on the goal.
Next, turn your attention to something less pleasant: imagine it’s a year later, and the whole project had been a catastrophe. Ask yourself “What went wrong?” Unexamined assumptions are a great risk, and by doing this exercise, you can question these assumptions.
List your “sprint questions” on the whiteboard:
- What questions does the team want to have answered by the sprint?
- What must be true to realize the long-term goal?
- If you fail, why would that have happened?
You might generate a big pile of sprint questions, or just one or two. Whatever the results of this exercise, you’ve hopefully at least looked at your fears and listed them all. In doing so, now you know what you’re up against.
Lord of the Rings is a complex story told on epic scale. It can be hard to keep track of everything that’s going on, which is why it’s helpful that there are maps at the beginning of each volume. Maps, too, can be useful during a sprint, to simplify and help you understand an otherwise complex situation.
Your map should be simple. It doesn’t have to show all the details, just the basic steps a customer must take from beginning to end.
Sprint provides some examples of maps, which share common features:
- List all the key actors at the left — anyone with a role in the process should be listed.
- Have the ending on the right — whatever the desired action is at the end.
- Link the beginning and end with words and arrows.
Ultimately, your map will be customer centric and will illustrate the process like a story, with a beginning, a middle and an end. It’s not necessary to show problems and exceptions to the process. What you say will necessarily depend on the situation — just remember to keep it simple.
As you draw, you should continuously solicit feedback from the team. As them if you are getting it right.
Finally, once you have the first draft of the map, be prepared to change it and correct it. You should always add to the questions and update the map as needed.
Spend most of Monday afternoon interviewing subject matter experts: people on the team, other people in the company or outsiders who are coming in for the day as guests. As you talk to the experts, gather information that will help you decide on the target of the sprint.
Remember: you want to talk to experts, not just managers and executives. Often, leaders believe they understand things and know what’s going on. But the devil is in the details. No one knows all the details of a company, so inevitably, there will be important things that the boss doesn’t know.
The experts who should attend your sprint will depend on your situation, but consider the following:
- Ask the Decider about strategy. What do they want to have from the project? What would make the project successful? What are the risks and advantages?
- Find your customer expert: someone who interacts with the customer quite a bit, perhaps a sales or customer service representative. Ask them about customer preferences and any insights they have that would help you understand the customer’s viewpoint.
- Have as many experts as needed to understand the mechanics of your project. Perhaps you’ll need engineers, financial experts, tech experts or marketing experts.
- Talk to people who know about past attempts to fix the problem. If you’re working on something that people have tried to address in the past, try to learn from their attempts.
Take about 30 minutes or less for each discussion, but be sure to adequately introduce the expert to the sprint. The basis of your conversation with each expert will be questions. Does the expert agree with your assumptions? Is there anything wrong with the information you’ve posted on the whiteboard? What are the opportunities? Ask open ended questions.
At the end of the day, you’ll have a lot of information. Everyone should take their own notes throughout the day, and the exercise “How Might We” is recommended for sharing and retaining this group knowledge. In this exercise, sprint team members write their good ideas on sticky notes, phrasing each as “How might we …?” At the end of the day, everyone shares their notes. Look for themes. Vote on the notes. Put the most voted on notes on the map. This will give you a place to start looking for the target.
Marie Tharp originally discovered the Mid-Ocean Ridge in 1948, by plotting out data from sonar and developing a map of the ocean floor. Tharp found — right where no one expected anything at all — a giant ridge of undersea mountains stretching out like a zipper. Tharp thought the ridge was caused by plate tectonics, but at the time, this was an outsider theory. Once Tharp had her map, however, others were persuaded by this evidence and plate tectonics became established science.
At the end of Monday, you’ll be ready for your Tharp moment. By mapping many different data points, you’ll find something unexpected and significant. And with the information discerned from the experts, it should now be easy to see the most important parts of the project. With a fresh perspective, it’s time to choose a target for the sprint. Think about the most important customer, and figure out the critical moment of that person’s experience. Everything else is decided outward from this core.
Everyone on the team should have the opportunity to talk about what the target should be, but the Decider will pick the target. And they’ll do this by choosing one target event and one target customer from the map.
Often by this point, the Decider has enough information to make this decision. Sometimes, however, the right choice might not be so clear. In these cases, the Decider can ask for advice as needed. Whatever they decide will become the focus of the rest of the sprint.
Once a target has been decided on, review the sprint questions — at least one of these questions should be in alignment with your target.
In 1908, Melitta Bentz invented the paper coffee filter. She took two existing ideas — cloth coffee filters and blotting paper — and came up with something revolutionary: disposable coffee filters. The lesson to take home from this story is that, while it would be nice to get a sudden flash of inspiration, great innovation comes from using existing ideas in new ways. Reframing ideas by combining them with other ideas is something you can do with your time while you’re waiting for that flash of inspiration.
On Tuesday, you’re going to look for solutions. Start the day with a team exercise called “Lightning Demos.” Everyone takes turns giving three minute presentations on their favorite ideas, products or services. The ideas can be from within the company, from competitors, from another industry, from another domain altogether or from old projects and opportunities that were never realized.
Each idea should be given real estate on the whiteboard, with a note explaining “the big idea” as succinctly as possible. This is a brainstorming session, so you don’t have to decide anything now. You are just looking at ideas, anything that might be useful. Examine about 10 to 20 different ideas using this method.
You’ll have a lot of material to integrate between the map, the sprint questions, and the “How Might We?” notes. At this point, you’ll have to decide how the team will proceed. A threshold question is whether you want to divide up tasks or to address the problem as a group. For a focused target, it might make the most sense to keep the team working together. For those targets with different pieces, however, it might make more sense to break into smaller working groups. As much as possible, people should be able to pick the part(s) of the problem on which they’ll be working.
On Tuesday afternoon, everyone sketches out their ideas. Doing so will help people think about the problem in depth. You don’t have to be a good artist; you simply have to be able to draw boxes and arrows and similar stuff. Sketching is a fast and easy way to turn abstract ideas into concrete solutions. It’s easier for people to think about and evaluate ideas that have been sketched out. The sketches should be detailed and easy to understand.
It can be difficult knowing where to start with a task like this, so Sprint offers a template to help get the team going. The first step involves having the team quickly review some of the top ideas from the sprint so far. After doing so, everyone works independently on their ideas.
Go into the sketching process with all the information relating to your idea that’s been generated during the sprint — the maps, your notes, everything. For this exercise only, allow people to use their electronic devices for research. Spend some time doodling, generating solutions and giving some rough form to your ideas. Don’t worry if these sketches are messy — nobody needs to see them but you. After about 20 minutes, review your work and circle your favorites.
The next step is “Crazy Eights.” Each team member takes their best ideas and sketches eight variations (reasonable solutions) in eight minutes. Keep asking yourself what would be another way to get the job done. Sketch out the details of your solution; show what your customer sees when they interact with your product. This is an anonymous process, so don’t put your name on the sketch. But do give it a title so that when people talk about it they have some way to refer to it.
When everyone is done with the sketches, put them all in a pile and go home.
Now you have to decide among all the ideas that have been generated. It isn’t always easy to make a decision, and sometimes groups go around in circles trying to select the best option. But you can avoid this by approaching the decision making process systematically. Consider the following example to illustrate how this can be done.
A company made a game called Glitch, but it wasn’t successful, so the company shifted their attention to a side project. This particular side project was a messaging service they created to facilitate their work on the game’s development. They called it Slack. It was obviously very successful, but initially, Slack had challenges scaling. While popular with tech companies, other industries didn’t understand what Slack offered. So, the folks at Slack did a sprint to develop a way to explain to people, including potential customers, what it was that Slack did and what it could provide to a company.
The following outlines the five step decision making process this team used on the Wednesday of their sprint:
- They got the ball rolling with an art museum, hanging everyone’s sketches on the wall.
- They silently evaluated the sketches and created a heat map by using dot stickers to show team interest.
- They held a speed critique and briefly discussed the highlights of each solution.
- They took a straw poll by asking everyone to use a different colored sticker to pick their favorite.
- The Decider used a supervote by engaging in discussion with the team and consulting with the CEO.
Remember: Save the other ideas. Just because they didn’t get picked, doesn’t mean they’re bad ideas. You might want to revisit them eventually.
It turns out, you can pick more than one possible solution — for example, you might have two Deciders who each like a different solution — and there needs to be a way to break the tie in these cases.
One approach is to consider whether the two winning solutions can be combined into a single idea. (This is called an “all-in-one.”) Another method, called a “Rumble,” entails testing the ideas against each other. Split the team in two, develop the two prototypes and then compare them on Friday. You can even show the prototypes to potential customers to see which they prefer. (Create fake brands for the prototypes to help them stand out against one another.) It’s fun to create fake brands. Be creative; you and the team will enjoy it. But don’t waste too much time on this part, OK?
Everyone gets paper and a pen. They take a few minutes writing down their ideas. Then everyone takes another couple of minutes to look over their lists and edit them down to the best two or three ideas. Then, write everyone’s top ideas on the whiteboard. The group gets a few minutes to read over all the ideas on the whiteboard. Then, each person votes on their favorite idea. You can use those dot stickers because you probably have more than a roll of them left over anyway. Then the Decider decides. Being the Decider, they don’t have to decide on the same thing the group voted for, dot stickers be damned.
So now you know which solutions you’ll pursue and which prototypes you’re going to create.
The next step is to put the winning sketches together to produce a storyboard (about 10 to 15 panels long) that will illustrate the solution’s steps. The storyboard will call attention to difficulties and problem areas before you build the prototype. (Slack is again used as an example of how to proceed.)
Select one person to do the actual drawing, and have them begin by drawing a grid on the whiteboard, with each box being about the size of two pieces of paper. Decide what must happen first in the process, and write this in the top left box. Starting in the right place is important — it establishes the context — so you might even want to back up an extra step or two from the beginning. For example, the opening scene might show how the customer first hears about the product.
Add to the storyboard from there, as a team, incorporating the ideas from the sketches one scene at a time. The story should have a short time span. Expect each panel to equal about a minute of time with the prototype demonstration. This will help you keep your focus tight on the solution without fussing with extra bells and whistles.
If you run into a gap where the sketch doesn’t sufficiently explain a feature, you might be able to skip it. Unless it’s core to the function of the product, you don’t need to test it right away.
This work will probably take up the rest of the day. Don’t go for a polished result. It doesn’t have to be really detailed, but do include enough to ensure that viewers can understand what’s going on. And don’t pursue new ideas, just stick with the existing good ideas.
In a Hollywood Western movie, the frontier town with its grimy saloon was likely shot in a ghost town or Hollywood studio. The storefronts are just that — fronts. But when you watch the movie, it doesn’t matter. As long as it appears real, the illusion works. This is your goal for building a prototype.
You want to build something that is sufficient to give the illusion of what the real product will be like. You’ll build the prototype over the course of a single day, and this short timeframe is intentional. The more time you spend building something, the more emotionally attached you become and the more resistant you are to changes it if the customer doesn’t like it.
Getting yourself in the prototype mindset means setting aside perfectionism and being optimistic. Remember that the prototype is disposable. As soon as it’s no longer needed, it will become trash. Build enough so that you can learn from the process, but no more. Don’t get emotionally attached to it.
You don’t need a fully functioning product, you just need a façade with which the customer can interact. Nevertheless, the prototype should appear real so that you can see how people react to it. You want a reaction. This requires a balance — finding the “Goldilocks quality.” This is to say: you don’t want to produce something that’s flimsy and unconvincing, but you don’t want to be up all night working on the prototype. Strike a balance that’s “just right” for you and for your situation.
Every prototype is different, so not surprisingly, there are lots of different ways to create prototypes. The one that you make and how you create it will depend on your circumstances.
Some useful tools and activities include:
- Pick the right tools (software, processes, methods, etc.) for the job.
- For creating prototype websites or applications, Keynote comes highly recommended. Keynote and PowerPoint also work well if your prototype is on paper.
- If you are prototyping a service, you could write a script and use team members as actors.
- When prototyping a place like a store, use an existing space.
- For physical products, you might have to go with 3D printing. If that doesn’t work you could try modifying an existing object.
- If you’re working with something that’s super tricky to prototype, you could instead create a prototype video or brochure selling the product.
Divide up the tasks to create the prototype:
- There must be at least two Makers to make the prototype’s components.
- The Stitcher will take the pieces that the Makers made and put them together. (Preferably, this person is detail oriented.)
- The Writer will take care of generating any written material needed.
- The Asset Collectors will oversee gathering material that the team needs.
- The Interviewer will spend all day Thursday writing the interview script that they’ll use to interview the customer on Friday.
After you decide on roles, look at the storyboard and divide it up. Figure out who is providing each of the features; also look at the opening scene and how to set the stage.
At about 3 p.m., do a trial run to practice presenting your prototype. You will probably find things you need to tweak. If you end up with time on your hands, you can revisit your sprint questions to verify that your prototype is aligned with your goals.
Today, a team member (the Interviewer) will interview five customers who get to try the new prototype. The rest of the team is in another room, watching the interviews via video. You’ll interview the customers separately.
And five is enough. Research demonstrates that asking five customers will uncover 85% of the problems. Testing more people uses more resources with diminishing returns. The return on investment drops considerably. Nearly all important patterns will reveal themselves in five interviews, and often in less.
The interviewer will show the customers the prototype, let them play with it and ask them questions about it. The team should pay special attention to the customers’ reactions. The great thing about interviews is that you can see not only if the customer likes your prototype, but also why they feel as if they do. This is crucial. If you don’t understand why there is a problem, you won’t be able to fix it. If you have questions during the interview, you can just ask.
You can designate one person as the interviewer or several team members can take turns doing it. Whichever model you use, it’s good to have some structure for interviewing people. The interview process outlined in Sprint has been tested and tried by some of the best research teams:
- Begin with a friendly welcome. Greet the customer warmly and make some small talk; help them feel relaxed. Explain how you are soliciting their opinion to improve your product. Make sure they understand that negative feedback is fine. Also explain up front that the rest of the team will be watching from another room, and make sure they are comfortable with that. If you have legal paperwork for them to sign, in the form of disclosures and permissions, go over it at the beginning.
- Next, ask context questions. Depending on your market, you’ll want to ask them about their life, their interests and their activities.
- Introduce the prototype. Explain that it is a prototype and all the features might not be working properly yet. You will let them know in that case how it is supposed to function. It’s rather important to say you didn’t design the prototype (and that your feelings won’t be hurt by criticism) because then customers will be less inclined to spare your feelings. (Even if you did design it, say that you didn’t.) Ask them to think out loud while they look at the prototype and let you know every thought that pops into their head.
- Let the interviewee try a few tasks with the prototype. You might need to give them a few nudges along the way, saying, for example, “Say that you got this as a birthday gift. What would you do with it when you take it out of the box?” Don’t try to instruct them on every step; rather, see what they do. Ask them what they are thinking and how they would use the product. The questions should be easy to answer.
- Finally, debrief the customer and see what they think of the product overall.
Some basic techniques will improve your interviews. Think of yourself as a host, and the customer as your guest — and treat them accordingly. Ask open ended questions, you’ll get more information that way. Ask who, what, where, why and how questions. Maintain a mindset of curiosity. If you feel open and curious, it will spark you to ask better questions.
On Friday, you likely will see many different responses to your prototype. It’s not until the end of the day, when everything gets tied together, that you’ll get a sense of the answers to your questions.
Before the interviews begin, draw a grid on the whiteboard. Make five columns, one for each customer to be interviewed, and create rows that correspond to the prototype or prototypes. The rows might be for different features of the prototype, the sprint question you’re trying to answer or whatever else seems appropriate to the situation. Give everyone sticky notes and markers; instruct them that whenever they see something interesting in the interview, they should write down their observations on a sticky note. Use different colored markers for different kinds of notes (green for positive, red for negative, black for neutral), or use a plus or minus sign on the corner of the note to indicate opinion.
The team should be quiet during the interviews. Reacting and talking during the interview increases the odds of missing something important. (Also, even if the interviewee can’t hear or see the team, it’s impolite.) After each interview, put the sticky notes in the appropriate location on the whiteboard.
After the interviews, look for patterns between the interviews, paying special attention to commonalities between three or more customers. Everyone on the team should take notes on the patterns they observe. After about five minutes of individual review, the team discusses the observations. Using another whiteboard, list out the various patterns and label them positive, negative or neutral.
Look back at your long-term goal and your original sprint questions and see whether you have answers. You might not have an answer for every question, but that’s okay. By now, it might be easy to figure out the next steps to take. While the group discusses all that has happened, ultimately, it’s the Decider who determines what happens next.
After the sprint, you can look back, having spent a productive week working together on a project that really matters. It’s what a sprint is all about.