running a sprint
Q: Who is good to invite to a Sprint or how do I put together a Sprint team?
A: Obviously, it depends on the focus of the Sprint, but the value of a sprint comes from bringing together a cross-functional team of people, product managers, ux designers, engineers and researchers, those who will be the primary owners of the ideas generated in the sprint and working on the product moving forward.
There are a number of roles in a Design Sprint:
Sprinters Knowledge Experts User Research Participants Sprint Master Stakeholder
First you have the most critical people, the Sprinters. These are the folks that are responsible for creating the work in the Sprint and ideally the owners who will be working on the project after the Sprint. This should be a cross-functional group pulling from these roles: UX Design, UX Research, Product Management, and Engineering. At a minimum you will need atleast one Designer and on Engineer. The next role that people can play is a Knowledge Expert, this is someone who gives a lightning talk during the Understand Phase and has a particular area of expertise that is relevant to your Sprint Challenge. This can be done remotely via Video Hangout or in person. The final role is the User Research Participant, this is someone who has been recruited to come for the Validation phase and be a tester of the concepts that were created in prototyping.
Anyone who is required to greenlight the work, a key stakeholder or leadership role should be involved in the sprint planning and sign off on the challenge for the sprint. They can also be included at various points throughout the sprint to give feedback on the concepts and provide direction during the decide phase.
Q: Does everyone need to be present for the whole thing?
A: A: The Sprinters need to be present for the entire Sprint, during the beginning of a Sprint the team builds shared knowledge, establishes a shared vocabulary and set of goals, they are forming a strong team bond and collaboration style, everyone needs to be a consistent participant in that and if someone leaves or shows up in the middle it sets the team back to the beginning. Knowledge experts can join just for their presentation or the first day if they like. Finally Stakeholders or Leadership who frequently can’t set aside as much time can join for the Understand phase and then during critical check ins.
Q: What is a good challenge for a Sprint? When should I use a Sprint and when is not a good time to use a Sprint?
A: The Sprint Process is generally applicable to solving most user-focused challenges. It is a tool for generating solutions and testing them quickly, so testability is a key factor. If the problem you are looking to solve cannot be tested, then it may not be a great candidate for a Sprint. However, don’t underestimate the potential of the Sprint brainstorm process to uncover ideas that can, in fact, be tested. The core idea behind Sprinting is to ensure that meetings and brainstorms lead to action (not just more meetings). A great time to run a Sprint is at the initiation of a project to bring a new team together, or it can be helpful if you have a mature product but want to improve it and you have some useful user research a Sprint can help a team leverage that research to gain insights and generate ideas. As a process, the Sprint is a powerful tool to propel innovation and minimize wasted effort. Try it and discover what is waiting to be discovered.
Q: How do I get buy in from leadership to spend that much time?
A: The answer is testing. Management is often loathe to commit resources in the short term for fear of its effect on day to day operations, the dreaded reduced productivity. It’s a valid concern. But the Sprint Process is designed to test solutions as efficiently as possible. In one week you can propose a solution to a thorny problem and discover whether or not that solution actually works. Think about the cost savings inherent to that process - one week of labor gets you confirmed results in contrast to weeks or months of work that may or may not prove effective. It’s a bit like taking coordinates when you’re lost at sea. If you can confirm exactly where you are, it’s much easier to figure out where you’re going. In the long run, the Sprint Process saves time and money. That’s why Google uses it. tl/dr: Tell them Google does it.
Q: How do I get decision makers to join the sprint?
A: For starters, a Sprint is fun. It’s engaging, hands on, immediate, and vibrant. It breaks up the daily grind and asks people to get creative with one another. Second, the Sprint makes the ethereal tangible. It gets people out of their heads where they randomly daydream about solutions, and asks them to make those daydreams manifest. It’s literally empowering. Third, decision makers are often slightly removed from pain points of day to day operations. A Sprint gives them insight into their products, processes, and teams like nothing else. It can be revelatory for management. Finally, it’s really a short term commitment. A week may sound like a big deal (and coordinating that amount of free time among multiple stakeholders can be difficult), but the result is a solution to a real problem, brought to life, and tested for efficacy.
Compared to typical R&D timelines, it’s incredibly efficient and requires a relatively low level of commitment. Sprints can galvanize people, realign their perspective, build cross-team understanding, and affect the bottom line with an unprecedented immediacy. And again, it’s fun.
Q: What do you do with strong personalities or conflicts?
A: Sprints can’t fix personality. But with strong leadership from the Sprint leader and a commitment to staying in the process, we’ve found that conflict can be overcome. Remember, the Sprint isn’t about debate, it’s about finding a testable solution, building it, and testing it. Let the process win the argument, so participants don’t have to.
Q: How do I adjust the framework for my challenge?
A: The length of time and deliverables are the primary factor in flexing the framework. If your challenge is relatively narrow in scope such as “Improve the onboarding for my app” and you are looking to get high fidelity mocks in a clickable prototype for just the onboarding flow you can work backwords to set up your agenda and the necessary methods to help you generate those deliverables and solutions. If your challenge includes vision setting you might add in some methods for defining the vision of your product experience. The methods you select should directly relate to the deliverables you are looking to walk away with at the end of your sprint.
Q: How can I take the ideas from the Sprint and drive them to launch?
A: Typically, a Sprint will clarify how to build on its own findings - that’s what the testing is for! The final day interviews clarify where solutions are working and where they’re missing the mark. Those insights are a goldmine for creating consensus on next steps. Often next steps are abundantly clear and each team of stakeholders can take on the necessary tasks. When next steps are not clear, a follow up Sprint can help realign the questions being asked and lead to new proposed solutions. Trust the process - eventually solutions will arise.