Agile Sprints vs. Design Sprints

How and when to connect these powerful frameworks to create new products or rethink existing ones.

Jay Melone
Aug 2, 2017 · 8 min read
Image for post
Image for post


A shift took place that moved many of us away from industrial-age-inspired waterfall processes where everything was documented upfront, and then moved through stage gates until products were finally ready for deployment. In place of waterfall came iterative development approaches including Scrum, Kanban, XP (extreme programming), and other variations.

These disciplines veered away from the silo’d, waterfall approach, replacing it with lean, measurable cycles of build, test, ship. These rapid cycles, typically spanning 1–2 weeks, were aptly named, ‘sprints.’

Product and project managers ditched their Gantt Charts in place of Sprint Plans in order to organize their product development plans — prioritized features were pulled off the top of the product backlog, into the sprint backlog, cycled through a sprint, and then released to production.

Image for post
Image for post
Courtesy of

And just as C-suite and Sales & Marketing leadership grew accustomed to sprints and learned to speak the latest language of their technology groups, in 2015 a new ‘sprint’ began to bubble up — the Design Sprint.

Design Sprints, modeled after IDEO’s design thinking framework, were originally incubated at Google by Jake Knapp, where they helped orchestrate the successful launch of products such as Gmail and Hangouts (now Meet).

Over the course of years and hundreds of sprints, Jake eventually honed the process to the point that multidisciplinary teams could spend 5 days understanding, ideating, prototyping, and testing big business problems, before launching into full-blown product development.

After countless success stories, GV snatched up Jake and design sprints so that they could begin offering them (both, Jake and sprints) to their portfolio companies. Having used sprints to help companies like Uber, Slack, and Blue Bottle Coffee (among many others), Jake and several other GV design partners, collaborated to publish the Sprint book on March 8, 2016. It quickly became a NY Times and WSJ Bestseller.

Product teams around the world have since consumed, tested, and adopted Design Sprints into their toolkit. Without question, design sprints have changed the way companies of all shapes and sizes approach new product and service development.

But there’s this one thing

And so today I’m hoping to shed some light on how design sprints relate to agile development sprints, both for newly created products as well as rebuilding or relaunching existing products.

But first, let’s me paint a picture of all of the pieces related to the digital product development process…

Software-enabled innovation

Image for post
Image for post
While the visual looks sequential, it’s important to note that product development is never linear.
  • Business Alignment: Deciding to work on problems that align with the strategy, vision, and resources of the company
  • User Research: Getting to know more about the market, users, and competition that surround those problems
  • Design Thinking (via Design Sprints): Building an understanding of the problem and validating prototyped solutions with potential customers
  • MVP Planning: Creating a complete picture of your solution and deciding on the minimum valuable product (MVP) you’ll bring to market inside of a Product Roadmap
  • UX Design: Building out the information architecture, interactions, and flow of the human-centered experiences you’ll offer within your solution
  • Visual Design: Giving your solution a style, tone, and interface (when applicable)
  • Logistics: Plotting out the system infrastructure and application architecture of your solution
  • Agile Development: Building the crux of your software solution and launching to market.

Note: Many teams bundle UX and/or visual design into agile development — for us, we’ve found this tend to work best for simpler applications and small feature enhancements. When creating enterprise digital products, we’ve found it more effective and efficient to keep them mildly separated, though teams are often working in parallel at a point.

Sprints for new products

This makes sense — before you start designing and coding you’ll want to build up some perspective of the problem and user, and then test solutions with disposable prototypes. Not only are prototypes cheaper and faster, but the team becomes less emotionally invested in a prototype than beautifully designed screens and working code.


A Product Roadmap will expand upon the specific focus within your design sprint prototype to flesh out the remaining, prioritized features / screens / user flows. These priorities becomes entries in your product backlog, which can then be fed into your agile dev sprints.

Code Sprints

  • What’s the best technology to leverage?
  • Are there existing solutions we can incorporate?
  • Where should we focus first?

