How Design Sprints + Agile Sprints Work Better Together
A common source of confusion around Design Sprints relates to the popularity of Agile development practices, specifically Scrum. When most people hear the word “sprint,” they think of the cell phone company, Scrum rituals, or “that stuff our dev team does.” Because of this, there have been several articles discussing the merits of Design Sprints versus Agile Sprints. One even suggested that Design Sprints may be a way to avoid the purgatory of Agile Sprints.
I’m here to argue that they can be harmonious, not antagonistic. Design Sprints and Agile Sprints work well together and even complement each other. Below are my thoughts on how using Design Sprints in front of an Agile development process can actually lead to better results.
Quick Intro to Agile & Scrum
First, I’d like to cover a few basics of Agile software development for those who are new to it. Agile first came onto the scene with the Agile manifesto, written in 2001. The manifesto consists of 4 values and 12 principles. I’ve listed the values here because I believe in them whole-heartedly.
- Individuals and Interactions over processes and tools
- Working Software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to Change over following a plan
“Agile Sprints” are part of a specific Agile development process called Scrum.
Scrum is an agile framework for managing work with an emphasis on software development. It is designed for teams of three to nine developers who break their work into actions that can be completed within time-boxed iterations, called Sprints (30 days or less) and track progress and re-plan in 15-minute stand-up meetings, called Daily Scrums. — Wikipedia
Agile Versus Sprints
Agile and Scrum are ways in which you build software. They define tools, practices, and rituals for conducting daily engineering tasks. A Design Sprint is a tool you use to dive deep into a problem, to understand if you should build something, and determine what exactly you should build. As you can see, Agile Sprints and Design Sprints share a few core principles in common. They both encourage cross-functional teams, seek to move quickly, and continually react to new information.
When Agile first emerged, organizations began to sit cross-functional team members close to each other so that they could become aware of issues more quickly. Unfortunately, designers were not always part of these teams. Often, the UX researchers and visual designers were part of another team or in an outside agency and their working style closely resembled waterfall development.
While Scrum defines a great methodology for how we should build our software, Design Sprints are a perfect method for determining what we should build.
Working in Sync
While Scrum defines a great methodology for how we should build our software, Design Sprints are a perfect method for determining what we should build. In Scrum, there is a Sprint backlog, which is fed by a product backlog. Design Sprints can help teams focus their product backlog and align the entire team on the features and projects with the highest business potential. They are also an effective tool for validating user requirements that are teed up in the Sprint backlog. In Design Sprints, you often iterate and test much like you would in Scrum; however, Sprints do this iteration through quick designs and light-weight prototypes, which are much less expensive and carry lower risk.
You Need Both
I’m sure you are familiar with the expression “garbage in, garbage out.” Scrum is a great process for developing code quickly, keeping projects moving, and adapting to new requirements. However, if you are building the wrong thing, it simply means you’ll have the wrong thing faster than with waterfall.
If you are building the wrong thing, it simply means you’ll have the wrong thing faster than with waterfall.
Some will argue that Scrum’s iterative nature will allow you to discover these issues and adjust course and that Design Sprints aren’t necessary. There are a couple of issues with this line of thinking:
- If your focus is on pushing code and building features, it will take you a long time to discover the cracks in your foundation.
- Once you have built the system, the sunk cost fallacy may make you inclined to continue investing in the project long after you realize it’s not a winner.
- Technical debt is a measure of uncertainty, so the more you build from a point of ignorance, the more technical debt you accumulate.
- Design Sprints leave you with a prototype that becomes a “visual spec,” which can help to decorate and improve on the Agile acceptance criteria.
Prototypes Set You Up for Success
I think starting your Agile process with a focused Design Sprint sets you up for much greater success down the road. That’s because Sprints are predicated on quick user feedback from rapid prototyping. Prototypes are by nature disposable and can be easily updated without fear of technical debt or other hidden costs down the road. They allow you to test ideas and features quickly and increase your level of confidence prior to sending the project through an Agile Sprint. When you are done with a Design Sprint, you are ready to build.
When you are done with a Design Sprint, you are ready to build.
You’ll leave your Design Sprint with a functioning prototype that has been battle tested with users. This prototype becomes the “visual spec,” which helps improve on the Agile acceptance criteria. There will be less time needed to write the acceptance criteria because your visual prototype is highly specific, leading to much less ambiguity.
I encourage all Scrum teams to think about their Scrum cadence and on what frequency it makes sense for them to conduct a Design Sprint first. In fact, I’m noticing more and more companies using Design Sprints as a way to validate product requirements and align stakeholders prior to sending their project through an Agile development process.
I would love to hear your thoughts on how you use Design Sprints and the Agile process to inform each other. What’s your cadence?
