This question "What is the duration of a Sprint" is seemingly simple, but depending on the interviewing situation, company, interviewer, and familiarity with Scrum you might need to give them more or fewer details and answer additional questions your answer might bring up.
Sprint Duration - Where Size Matters
The answer is simple, a Sprint is a time-box of one month or less. A reasonable follow-up question would be, “what is the optimal Sprint duration?” Here you might want to put on your consultant hat and give the “it depends” answer. And it really does. It depends on various factors. Let’s explore the extremes, where Sprint duration is either too long or too short.
Not Scrum
Firstly, if your Sprint duration is longer than a month, you are not doing Scrum. It’s just as simple as that. You can do whatever you want, pick whichever events you want to practice and whichever you want to drop, set your event duration to whatever length you want. Just remember that the Scrum framework can be practiced in its entirety for the result to be Scrum.
Scrum, But...
Secondly, you might be tempted to choose your Sprint duration to be a month. A lot of organizations do that to align with other time boundaries, for example existing planning horizons. That is perfectly fine. A Sprint can be treated as a project with a month's horizon. While this alignment sounds nice, we need to be acutely aware of the pitfalls of longer (long-ish?) Sprints.
Remember that Sprints are the containers for all other Sprint events and designed to provide cadence. They are to ensure that all formal opportunities to inspect and adapt, of which are four, occur within the container and therefore the encompassing time box.
By lengthening the Sprint to a month's time horizon we delay the formal inspection and adaptation opportunities. We should keep in mind that scrum does not prevent us from inspecting and adapting wherever we feel necessary. It is just those formal opportunities that are there to ensure we have the minimally necessary chance for such activities.
If we delay the inspection opportunity, we might be delaying the valuable feedback. This feedback might prove crucial to our ability to timely correct the course. At the same time during longer sprints risks might go uncover or stay unmitigated for longer.
Also, we need to remember that Scrum deals with complex adaptive problems, thus delaying the feedback opportunity will potentially give rise to complexity as shorter iterations and faster feedback loops prove to be excellent complexity busters.
Not in My Comfort Zone
This of it this way. The work pulled into a Sprint should ideally be completed within that Sprint. The longer your time horizon is, firstly, the harder it is for you to forecast what can be done within the longer time box. But also, it is more tempting to skip taking a harder look at work and slice and dice it into smaller manageable vertical slices of functionality that can conform to the Sprint boundaries. Lengthening the Sprint will not get the team out of their comfort zone enough and will let them keep planning for bigger chunks of work. Your PBIs pulled into a Sprint will tend to be bigger, more complex, containing more ambiguity than otherwise, they would have had if they were planned to be completed within a shorter Sprint.
The Other Extreme
Let’s talk about another extreme, where Sprint duration is very short. In Scrum Dojos they practice a One Day Sprint Kata. It is specifically designed to train the team’s muscle memory, to break bad habits of planning for long time horizons, of getting finite work done within a short time period (in this case a single day).
The team lives through a Sprint routine within a day. They start the day with a Sprint planning, do their work, and perform Sprint Review and Retrospective at the end of the day. Some choose to do their Daily Scrum before or after lunch to inspect their progress toward the goal.
This experience is very intense. And you might rightfully suspect that a lot of time that could be spent on doing work is spent in Scrum events. Again, this is an artificial exercise and is not recommended as a “production” routine for the Scrum teams. But it gives us an excellent point to start defining what too short of a Sprint will look like.
In general, the Sprint should be long enough so that its events are not becoming impediments for the team in producing a valuable done increment. In other words, the events overhead should not be burdensome and take away from the work.
One might argue, that an event of any length takes away from the work. While that is true, we should balance that assertion with the benefit of a Scrum event as a formal inspection and adaptation opportunity.
To wrap up the answer, you might want to give some of your experience. What Sprint length have you observed and worked best for the team? Why do you think that was the case? Have any factors mentioned above played a role in selecting a specific duration for the Sprint?
What worked best for you? I would love to hear it in the comments.