So we developed a Code Sprint (yes, we added yet another ‘sprint’ term to the mix…sorry?).

Image for post
Image for post
New Haircut’s Code Sprint

In a Code Sprint, technology teams spend 4–5 days to:

  • Understand all of the previously assembled information
  • Vote upon the 2–3 biggest technology challenges they’ll need to overcome
  • Diverge to research and build competing prototypes to each challenge
  • Test the prototypes that help to ultimately decide upon the winning implementation(s)

We modeled Code Sprints to use the same intense focus, duration, and divergent-convergent techniques of a Design Sprint. Subsequently, our tech teams have been able to answer not only the questions, “What are we building?” and “How are we building it?”, but produce a foundational layer of infrastructure, architecture, and code to build upon within their agile development sprints.

Expected improvements

  • Recover months and years of wasted efforts working on problems people don’t care about
  • Enable engineering-driven organizations to effectively collaborate with others in the product development process
  • (alt to above) Empower roles outside of product and tech to have a necessary and welcomed seat at the solution design table
  • Provide engineering teams with the empathic perspective and voice of the user that they’re typically missing

Sprints for existing products

One mistake lots of teams make when first adopting design sprints is to overuse them. They start running design sprints for nearly every feature they want to roll out… Adding a form to a page? “Let’s run a sprint.” Building the iOS version of our Android app? “Sprint!” This is overkill.

A design sprint is best intended for a problem that maps back to a critical business opportunity or challenge. For example, if your company decides to begin offering your product to an entirely new customer segment, this is pivotal decision that should be funneled through a design sprint.


  1. It forces us into solution mode before we fully understand the problem
  2. It influences the solutions we come up with
  3. (if we need to build within an existing solution) It limits our solutions within the confines of that solution — this is particularly challenging when those solutions are outside our control; e.g. third party platforms / data / access

On the flip side, having an existing solution also provides us with benchmarks new products don’t have access to.

If you scroll back up to the New Haircut approach diagram above, you’ll see that problem validation is critical to a design sprint (solution validation). This typically comes in the form of ethnographic research, surveys, paper (aka super lightweight) prototypes. However, when previously existing solutions can be tapped, you get an additional source of data.

The trick with leveraging existing solution data is to pull out the insights, sans implementation bias. In other words, the data you’re looking for is more about the patterns (good or bad) based on the problem the existing solution is trying to solve.

How that solution has been currently implemented can certainly be noted, but it shouldn’t heavily influence an upcoming design sprint that’s intended to discover new possibilities. Remember, the advantage of a design sprint is that you’re provided the space to dream big with entirely new, interesting, and viable solutions.

Because of this legacy bias, it often means that you’ll want to think very carefully about using team members from previous incarnations in next-generation solutions. What tends to work well is to leverage previous team members as outside experts during Monday of sprint week.


  • New solutions can borrow from existing solutions to either replicate, or devise entirely new experiences

And what does it look like for an existing product to seed a design sprint, before moving into agile development?

Image for post
Image for post

Wrapping up on agile sprints and design sprints

Start leading design sprints

The toolkit includes all of our digital templates, presentation slides, pro tips, and dozens of sprint upgrades. Included are versions that support remote (virtual) or in-person sprints.

This toolkit is 100% comprehensive and ready-to-use, today.

Design Sprint Toolkit by New Haircut
Design Sprint Toolkit by New Haircut
Image for post
Image for post

Agile Insider

Exclusive & practical insights about rapidly delivering value.

Sign up for All Things Agile

By Agile Insider

The best of Agile Insider delivered to your inbox Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Jay Melone

Written by

Principal Facilitator @ New Haircut |

Agile Insider

Exclusive and practical insights that enable the agile community to succeed.

Jay Melone

Written by

Principal Facilitator @ New Haircut |

Agile Insider

Exclusive and practical insights that enable the agile community to succeed.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store