Tips and tricks for running a successful discovery sprint

---

I work for a technology company. Moreover, in working for a company that relies on winning the business of other businesses in a wide variety of industries, I've had to quickly develop knowledge in areas that were previously unfamiliar to me. I've also learned that the best way to quickly (and thoroughly) understand a client’s business is to go through a discovery sprint.

"What's a discovery sprint?" you ask. Well, at Pillar (my company), a discovery sprint consists of a mix of information gathering, collaborative activities, individual exercises, and team discussions all of which are meant to ensure we're focusing on the right needs of the business and it's users.

This happens by:

• The stakeholders providing a solid understanding of the background, landscape, and purpose of the project
• Defining the problem and goals of the project as a team
• Building empathy and changing the perspectives of the team by understanding whom the users are and developing personas to represent them
• Understanding the user's journeys and experiences, so we can provide them with what they need when they need it.
• Converging with lots of ideas as a team and diverging of the best of them.
• Sketching, prototyping, and testing our ideas with users to gauge their viability

Discovery sprints come in a few different flavors and can vary in length depending on the size and scope of the project.

Being a facilitator of a discovery sprint is hard :)

As a facilitator, you'll be expected to do a ton of improvising and critical thinking on the spot. Improv and thinking that might freeze lesser facilitators right in their tracks, in front of their participants, just sitting there waiting, waiting, waiting…

No one wants that :(

Participants will look to you for a real-time analysis of your discussions and exercises — making it all make sense for them.

As I’ve been assisting or facilitating discovery sprints for a grip now, so, with a few successfully under my belt, I think it’s high time I share some tricks that I’ve learned along the way.

1. Plan damn you, plan.

---

Planning makes perfect

If there is one thing that you take away from this, I hope it is that you understand the importance of planning.

For a discovery sprint to be beneficial for you and your client, there has to be structure and a method to all the activities and madness.

One of the biggest misnomers I always come across is that people think true creativity can only be achieved alone, in isolation, and in pure spontaneity. Wrong. In my experience, creativity, at its finest, is mulled over, discussed, developed, by teams with diverse backgrounds and skills. Planning out the methods and structure to extract that creativity is critical for a successful discovery sprint.

Schedule your users for testing

If you plan on doing some form of user testing on a prototype that your group builds during the sprint — and I suggest that you do — get that on the books here and now. Getting real users through the door in time for testing during the discovery phase of a project is the area I see fall through the most.

Get An Agenda Together, Man.

So with any good ol’ discovery sprint, there’s usually a core set of activities and objectives that the group needs to accomplish.

I am not going to tell you exactly what you should do when, but mine usually goes a little something like this:

• Intros / Admin stuff / Ground rules / Explanations of dedicated areas in the discovery room, i.e., I like to set up an Ideas to Come Back to (Parking lot) space on the wall and explain its purpose.
• Background and information gathering (usually from the stakeholders and user interviews)
• Define problem
• Identify project goals (I use value stories and usually do one from the user’s perspective and one for the business)
• Understand and identify who the users are, their pain points, values, and goals.
• Understand (empathy maps help here) and explain the user’s journey
• Sketch, create and develop solutions through various group activities
• Choose your favs, build a prototype, and test with your real users :)
• Define the core features that are needed to build a minimum viable product

2. Case the Joint

---

Well, not really. However, it is extremely beneficial to know, beforehand, where you are going to conduct your sprint. There’s nothing worse than showing up on-site with the client, day one of discovery, without knowing what space you are going to be in, only to find that there are no whiteboards and the room is about five sizes too small. In a perfect world, clients would pay lots of money to come to you, the discovery guru. You would have the perfect space and complete control over your creative ecosystem. In reality, you have to roll with punches, changes, and lack of resources.

Here are some tips to minimize your spatial constraints:

• Bring your own gear (Don’t rely on the client to provide you with what you need. I like to show up with thick and thin Sharpie Markers, a ton of Post-Its in a bouquet of colors, large Post-It re-stickable paper, masking tape, index cards, GOOD whiteboard markers, a ream of paper, sticky dots for dot voting, and anything else I might need.)
• See the space you will be working in before discovery begins, if possible (Seeing the space will allow you to think about any adjustments to the room that need to happen before your discovery begins)
• Ensure there will be a plethora of whiteboard space

3. Have a wingman (or woman)

---

Support is good

Yep, it’s Goose. You know, Maverick and Goose? Iceman? Singing, motorcycling, flying, Take My Breath Away?

So, barring his untimely demise in Top Gun, Goose’s example helps to illustrate the importance of having someone that's got your back in times of need. If you haven’t seen Top Gun, apologies as the example above will fall flat.

There are numerous instances when having a wingman is essential like when:

• You do not want to lose your group’s creative momentum and need to transition to a new activity [Insert wingman]
• You need to take some time to do some quick analysis [Insert Wingman]
• You need to take a breather after a mentally laborious exercise [Insert Wingman]

Having a co-facilitator at the ready allows for all of that to happen. Plus, you can pack in more discovery goodness if your co-f is always getting a head-start on the next activity — with setting up and whatnot.

Most importantly, it ups your street cred, making it look like you have done this a thousand times and you have honed your discovery skills to a tee, which you have. Right?

4. Throw in some charisma and keep things interesting

---

Throw in plenty of relevant but off-topic activities.

