Leaning Scrum for the first time can be a bit overwhelming. There are many new terms and concepts in Scrum. The sprint is one of those terms, and you may be wondering:

What is a sprint, and how is it used in Scrum?

The recent increased popularity of design sprints has added confusion about how they are similar or different. I’ll walk through both what a sprint is and why it matters to your team.

What is a sprint?

Let’s begin by looking at the definition of a sprint.

What makes up a sprint?

A sprint is the basic unit of time in Scrum, and Scrum has a distinct rhythm and cadence that is structured around the sprint. 

I like to think of Scrum as a relay race, with each sprint being a lap. The Scrum team hands off the “baton” of finished work to itself in the next sprint (that’s where the analogy starts to break down a bit).

The sprint serves as a boundary to focus the team. At the beginning of the sprint, they set a goal and select what work they will complete by the end of the sprint. This selected work receives all their attention, and no new work comes to the team during this protected time.

A sprint defines the scope of a team's attention for a period of time.

All the events in Scrum are contained within the sprint. Take a look at this graphic to see how all the events fall within the sprint.

The sprint in Scrum has a consistent length with a defined beginning and end. Once one sprint ends, the next begins without a gap in between. 

The length of a sprint is usually one or two weeks, though I’ve been on teams with a three-week sprint. Beyond three weeks, the sprint loses its effectiveness because people no longer feel the cadence.

How is it different than a design sprint?

Design sprints have become increasingly popular over the years. And rightly so, they’re very effective at focusing a team on solving a problem and quickly iterating to a testable version of their idea.

A design sprint and a scrum sprint share names and some common features, but they are also distinct. 

Similarities

• Usually one week in length.
• Provides focus for the team.
• Have prescribed events during the sprint.

Differences

• Scrum sprints fit in a larger framework.
• Scrum teams are consistent over time, whereas design sprint teams may exist only for the sprint.
• The events that make up the sprint are different for each.

As you can see, they have a lot in common. You can even combine the concepts by using a design sprint approach during a scrum sprint. Next, let’s look at what you would want to use sprints.

Why is a sprint important?

The cadence of a sprint can take a little getting used to for a team, but the benefits are well worth it, and I’ve never been on a team that wanted to go back after trying it for a few iterations.

How a sprint keeps your team focused.

Our world continues to get faster, more complex and more unpredictable. In this environment, we need clarity and focus to make progress. Sprints help teams focus by providing a boundary of time with a clear outcome.

When the sprint begins, the product owner casts a vision for the sprint by setting the sprint goal. Then the scrum team collaborates to select work from the top of the backlog that they will commit to completing by the end of the sprint. 

During the sprint, the team will work on what they selected and only what they selected. The sprint is a safe block of time where the team is protected from distraction and competing priorities. The sprint defines the scope of a team's attention for a period of time.

How to choose the length of your sprint

There isn’t a one-size-fits-all for the length of your sprint in Scrum. One week is the most typical sprint length and beyond three weeks is uncommon.

Several factors influence the best sprint length for your situation.

• Team: Do you have a brand new team? I’d suggest maybe a two-week sprint. One week would likely feel too fast as they are learning the system, and three weeks would take a long time to feel like much of a rhythm.
• Environment: How stable is your environment? Are priorities changing daily? If you’re in the middle of a global pandemic, you want to shorten your sprint to one week. Anything longer than that and information, requirements, and requests have changed mid-sprint.
• Nature of the work: Some work is easier to break down than others. Web design is more suited to short sprints than video production. Although I often find that once the development team gets into their rhythm, they see how to break down their tasks more effectively. Then they can more easily work in the shorter sprints. 

In the end, I suggest choosing one or two weeks. The great thing about Scrum is that you'll run a retrospective at the end of each sprint and evaluate what’s working and what’s not. If the current sprint length is too long or too short, you can evaluate and adapt as you go along. You don’t have to get it perfect the first time.

Next Steps

There are a lot of new terms when learning the Scrum essentials, and I hope this post helped clear up some of the vocabulary around sprints. If you want to learn more about Scrum in general, check out my What is Scrum? A Guide for Everyday People to Learn Scrum. If you have more questions, please feel free to reach out on LinkedIn.

Still not sure about your next step with Scrum? I offer a couple of free coaching sessions each month. You can signup for a free 1-hour coaching session, and we can work together to identify a good next step for you.