Agile Software Development

What Is the Best Time of Week to Start a Sprint?

The workweek starts on Monday. Might as well start the sprint then too, right? Of course not, or else this article would be a waste of time. Comcast’s Jeffrey Johnson discusses at Scrum Alliance the many factors that come into play for finding your sprint start sweet spot.

One Fine Day

There are several troubles with adhering to a sprint schedule that involves starting on Monday mornings and ending on Friday afternoons. One of them is that Mondays and Fridays are the days that employees most often use vacation days (in the U.S. at least), and many holidays fall on Mondays. Additionally, employees may not be enthusiastic to go through sprint reviews and retrospectives at the very end of their workweek, especially if company culture grants people early leave on Fridays. And yet another problem is that spending the weekend away from work means it will take more time to get back up to speed for the next round of sprint planning.

These are issues that exist even when the team is all located in one space. If working across vastly different time zones, a sprint review conducted on Friday in one location could be Saturday elsewhere. Nobody wants that. As a result of all of these factors, Johnson recommends starting sprints in the middle of the day, in the middle of the week.

That being said, he also says never to change a calendar in mid-sprint, because a commitment has already been made. He then adds this:

When you do decide to change, how [do you] handle the “remainder” in the equation? You can choose during sprint planning to have a single shorter or longer changeover sprint to align with the new calendar. Remember, this will result in a sprint with a different velocity, so be aware of this when planning and looking at trends. This should revert immediately back in the next sprint. (Remember, we are only talking about shifting the alignment with the weekly calendar. Scrum teams should have a consistent cadence.)

There are numerous dimensions of complexity to optimizing sprint time, such as what to do when there is little or no overlap between teams. For a bit of discussion on how to handle overlap issues, you can view the original article here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.