Nothing is worse than an unresponsive, lackadaisical group that isn’t as gung-ho as you need them to be. A simple way to avoid drowning in the sandtrap of slothfulness is to pack your day with short, fun, relevant activities that keep your audience on their toes.

"Why should I do these crazy activities?", you ask

• They can relieve the monotony of talking about the same “ish” for too long
• They build teamie-ness :)
• They are great ways to get going in the morning or after lunch

Ice-breakers and Lunch-breakers

• Here are some of my favs:
• 6 Words (Larry Smith, look him up)
• How Might We? (Ideo, look them up)
• What if? (Group writes down their most audacious, ambitious, and crazy ideas for the project)
• Visual explanations (Give the group a topic, like making toast, and have them explain the process by sketching it out, no words)
• Mind Shift: Similar to Exquisite Corpse (Surrealists, look them up)

5. Know When To Pivot

---

“You gotta know when to hold em, and know when to fold em”

The great Kenny Rogers once told me this, among other things. However, the point is, there are times when you need to ride out an activity for the sake of the discovery’s progress, and then there are times when you should find an alternate route. So, if your sprint goes exactly as planned, and there is never a time when conversations tend to get stuck in the mud, you can skip this section. Also, if you skip this section, you are only fooling yourself.

In my experience the most common instance goes something like, someone in the group knows more about a certain topic of conversation than the rest. Said individual inserts themselves as the authority on the subject, and proceeds to dominate the group discussions. At this point, a mental red flag should go up, and you will know that it is time to switch tactics.

For issues like the above, my time-tested recommendations are:

• Turn to writing instead of talking (Let everyone write out his or her ideas on Post Its.This allows everyone to jot their ideas down before the nay-saying begins.)
• Break into small team exercises (Keep the teams 2–3 people. Small teams = big camaraderie.)
• Turn group discussions into a top thoughts session where the whole team gets to contribute, one at a time. (Set the premise that everyone will have a chance to talk. If you know who the alpha opinionator is, have them go last.)
• Move on. Don’t harp. (If an activity is not working, it is best to move on to something else and come back to it at another time. Don’t worry, on occasion; I have had to revisit an activity, that should have been finished on the first day, two or three additional times during the week just to get it right )

6. Don’t skimp on the Personas

---

Who are our users?

What an important question. If your group does not know, stop everything and start here. Moreover, if there isn’t alignment on your team for whom they are building a solution, how will they know what ideas and features they should be pursuing? Oh, and I should mention, personas should be rooted in user research, not just thrown together with the speculation of the group as the determining factor.

For the elephant in the room, yes, personas are just a tool but when developed and used properly, they become an invaluable tool for building user-centered solutions.

How many should I create?

As many as are needed to capture your target audiences. The number of personas can vary depending on the project, but I’ve typically found three to five to be the average. I’m not huge on the robust backstories, but I do have a list of “must-haves” whenever I lead a group in developing personas.

My Must-haves are:

• A persona’s basic demographic info
• A core value story (Something that sums up the epitome of that individual, wrapped in a value story )
• Goals (3-ish)
• Pain points/potential issues (3-ish)
• Voice of customer quote (Don’t make one up. If you can find a quote, use it.)
• Any other relevant fluff that’ll keep the persona concise and informative :)

7. Test damn you, test.

---

Remember when I told you to schedule your users for testing? Well, this is where it all pays off. Nothing validates an idea or prototype better than actual users. Oh and don’t think you have to create and conduct a super-formal test in an authorized lab. No, you can do some truly useful testing on a shoestring budget. In cases where your pre-scheduled users fall through (99% because of lack of planning), try some guerilla testing at your local coffee shop. Nothing gets people to participant faster than a red-hot $5 gift card that they can use right there, in the coffee shop. I usually just capture the audio and video with my phone and have one other person observe as I moderate.

My testing steps:

• Get your prototype together, quickly (Don’t spend more than an hour or two on it. A prototype does not have to be fancy. A simple mocked up sketch of the flow will work in most cases.)
• Create a set of tasks and follow up questions (I like to keep the number of tasks around five with one or two post-task questions.)
• Test with real users (Use the one’s you scheduled before the discovery sprint or if you forgot, wink wink, do some guerilla testing, as explained above.)
• Put together a (small) doc that outlines your recommendations moving forward.
• Boom. You are all done.

8. Capture everything. Everything? Ev-er-y-thing.

---

Be sure to take pictures of your activities.

Too often, I’ve seen (firsthand) an amazing whiteboard activity go into the ether of nothingness, erased from existence by an unknowing facilitator. Don’t let it happen to you.

Methods for capturing everything include:

• Getting into the habit of taking a picture of every activity immediately after it’s done. Doing so will also give you a photographic timeline that will help you to recall the sequence of events after discovery is over and you are organizing the findings.
• Use your phone (after all, it is portable, powerful, and easy to use)
• Have your wingman help out (have them get some “in the act” photos that can double as assets for some snazzy presentation decks)

8. Do Yo Retro

---

Retrospectives

In the world of agile, conducting a retro at the end of a sprint, exercise, get together, or anything is the norm. For those not familiar with the term, the idea is, after your discovery sprint is over, and as a group, take an hour to discuss and write out (preferably on a whiteboard) some feedback from the sprint.

The three things I like to capture are:

• What went well?
• What could be improved?
• What actions should be taken to make changes that are needed to improve?

Take heed to the topics that come up in retro and strive to adjust and improve for next time.

---

And, until next time, see ya!