Should you run a sprint?

Design Sprints are a great investment of time and resources. They promise a quick return of actionable prototypes, with a controlled input of effort and time. But sprints are not equally suited for all situations. They require specific pre-conditions to be effective. They are also more suited for some business needs than others. Here’s what to look for before you decide to embark on a design sprint.

What you need

A problem to solve

It seems obvious, but in order to run a sprint, you need a problem to solve.

The problem definition may have come from an audit of an existing product, or from a desire to improve a pain point. We’ll often work with the team to further define and clarify the problem from this starting point. For an internal project, the problem may be an area of opportunity that has become visible through analytics, or by customer feedback. It may also have become clear after conducting a usability study.

Access to stakeholders and knowledge

Because you’ll be moving fast, you need to have access to the stakeholders in the product being considered. You also need frequent and direct access to the stakeholders’ and domain experts’ deep industry and business knowledge. Your ability to move forward quickly and efficiently depends on getting answers immediately along the way. With the right process, the product is based on industry knowledge, historical usage data, conditions of the target market, and the overall direction of the business. Effort isn’t wasted on assumptions that are easy to correct.

It is technically possible to run a sprint without access to stakeholders, but a lot of the work will be based on assumption and speculation. Even with best practices and UX design experience, it is always possible to make incorrect assumptions about an industry if an expert’s input is not available.

Who are all the stakeholders? In our practice, this term refers primarily to the final decision makers on your team and the client’s team.

Team buy-in + participation

To allow designers to draw on the domain experts’ knowledge and access them directly, it’s best to have them in the room for all of the sprint. Everyone will need to clear their schedules of other commitments to participate fully.

This is only possible when all parties have agreed to and understand the value a design sprint can bring. Even then, a sprint (as the name implies) is an intense process. Having everyone in the same room requires a tightly managed schedule. There is significant progress at the end of each day, but the process can be draining. It’s an “always on” situation for the participants.

The best way to mitigate potential burnout from working in sprints is to avoid scheduling them back-to-back. This is especially true if you are using the sprint method for different projects, rather than building on the previous week’s progress. It also helps to prevent burnout if your company follows the 20% time schedule, with project (in this case, sprint) work concentrated in four days out of the week, and skill development, community work, and other internal projects on Fridays.

Project goals

Project goals need to be clear before a sprint can start. There is simply no room within the short duration to allow for a change in direction.

What if a project has unclear goals, or they seem too vast to tackle? In this case, a sprint could help explore the possibilities in order to find the most critical user needs, and narrow down to the most effective routes to explore for addressing those needs. For this type of sprint, “establishing goals and proposing a future course of action” can become a focused goal in itself.

Example
A more typical sprint situation might address a question like:
“How would users in a marketplace manage communication and transfer of goods on their mobile devices.”
“How can an admin create, update and manage multiple inventory lists?”

So - before committing to a sprint, ensure that goals are clear, and that you and everyone involved agree to follow the design sprint work schedule.

Part of establishing the project goals is to define what deliverables will best accomplish them. The sprint work plan may include very extensive user flows and wireframes, or it may include more focus on visual design. See some of the examples to help decide how to best create those assets.

What sprints can do

To show what a sprint can do, here are some example sprint outcomes. Not all were accomplished in a single 4-day week. In some cases, there were three or four week-long sprints in succession (with a separate area of focus each week.)

Discover the right priorities and features for a product
When features and goals for the product have already taken shape, it can be valuable to prioritize them, and form a strategy for which components should be built first. An initial sprint can examine which features might be most effective. In the next few weeks, the team would tackle one feature per week. Each feature goes from a general overview of what a user might be seeking to accomplish, through to an interactive prototype.
Quickly validate and gain feedback for a product idea
In a single sprint, it is possible to quickly build, test and validate assumptions about a product idea. But, if the product is complex, or the features need to be tested at a high level of fidelity, several weeks might be necessary.
Establish and confirm the broad strokes of a feature before worrying about non-critical details
A design sprint can help define, prototype, and test the essential components of a much larger product in just one week.

Let’s say the value proposition and the mechanics behind the product are already worked out. The sprint process can be very effective in helping both define and refine a product offering. It puts a large project into perspective, helps prioritize key features, and can have a huge impact on its future.

What sprints can’t do

Sprints can’t always yield a fully resolved complex product
Before committing to a sprint, it is important to establish shared expectations of what exactly the process will yield.
For example, it might be easy to assume that a visually designed working prototype is almost a finished product. It is not. It’s unlikely that a small team could completely create a complex working product in a week. You will need to make assumptions for the sake of speed, and areas outside of the focus of the sprint will be left unexplored.
If it is the team’s first experience participating in a sprint, it is especially important to communicate what exactly the outcome will entail.
Sprints don’t cover all possible cases
As mentioned above, the tight focus that makes a sprint possible is necessarily going to leave out possibilities and potential features. If an all-inclusive, “big picture” approach is desired, a broader Design “Discovery” process might be a better fit. (Here’s an article that compares the two.)
Sprints aren’t hands-off
Sprints call for a more time sensitive, iterative, and participatory approach than a typical working schedule might allow. Participation of the full team is imperative to the understanding of the content, goals, and target audience. All parties will get the best value from a sprint if they can commit to being available for the close collaboration that this process requires.