The Cost of Running Design Sprints
At The Zebra, we’re constantly running design sprints to solve our biggest problems. We’ve run roughly 15 in the past year and learn something new each time. (Here’s a look inside our process.) But one of the challenges we have now is running too many design sprints, often unnecessarily. To address the issue, I first sought to determine the cost of each sprint and then collaborate with the stakeholders on how to improve the efficiency of our process.
The Variables
For these numbers, I used the standard 5-day design sprint process as prescribed by Jake Knapp. We’ve shortened our design sprints at The Zebra to 5 meetings of 60–90 minutes each, but the formula works in either case.
Number of Attendees
For this variable, I looked at previous design sprints and calculated the average number of people in each meeting. For us, it was 10.8 employees but I imagine that’s higher than most. Jake Knapp recommends a team of 7, so that’s what we’ll use for this example.
Average Hourly Rate per Employee
To calculate how much each person’s time was worth, I asked HR for a rough estimate of the average salary of each employee. For this example, let’s assume it’s $50,000. Next, you divide that by the number of working hours in a year, which is 2,080. That comes out to roughly $24 per hour per employee.
Number of Hours per Design Sprint
If you run a standard design sprint, you are looking at 5 full days, or roughly 40 hours, of work. At The Zebra, our meetings only take up 6 hours total, but we produce most of the designs, prototypes, and testing (about 20 hours) between the meetings.
The Cost
With the variables defined, we can now determine the cost pretty easily. The formula is simply:
(Number of Attendees) x (Average Hourly Rate per Employee) x (Number of Hours per Design Sprint)
So for a standard design sprint, the formula looks like this:
7 employees x $24/hr x 40 hours = $6,720 for the total cost
$6,720 isn’t a small amount of money for most companies, including ours. Learning this information and assigning a dollar amount to our sprints drastically changed our perspective. We began to look at ways to cut costs and work more efficiently.
The Solutions
Don’t Be Afraid to Say No
The first step we took to curb unnecessary design sprints was to create a series of questions to determine if a sprint was the right solution or not, and if so, who should be involved:
- Is there a defined problem?
- Will solving the problem have a significant impact on the business?
- Is the problem complicated?
- Has there been any research to validate the problem?
- Are the possible solutions unknown?
If the answer is yes to all of these, then we proceed with the design sprint. Otherwise, we push back and figure out other ways to solve the problem.
Tighten Up the Roster
One of my favorite features of a design sprint is the opportunity for collaboration. As sprints have become more popular, we’ve seen more and more people wanting to be involved. It’s tough to say no, but providing a dollar amount is a good rationale for leaving someone out. A good compromise is to rotate team members for each design sprint to make sure their voice is heard.
Also, there are often moments during our sprints when a team member isn’t needed. I think it’s important to make it clear that attendance isn’t mandatory and as long as they are available for questions, they should feel free to skip certain parts if they need.
Modify or Shorten the Process
Another strategy we have employed is to skip parts of the process that seem unnecessary. For example, there have been multiple times where we feel confident that we know the problem and the success and failure criteria, so we skip the first meeting and fill out our Realtimeboard before we get together the first time. Sometimes it goes the other way, where a solution isn’t needed, but we need to have a conversation about a problem. The first meeting often serves as a useful framework for this discussion.
Conclusion
Design sprints are a critical part of our process, but they’re costly, both in money and in time. In order to maximize the value of our process, we must be vigilant in scrutinizing each problem before we commit to allocating our team’s valuable resources.
