What Is The Difference Between A Design Sprint And A Development Sprint?
Wondering why we’re always running? At Inktrap we’ve looked at what this popular term actually means within the industry.
If you’ve spent half an hour on Medium in the Design or Tech section you will without a doubt have read the word Sprint within the first five minutes. This term has been a buzzword for the last few years, and its popularity is set to grow, meaning it is destined to be part of our design language forever. But what does it actually mean?
My first encounter with the term Sprint came when I was about to embark on a project with a big UK bank. The brief for this project was to create a digital service that transformed a traditional face-to-face and offline interaction. Before we started the project my then boss came to me and said we were going to run the project like a Google Sprint. As I was originally a Brand Designer who transitioned into being a Web Designer this was completely new territory for me. I was bought the infamous Google Sprint book by Jake Knapp then sent on my way to learn as much as I could before the Monday meeting.
Fast forward nearly 3 years I’m now confronting the word Sprint weekly but in an entirely new context. In my current role, I work directly with Developers as well as with external Project Managers, we talk about Sprints, but not always in the Design sense, we also refer to Development Sprints.
As you can imagine, using this term for both design and development can become incredibly confusing. Not only for designers who think they may be running a workshop but also for developers who might think they will be focusing on code when actually they will working without their laptops for a week in a room filled with post-it notes.
So What Is A Sprint?
According to Atlassian, the creator of Jira (A product for managing project tasks) They see a sprint as a time-boxed period when a team works to complete a set amount of work. It’s as simple as that, but what goes into a Sprint is where a misunderstanding occurs due to the vagueness of what a Sprint is. For Inktrap, we see that there are two clear types of Sprints — Design and Development.
What Is A Design Sprint?
A Design Sprint, if doing it by the literal book is a five-day process for solving problems and testing new ideas. The idea from Jake Knapp came around when he found that the Design process was flawed due to those in marketing only seeing the Product at the end of the Design Process.
The Google Sprint process focuses heavily on getting a variety of people in the business in the room for a week and striving to great ideas together. On paper that sounds like a great idea but it can be difficult to convince stakeholders of the value they can add by clearing their schedule for a week.
Within this week period, you will spend time understanding the problem, gaining research, hearing from experts, as well as generating ideas, deciding which is the best solution and testing with anyone you can — ideally your target user.
The Design Sprint method allows a team to focus on a specific problem, testing and iterating within five days. By having a clear and prescriptive method such as Google Sprint, means that there is less time planning workshops by the Design team, as well as a reduction in meetings that revolve around discussion rather than action. More time ends up being spent on solving the problem and rapid progress to a potential solution is much more likely due to the tight timeline restraints.
What Is A Development Sprint?
A Development Sprint is much simpler and closer to Atlassian’s description. In the general context, a Development Sprint is a focused period of time, usually, two weeks, that centres on tasks that have to be completed, built and ready for review.
With a Development Sprint, the client or experts aren’t required to be in the office each day and there isn’t a focus on research to define or understand problems. This type of Sprint falls into a Project Management technique compared to a Design Sprint which is a Design Thinking approach.
At the start of a Development Sprint, the Product Owner would outline the next set of features or bugs that need to be dealt with within the next Sprint. This discussion takes place with the Development Team so they can confirm out of the list of features or bugs what is feasible in that period of time. After this has been defined the Product Owner usually steps back and allows the Development Team to get going with a daily call or face-to-face meeting if in the same office to discuss anything that may affect the progress that week such as blockers. The end of the Sprint is where the Development Team presents the work that did in that time period to the Product Owner.
Conclusion
When looking at both Sprints and what they mean to a Designer or a Developer, there is a really clear distinction. When focusing on a Design Sprint, the outcome is unknown at the beginning, yes we know there needs to be a prototype at the end of the five days but we don’t know what that would look like. Compared to a Development Sprint, what is going to be built in that time period is clearly defined from the start.
There is one thing that both Sprints share, and that is the focus on a set period of time on a piece of work with clear goals. Nothing more. Nothing less.
At Inktrap though we like the Google Sprint approach. We have found that not every client needs a week-long Design focused workshop. We have found that a lot of our clients come to us because they have a specific problem they want to solve. Due to this, we have created our own Sprint process which takes the most successful elements from both the Design and Development Sprints.
We still agree it’s important that we clearly state whether we are planning a Design Sprint or a Development Sprint and what that involves when talking with clients as they can both have very different outcomes — allowing room for assumptions will always end badly! Like any successful project communication is key, so if you’re unsure about what sprint you should do or have been asked to do then find out more from the client or project owner before committing.
If you enjoyed this article, you may also like…
📄 How come everybody loves to hate self-checkouts?
📄 So you’ve lost your design mojo? Well here’s how to get it back!
📄 Why does design for children’s websites have to be so chaotic?
Before you go…
👏 Clap if you enjoyed this article, it helps others find it!
💬 If you have something to say, drop us a line on Twitter: @InktrapDesign.
📝 Sign up to our design newsletter Minimum Viable Publication, published every Tuesday at 1pm.
