The Zebra
Published in

The Zebra

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:

  1. Is there a defined problem?
  2. Will solving the problem have a significant impact on the business?
  3. Is the problem complicated?
  4. Has there been any research to validate the problem?
  5. 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.

--

--

--

The Zebra is America's most trusted and most popular online resource for finding, buying and managing your insurance.

Recommended from Medium

Wireframing Easyjet: Challenge 2

Content Accessibility

The Final

Things to consider when migrating from Sketch/Adobe XD to Figma

Reflection Point: VRBO Patterns and User Flows

Know your customer and their Jobs-to-be-Done!

Goodnight Aura

How to write the perfect Design brief #DesignSprint

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
Matthew Stephens

Matthew Stephens

Fractional Design Leader. Co-Founder @ DeviantArt. Former VP of Design @ The Zebra.

More from Medium

Experience Mapping between the design tool and transformation driver.

A thirst for creativity: From academic research to UX design

Picture of two dogs, one black and one white, lying on a bed and looking a the camera.

Redesigning the Auth0 Quickstart Experience

All About Design Thinking