Sprints Starting Mid-Week in Scrum

Question

When people discuss Sprints that start or stop mid-week, they seem to agree that this should be done on a Tuesday or Wednesday. Why is that?

Also, how do week-long Sprints with mid-week starts and stops follow each other without constantly moving which days of the week are used? For instance:

• Sprint 1: Tuesday to Tuesday, next sprint starts Wednesday.
• Sprint 2: Wednesday to Wednesday, next sprint starts Thursday.
• Sprint 3: Thursday to Thursday, next sprint starts Friday.

Is the idea to do Wednesday to Wednesday, where Wednesdays are the end of the current Sprint and the beginning of the next?

Answer 1

Also, how do week-long Sprints with mid-week starts and stops follow each other without constantly moving which days of the week are used? For instance:

Sprint 1: Tuesday to Tuesday, next sprint starts Wednesday.

Sprints always start on the same day of the week. That means they must end on the day before that. M-F or T-M or W-T or Th-W.

When you're first trying to get used to this, it helps to count off the working days, remembering that there are 5/10/15/20 days in a 1/2/3/4 week sprint.

When people discuss Sprints that start or stop mid-week, they seem to agree that this should be done on a Tuesday or Wednesday. Why is that?

I've seen recommendations for starting on Wednesday or Thursday, because there are important Scrum activities that normally occur on the first (sprint planning) and last (review & retro) days of the sprint. Starting or ending a sprint on Mondays or Fridays runs a higher risk of regularly missing folks who are taking a vacation day for a long weekend, or are leaving early on Friday or coming in late on Monday.

But there is no absolute/intrinsic answer to this one. It depends on your local circumstances.

Answer 2

Think in Five-Day Cycles

You're thinking in seven-day cycles for some reason. You may have a specific use case for this, but I would consider it unusual to plan this way. As a general rule, Sprints are based on single teams, and a team usually plans around 40 hours per person during each week, and five business days per team.

So, if you're planning one-week Sprints, you could start on a Monday, end on a Friday, and then start again on the following Monday. This is a typical cadence, and certainly the most common.

Scrum teams that don't decouple delivery from deployment might prefer not to deliver on a Friday, because in such shops there may be no one to tend production over the weekend immediately after new features have been rolled out. In that case, they may prefer to deliver earlier in the work week. This gives newly deployed code a couple of days of "burn in" before everyone leaves for the weekend.

In this type of cadence, starting each Sprint on Wednesday and ending on the following Tuesday (along with the associated deployment) leaves three business days for burn-in and urgent bug fixes. You could also start on Thursday and end on Wednesday, or (for teams that only allocate half a day each for planning and review/retrospective ceremonies) start and end on the same day each week.

The Whole Thing is an Anti-Pattern

In case it isn't obvious, all the atypical cadences above are really anti-patterns. They are trying to work around defects in staffing, planning, process, tooling, or organizational politics by routing around the problem rather than resolving it.

Truly agile teams should decouple delivery from deployment, and the Definition of Done should include sufficient quality assurance and continuous integration testing to assure that breaking changes aren't likely to make it into production. If these things are done properly, there's no reason to have weekly Sprints that are out of sync with the Development Team's work week.

In close to two decades of agile implementations, I have yet to see this type of delivery cycle serve any purpose other than to cover up an X/Y problem of some sort. If you think you have to do it, then the organization is probably less agile than it imagines itself to be.

If you must do it, then adjust your delivery dates to fit somewhere within the middle of the work week where it is least likely to be disruptive to developer flow. As a singular example, delivering on a Monday is usually a spectacular failure for most teams that break for the weekend, although your mileage may certainly vary. Even when following an anti-pattern like mid-week delivery, it's usually best to optimize for flow and shorten Sprints to fit within a predictable weekly cycle.

The Scrum framework optimizes for predictability. Select odd or unpredictable Sprint lengths or unusual delivery cycles at your own peril.

Answer 3

As the other answers are highly focused on the last half of your question, I'll review the first half...

When people discuss Sprints that start or stop mid-week, they seem to agree that this should be done on a Tuesday or Wednesday. Why is that?

Based on my experience, it's part psychological and part practical - Your mileage may vary, and that's very important to avoid a debate on comments. Let's see the options (assuming a proper sprint, i.e. Mon to Fri, Tue to Mon, Wed to Tue and so on):

• Monday: Not a good candidate due to psychological factors (Monday is not the most beloved day of the week by nature) as well as technical factors (if there's working happening over the weekend such as a delivery or a validation, chances are people won't be very happy also starting / stopping iterations).

• Tuesday: The opposite of Monday, with almost the whole week ahead. Usually done on one week iterations. You have a Monday to wrap up what you had pending from previous week and can plan properly how to "start the week". Also, it breaks the (one week) sprint into 4+1, so psychologically speaking people could tend to plan tasks considering 4 days plus one for "margin". I'd say that's the common approach on teams onboarding Scrum.

• Wednesday: Psychologically speaking, a less powerful version of Tuesday as you have less week ahead (although you have Mon and Tue next week). This problem almost disappears if you work on sprints with two weeks (or more). I'd say that's a good candidate for more mature teams.

• Thursday: You start the day with the planning, a lot of energy and enthusiasm. By the time you actually start work (Thu afternoon, potentially) you have only a day ahead before the weekend. That could have a massive negative psychological impact. Besides, by the time the iteration start, people could tend to think "heck, week is almost over, things will start for real on Monday!".

• Friday: A Thursday on steroids (in a bad sense). You dedicate a lot of time and energy to review stories, understand and plan them. By the time you completed, you have to go home and try to remember everything after a week enjoying life. Not the best, definitely.

However, the sprint demo - a byproduct of sprint finish - could be one good reason for having sprints finishing on Thursday (or Friday). Psychologically speaking, there's more negotiation and compromise on a Thursday and Friday than any other day of the week.