Back to all Articles

Should My Scrum Team Have a Design Sprint?

Stacey Ackerman

Experiment in a Time Box

A member from Chicago, Illinois, worked with a company that used to have design sprints, but they’ve since moved away from them. As their agile coach, he cautioned them against design sprints, but the architects and UX leads insisted they would not give up their traditional approach. He agreed to let them have a design sprint for one full program increment to see if it was helpful or not.

At the end of the program increment, they missed many of their deliverables. During the Inspect & Adapt, the coach asked why, and some teams responded by saying, “Two weeks wasn’t enough time to design. They also said that designs were wrong and didn’t work, so they had to go back and design again.”

The teams learned a valuable lesson—you cannot know everything upfront and simply acting on the solution can change the nature of the problem itself.

Once they realized this themselves, they agreed to no longer have a design sprint and to only design enough to prove whether their initial design will work or not, which is exactly what agile is about.

Design Has a Runway like Architecture

A member from Jamestown, Road Island, chimed in to say that she sees design sprints as a parallel to architecture. There’s a runway where you look ahead, but you still allow some design to come from the team.

She says that her organization has a UX/UI team that spends part of its time in the current sprint and the other part looking at future business pain points to tackle.

The design team conducts research by interviewing the business and watching the business work, they map out the business process and look for ‘muda’ (waste) that they can eliminate. Next, they facilitate a workshop with the business and the team to identify what is highly desirable for the business and highly doable by the team. “We’ve tried both Kanban and Scrum to organize this work, but Kanban works better,” she says.

A Valuable Agency Experiment in Incremental Design

A member from Melbourne, Australia, shared his story about an experiment that changed everything for an agency.

The team split the client’s work into increments of work (user stories), then did their best to design, get client sign-off and develop all within the same iteration.

The team was a little concerned that the client had to be so available to sign-off on stories, but they found the client liked the involvement. The client was getting back with sign-off almost within the hour of receiving each user story, creating a steady flow throughout the iteration.

The team theorized that in the big-bang approach the clients were overwhelmed with the amount of design to review and sign-off, and it was stalling completion. With the smaller increments, the sign-off was clear and focused and they were able to review them quickly and get back with valuable feedback.

From this one successful experiment, the team then started looking at all their other stage-gates and how they could eliminate them from the process.

The member said, “It helped to prove the value of agile in a real and measurable way. I didn’t try to change the model from the start, or change their mind. I simply recorded metrics. I looked at the team’s ability to deliver and retro’d this with the team and explored with them how we could improve.”

Do you have the advantage of being an Agile Mentor?

Network with more than 2,330 members and get exclusive insights on the agile strategies that are working today. Get direct help from Mike in monthly video Q&A sessions. Be mentored by agile experts and share your experience to mentor others, only when you join the Agile Mentors Community.

Do you have the advantage of being an Agile Mentor?

Network with more than 2,330 members and get exclusive insights on the agile strategies that are working today. Get direct help from Mike in monthly video Q&A sessions. Be mentored by agile experts and share your experience to mentor others, only when you join the Agile Mentors Community.