Design Sprints vs Agile Sprints - What’s the difference?
Sprint seems to be one of the biggest buzzwords in development these days. “Sprint this, sprint that, we’ll do that in the next sprint,” Then a book comes out called Sprint by Jake Knapp, John Zertsky, and Braden Kowitz and you think great, now I can learn what these mysterious sprints are and be down with the cool kids in development. The problem is that the book Sprint is written about a whole different type of sprints, design sprints. So you end up more confused! I’m going to try to break down the difference and explain why and when you should use them.
Up first is Agile Sprints. Agile is a magical methodology used by everyone from small startups to giant multinationals. The basic idea around agile is that the team works in tandem to quickly produce small pieces of a much larger project and release parts along the way to gain user insights. It’s way more complicated than that but I’m trying to explain this in the most basic way so don’t give out to me. Agile sprints last a couple of weeks, depending on the organisation running it, and the team will plan what can they deliver for each sprint as well as reviewing the sprint at the end. There are boards and planning and daily standups but at its heart, it is taking a large project and breaking it into much smaller tasks and deliverables so you are delivering every couple of weeks rather than after months of the old reliable waterfall methodology.
On the other hand we have design sprints which are much shorter and play a very different role. Design sprints were developed by the team at Google Ventures to solve problems really quickly. Say you have an idea like opening up an online version of your brick and mortar shop but you’re afraid of spending months working on it only to find you missed out on what your customers actually want, that would be the perfect opportunity for a design sprint. A design sprint lasts one week, or four days depending on availabilities or the version of design sprint you want to run. You get your entire team in one room for five consecutive days and you work through a prescribed set of tasks and challenges to define the problem, ideate, prototype a solution and then test it with real clients all in one week. It’s like design thinking had a red bull, an espresso, and Usain Bolt’s legs.
So there you have it, the difference between design and agile sprints. Thankfully neither of them require actual running otherwise I would be in the wrong industry. As for when you would use each of them? Simply put, if the project is large and you know what you’re doing? You’ll be doing multiple agile sprints. If you’re trying to solve a specific problem or gain some insight into a certain idea? Gather your team and some post its in a room and do a design sprint. Obviously this is a very basic overview of what these two lovely buzzwords/methodologies mean. If you want to learn more, there are plenty of more informed articles out there detailing both or if you’re interested in design sprints I would recommend reading Sprint by Jake Knapp, John Zertsky, and Braden Kowitz or listening to Jake’s podcast, The Product Breakfast Club.
I said the word “sprint” 25 times in this blog post, am I hip now?