Executing Design Sprints - The Agile Way

Introduction:

As a leader, I've always believed that the key to unlocking a team's full potential lies in creating an environment where individuals feel empowered to be their true authentic selves. In the context of design sprints, this means fostering a culture that values collaboration, creativity, and experimentation. In this article, I'll share my insights on how to execute design sprints the agile way.

What Problem Are We Trying To Solve?:

In Agile, it's crucial to attack the right problems. This means taking the time to understand our customers' journey map and identifying the painpoints they're encountering. We need to ask ourselves: What are the specific challenges our customers are facing? Why are they encountering these problems? What are the underlying causes of these issues? By gaining a deep understanding of our customers' needs and painpoints, we can start to formulate a clear problem statement. This is where the "how might we" (HMW) question comes in. The HMW question is a powerful tool that helps us frame the problem in a way that's actionable and solvable. It's a question that encourages us to think creatively and come up with innovative solutions. For example, "How might we simplify the checkout process for our customers?" or "How might we improve the user experience for our mobile app?" By crafting a clear and concise HMW question, we can give our team a clear direction and focus for the sprint, and ensure that we're tackling the right problem. The goal is to come up with a HMW question that is specific, measurable, achievable, relevant, and time-bound (SMART), and that aligns with our customers' needs and painpoints. By doing so, we can create a clear and compelling problem statement that drives our sprint and guides our solution.

Define Our Hypothesis:

With a clear problem statement in hand, it's time to define our hypothesis. A hypothesis is a educated guess that answers our "how might we" question. It's a statement that outlines what we think will solve the problem, and why. A good hypothesis should be specific, testable, and falsifiable. In other words, it should be clear what we're trying to achieve, how we'll measure success, and what will prove our hypothesis wrong. For example, if our HMW question is "How might we simplify the checkout process for our customers?", our hypothesis might be: "We believe that by reducing the number of steps in the checkout process from 5 to 3, we can increase conversion rates by 20%." This hypothesis is specific, testable, and falsifiable, and it gives us a clear direction for our design sprint. By defining our hypothesis, we can ensure that our design sprint is focused on solving the right problem, and that we're working towards a clear and measurable goal.

Time To Sketch!:

So at this point, we've identified the right problem, and we've established our hypothesis. Time for the fun part; sketching. At this point, everybody can put their creative hats on and roughly sketch their creative ideas for what the ideal solution to this problem is. We want to keep them authorless so that team members are not inadvertently influenced by the authors and their past work. We also want to keep things low fidelity at this point, sketch just enough to get your idea across. Upon completion of the sketching phase, all of the ideas will be put up on the white board for everybody to review.
The team can vote on their favorite solution, and embark on a course of action together.

Keep in mind, the solution we agree upon needs to enable us to measure against our hypothesis. Our next step is our Prototyping or Build phase.

Build:

We're moving right along here. We've agreed as a team which sketch we like best, and now, we're ready to build our prototype. During our prototyping phase we need to remember that we arent shooting for perfect here. We are going to be running an experiment to validate or invalidate our hypothesis, and this prototype needs to enable us to gather insights that will help us refine our eventual solution. We want to build something just good enough to get the authentic user feedback we are looking for. It's not something that is going to go into production, and its not something that needs to rapidly scale.
For example, say we are testing a hypothesis that customers want their groceries delivered by a driverless car. Rather than building an actual driverless car to perform our experiment, what's a scrappier approach that can allow us to get the same insight? Maybe its something as simple as a driver wearing a costume so that it appears as if the car is driverless. The whole purpose of our sprint is to actualize our hypothesis quickly. The faster we can get a scrappy prototype together, the faster we can start conducting our experiment.

Conduct Experiment and Measure:

With our prototype in hand, it's time to conduct an experiment and measure the results. This is where we put our hypothesis to the test and gather feedback from real users. The goal of our experiment is to validate or invalidate our hypothesis, and to gather insights that will help us refine our solution. To conduct a successful experiment, we need to define a clear test plan, identify our target audience, and determine how we'll measure success. We also want to find the right sweet spot for number of participants we'd like to participate in this experiment. Studies show that as little as 5 interviews can give you a diverse enough participant pool to get all of the opinions you'll likely encounter.
Anything greater than 5 and you liklihood of duplicated opinions goes up. It can also be alot of work conducting the experiment and performing the user interviews. 5 participants helps us keep this manageable. Remember that it's important to ask questions in an unbiased way so that you are getting authentic and genuine feedback.

Learn:

With our experiment complete, it's time to analyze the results and learn from our findings. This is where we take a step back and reflect on what we've learned, what worked, and what didn't. We want to identify patterns and trends in the data, and use those insights to inform our next steps. Did our hypothesis hold up to testing, or did we discover something entirely new? What did our users like about our prototype, and what did they struggle with? By taking the time to thoroughly analyze our results, we can gain a deeper understanding of our customers' needs and preferences, and make data-driven decisions about how to improve our solution. This is also a great opportunity to identify any assumptions we made that were incorrect, and to challenge our own biases and assumptions. By doing so, we can refine our solution and make it more effective at solving the problem we set out to solve.

Iterate:

Design sprints are not a one-and-done process. Rather, they're a cyclical process that involves continuous iteration and refinement. Once we've learned from our experiment and refined our solution, it's time to iterate and repeat the process. This is where we take our newfound knowledge and use it to inform our next design sprint. We may need to go back to the drawing board and redefine our problem statement, or we may need to make tweaks to our prototype and test it again. The key is to be willing to iterate and refine our solution until we've achieved the desired outcome. By embracing iteration, we can ensure that our solution is truly meeting the needs of our customers, and that we're not just settling for "good enough." Iteration is where the real magic happens, and it's what sets design sprints apart from other design methodologies.

Closing Thoughts:

One final point that i'd like to make is this: agile design sprints are not the same as agile product development. Our design sprint helps to inform our product team of what to build next. When we've realized we know exactly what the customer wants, we can hand it off to our product team and get it added to their backlog. Agile product development is an entire process of its own. Stay tuned for an article on that next!