Design Sprints for Scrum Projects
How Scrum Teams can become more design-driven and systematically build products that customers love.
Building great software isn’t easy. Scrum and other agile frameworks are the new norm for delivering software and help teams to ship better products faster. But Scrum alone isn’t enough to build a great product. As markets get more crowded, a good User Experience (UX) is becoming one of the key success factors for software businesses. Design Sprints are a great instrument which Scrum teams can use to become more design-driven and customer-centric.
The rise of User Experience
Product development teams are continually under the gun to get better products to market in less time and budget. Over the past two decades, Scrum has established itself as the most popular agile development framework for delivering software. It enabled teams to ship better quality products faster and be more competitive in markets that are getting ever more complex and unpredictable.
Scrum alone is no guarantee that your team will consistently deliver truly engaging, impactful products.
But being able to ship changes in fast cycles isn’t enough. One of the hardest parts of building software, is to make good decisions about what to build and how it can solve the users problem. In our fast moving world, customers are no longer willing to accept software products and services that they don’t understand or that are hard to use. They demand solutions that are specifically tailored to their needs and that allow them to get a job done as fast as possible. As a consequence, a great User Experience (UX) has become one of the primary market differentiators and a crucial success factor for software products. Everyone is now talking about frameworks like Design Thinking and Lean UX and companies are hiring more and more UX designers to make their products more intuitive and useful.
Scrum needs to become more design-driven
This is great. But there is one big problem. Scrum and other agile frameworks lack specific practices to systematically integrate design activities into the development process. As a result, design and development are often handled as two very separate activities that follow their own processes and are performed by independent teams. Designers are not fully integrated members of the Scrum team, but often take the role of consultants or service providers that support the developers with design decisions. In order to continue to build great products, Scrum teams need to become more design-driven and find new ways how they can systematically build solutions that solve the right problems.
Enter Design Sprints. Design Sprints are a relatively new framework and have recently become very popular within the design and innovation community. They allow a team to quickly identify the right problems to solve and test solutions through rapid prototyping and feedback. As such, they are a great addition for Scrum projects. Whereas Scrum is an approach to problem-solving and delivering solutions, Design Sprints are an approach to problem finding and understanding.
What is a Design Sprint?
A Design Sprint is a fast-paced, agile approach to product design. Essentially it’s a five-day process that allows a multidisciplinary team to develop and test new ideas using a series of highly-effective Design Thinking exercises. The outcome of every Design Sprint is a high-fidelity interactive prototype, tested by real users, and with clear insights on where to go next.
Design Sprints were originally developed by Jake Knapp at Google Ventures and popularized by the bestselling Book „Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days“. After great success, Design Sprints are now being adopted around the world by thousands of innovative companies of all sizes and industries — including brands such as LEGO, Ebay, RedBull, Slack, Lufthansa, Bosch and UNICEF.
A Shortcut to Learning
The core idea behind the Design Sprint is to develop and test new ideas without building and launching anything. So instead of actually implementing some minimal product increment (MVP) to see if an idea is any good, you’ll develop and get data from a realistic prototype.
This makes the Design Sprint an excellent tool to discover and explore requirements and to align a team around one unified perspective. Instead of wasting time writing and debating specifications in endless meetings, you wrap them in a prototype and put them in front of the customer.
How does a Design Sprint work?
In order to run a successful Design Sprint you need three basic ingredients:
- A well-defined challenge: A successful Design Sprint cannot start without a clearly defined challenge. The challenge determines the scope and the goal of the Design Sprint. Let’s say you have a SaaS product where you offer a free trial period, but you struggle to convert trials into real customers. In this case your challenge could be this: “How might we improve the experience during our 30-day trial period to successfully convert more leads into paying customers?”
- A multidisciplinary team: You need a cross-functional team of ideally 6–8 (max 10) participants that are motivated and bring all necessary skills to tackle the challenge. If you take the challenge from above, a good team should certainly include the Product Owner and people from Marketing and Sales, but also a designer and people from and the development and customer support team.
- A strong facilitator: Because the Design Sprint process is super packed with fast-moving exercises, the success of a Design Sprint greatly depends on a skilled facilitator. They will do the preparations, lead the team through all tasks and guide discussions and team decisions. The facilitator should therefore be someone who not only has experience with the Design Sprint, but also great communication and team management skills.
Once you ticked these ingredients of your checklist, running a Design Sprint is pretty straightforward, as each day consists of a series of clearly defined and time-boxed exercises and has a particular goal.
Here is what happens during the different days and phases:
- Monday (Understand): The first day of the Design Sprint is all about understanding the challenge and exploring the problem. This involves mapping out the customer journey and conducting expert interviews.
- Tuesday (Ideate): Once the team understands the problem, it’s time to generate solutions. Through a series of creative exercises each participant will first create a bunch of potential ideas and finally come up with their own concept sketched on paper.
- Wednesday (Decide): The team votes and decides which concept will get prototyped. This can be one solution, but more often than not it’s a combination of the best parts of multiple ideas.
- Thursday (Prototype): The team will create a high-fidelity prototype from the final concept and prepare the user tests for the next day.
- Friday (Test): On the last day of the Design Sprint, the team will present the prototype to five users to gather their feedback and ideas. At the end the team knows exactly how to move forward.
Depending on the feedback of the users, there are different outcomes and ways to proceed after the Sprint. If the feedback was great, the team can often use the prototype to get down to the details, defining requirements and preparing the implementation. If you get mixed feedback, you can run a second Design Sprint to iterate on your designs and conduct some more user tests. Sometimes the Design Sprint can reveal that you are on the absolutely wrong track. In that case be happy that you didn’t invest more than one week, and move on.
Note that within the Design Sprint community there is a new and semi-official version of the Design Sprint that only lasts four days and is commonly referred to as the “Design Sprint 2.0".
Bridging Design Sprints and Scrum Sprints
Design Sprints can fit fairly easy into a Scrum project. But there are a few pitfalls. In order to make it work, you need to understand what kind of outcomes a Design Sprint actually provides and where they fit into Scrum.
Don’t flow down the Waterfall
A common misconception when using Design Sprints within an agile framework like Scrum, is that people expect the Design Sprint to deliver a bunch of pixel perfect designs that they can can raw-feed to the development team for implementation. But this is not the intention of a Design Sprint and is dangerously close to a waterfall mindset — completing the design phase before the implementation begins.
The designs that come out of a Design Sprint are prototypical and will therefore most of the time not be ready for development at all. They will often be incomplete and contain a lot of “fake door“ elements to omit details of application behavior. This is because a good prototype is build to test a set of clearly defined hypotheses and will leave out anything that is irrelevant to this test.
But if you shouldn’t use Design Sprints to design screens, what are they actually good for?
The real deal with Design Sprints
What a Design Sprint really does provide are not detailed mockups but the big picture and a clear indication in the form of user feedback. It will give your team essential insights about an idea and will tell you if you are on the right track. More importantly, it will help you plan and prioritize releases, backlogs and user stories on top of actual user feedback and not based on your own hypotheses.
This is one of the biggest challenges within Scrum, because Scrum gives very little guidance (pretty much none) on how to manage your product backlog. So it’s completely up to the team, especially the Product Owner (PO), to make sure that the backlog always represents the customer perspective. This makes it easy to believe that you already know what your customers want. This is why even the greatest, well-intentioned Scrum teams can waste their time building the wrong features or building right features the wrong way, because they don’t have a clear understanding of the user.
So the real deal of Design Sprints when used within Scrum, is that they help you create backlogs that are not just a flat representation of everything a team has to get done. Instead, they help you to view your user stories and backlog within the context of the user and answer questions like: Why are we building this? Who are we building it for? What value will the solution provide for the customer and when?
How to make it all work
When understanding the above, using Design Sprints within Scrum becomes pretty straightforward. Basically the process works like this:
- Run a Design Sprint. Set your challenge, gather the team and run a Design Sprint. When should you run the Sprint? There are many cases where a Design Sprint can be helpful in a Scrum project and also many where they are just overkill. I will explore this in greater detail in the next section.
- Derive User Stories. After completing the Design Sprint, use the prototype and feedback to systematically derive user stories from it. There is no real best practice for this, but we find User Story Mapping by Jeff Patton the perfect way to bridge the outcome of a Design Sprint. You can learn more about this in this blog post.
- Run your Scrum Sprint. Take the derived user stories and and plan your Sprint Backlog as usual. During the Scrum Sprint, the team can then use the prototype created during the Design Sprint to iterate and create detailed interfaces for the various user stories. This requires the development and design team to work closely together.
Make Designers part of the Scrum Team
Another very important prerequisite is, that designers have to become real members of the Scrum team. This means they will fit their work into the Scrum Sprints and participate in all Scrum meetings, such as planning sessions, daily standups, sprint reviews, retrospectives and backlog refinement. They will also work directly with the development team to implement user stories and do design work during the sprint week.
Best uses of Design Sprints in Scrum projects
Now that you know how Design Sprints fit into Scrum, let’s take a closer look at when it’s best to run a Design Sprint in a Scrum project. Theoretically you could benefit from running a Design Sprint every time you plan to implement something new. However, a Design Sprint is quite an investment, occupying more than a handful of people for a whole week. Therefore it will make no sense to run a Design Sprint for each and every new piece you are planning to build. A Design Sprint is best, when you are faced with something complex and risky, that bring up many open questions about the general desirability of a feature. If your problem is more about optimization and the perfect usability, running a Design Sprint will often be complete overkill.
To give you a better picture, here are four major situations where Design Sprints become super handy for Scrum Teams:
- when starting new projects
- when adding or changing big features
- when the product vision, roadmap or backlog are out of focus
- when you face big challenges or unspecific requirements
Let’s explore each of these cases in a bit more detail.
Kickoff new projects
When you set sail for a new project, chances are that you and your team have big uncertainties about the user and his context and therefore don’t know what an optimal solution should look like. In this case, the Design Sprint can act as a product discovery exercise. So instead of “best guessing” all the requirements, block one or two weeks and run a Design Sprint upfront or at the very beginning of the project, for example in the form of a “Sprint Zero” — a technique commonly used to reduce uncertainties or test technological feasibility before the first sprint in a Scrum project.
The outcome of the Design Sprint will provide you with a shared understanding of the overall product vision and experience. This creates a strong alignment within your team and all relevant stakeholders. The prototype and user feedback will make your initial backlog refinement and sprint planning very straightforward, as you will be able to determine your user stories without much discussion. You will also be able to easily prioritize stories and create a first product roadmap and release plan.
This is not to say that after this initial Design Sprint you get all requirements done for the product. Again, this is waterfall thinking. For most projects, a Design Sprint as Sprint Zero will simply not be enough to create concepts, perform research and get feedback from the customer. After some Scrum Sprints you will face new challenges and you will be forced to iterate.
Implement new features or redesign existing ones
Similar to the kickoff for a new project, you can run a Design Sprint in an established project to define bigger chunks of new functionality or to reconsider existing features. In this case the Design Sprint will focus on a particular aspect of your product and help you generate solutions to it. For example your team could run a Design Sprint to figure out how a new on-boarding experience for your application should look like.
To do this, run your Design Sprint between your next two Scrum Sprints in the form of an “exploration sprint”. You should definitely not try to run a complete Design Sprint and your normal Scrum Sprint side-by-side. This would block your whole team or at least some people of your team for an entire week, making a normal implementation cadence impossible.
If you don’t like the concept of exploration sprints however, you can also try to integrate Design Sprints directly into your normal Scrum Sprint cycles. To make this work, you will have to break down and drastically shorten or merge the different Design Sprint exercises, so that they can be performed during your sprint weeks without costing too much time. This requires a team that already has some experience with Design Sprints.
Strategic product management and backlog refinement
“The backlog is where features die”. It is not uncommon that mature Scrum projects suffer from ever growing, disorganized backlogs. This feature creep often happens out of the desire to provide the user with an ever more useful product, or due to compromises made to balance the interests of different stakeholders.
A great product manager sets the expectation that she can’t possibly predict the future.
As Design Sprints help you to get a big picture, they can be an effective instrument for the Product Owner (PO) to align the conflicting demands of stakeholders and prevent feature creep. Rather than trying to set the expectation that the PO can predict the future and provide all the right answers, he can use Design Sprints as a method by which contrasting requirements are aligned and good answers are found.
Whenever the backlog is starting to get messy or when the product roadmap and vision become blurry, take some timeout, gather all relevant stakeholders and run a Design Sprint to zoom out, align perspectives and to collectively figure out what’s best for the customer.
Discover solutions to high level requirements
Sometimes you might face abstract, high-level requirements where it is not obvious right away how to approach them or where to start. For example you might have to improve key metrics such as conversion rates or user engagement. Or maybe you aim to make the checkout process of your webshop faster and easier. In this case Design Sprints can help you to explore the problem from the user perspective and come up with a bunch of possible solutions in a short amount time. After running one or two Design Sprints you end up with a proven approach how to move the needle.
Conclusion
Design Sprints are a great way for Scrum teams to get more customer centric and design-driven. They will help you to quickly explore new ideas and get user feedback without coding. They allow you to derive user stories and requirements from real user feedback instead of best guessing them. This will provide one perspective for the whole team and align stakeholders. Over time, Design Sprints can change your mindset from planning and guessing to rapid experimentation and learning and break down silos between design and development.
However, Design Sprints are no silver bullet. They are no single design process but merely another tool in your arsenal. They won’t help you to solve small optimization issues or come up with perfect screen designs. Often times running a Design Sprint will be overkill and you should take a look at smaller Design Thinking or UX practices such as empathy mapping or problem interviews.
While Design Sprints and Scrum can be applied alone, the two frameworks are better together, creating a mutually reinforcing environment focused on user-centricity and rapid iteration as a means of reaching optimal outcomes. Design Sprints bring a strong user focus, while Scrum is an excellent way to incrementally deliver solutions, ensuring user needs are kept front and center throughout the entire design and development process.
So, if you are a member of a Scrum team and want to benefit from Design Sprints, how should you get started?
Start small. Try to find some high-value, low-risk opportunities and give Design Sprints a try. Maybe you start a new project soon? Maybe your team has some big feature coming up? Or maybe you need to groom your backlog to get back the big picture? Whatever the challenge might be, gather a team of volunteers and just get started. The Design Sprint is one of these things that you have to experience to really understand the power and beauty of it.
It can be difficult though to convince people on your team to invest one week on a process that they don’t know and trust yet. Buy and share the book with your team, or just read it yourself and do a short presentation. There are also a ton of success stories and companies that share their experience with Design Sprints. Ultimately, you can also hire some experts and just do a 1–2 day Design Sprint training that will show you how Design Sprints work and get you all setup to run them yourself.
Whatever way you choose, I promise you that after running your first Design Sprint you will start to see the benefits and ultimately fall in love with the process.
Benjamin Bestmann is Founding Partner of Strive Innovation Studio. He helps teams and companies around the world to build user-centered products and adopt new and more effective ways of working in the digital age. Follow him on LinkedIn or Twitter.
Want to learn more about Design Sprints, Innovation and Work in the Digital Age? Follow Strive on Instagram for daily stories or signup for our newsletter below … and feel free to ask us anything!
