Length of a sprint

but with 4 weeks it is fixed.

You answered your own question.  The key is a consistent cadence.  If you do calendar months your cadence varies between 28 -31 days.  It is not consistent.  Four weeks is 28 days every time. 

Simple question, how long should sprints be?

Simple answer is long enough to be able to deliver a potentially releasable increment of value on a consistent basis. My view is that if you can't deliver something like that in 4 weeks or less, you have some opportunities to improve.  But the longer the sprint the longer the feedback loop.  So find a length that provides the most effective use of your team's time and maximizes the feedback received from the stakeholders.  

Not every product and team will be successful with a "standard" sprint length.  Each team should determine the effective sprint length for them and not use a sprint length forced upon them from executive management. 

One month could make it easier to co-ordinate with any business events that are held monthly. The variation in the length of each time-box is predictable, and they are consistent enough in length to make significant problems the exception rather than the rule.

Thanks for your replies. Interesting that the guide doesn’t state 4 weeks then as a calendar month doesn’t seem like a very common choice or even a recommended one!

While it likely doesn't work well in many areas, there is nothing that says you can't have a 15 day sprint, or 23 day sprint, or even 2 day sprint. So to answer your question as to why the SG doesn't just say 4 weeks...

Calendar month vs 4 weeks: 

- Which harbors a greater ability to be more flexible? 

- Which is more prescriptive?

- Which fits in better with a framework vs process?

I believe that were the timebox "4 weeks" it would automatically set the expectation that sprint length must be determined by number of weeks, so you only have 4 options: 1 week, 2 weeks, 3 weeks, or 4 week long sprints. With the term as "less than one calendar month", that gives teams literally 31 different options for sprint lengths. Clearly that allows for more flexibility for the teams to utilize the scrum framework to fit their individual and unique needs and product. That is exactly why scrum is a framework and not a process: flexibility with the absolute bare minimum rules in place.

Hi Curtis, I do get your point. My argument to say max of 4 weeks (still have 28 options that way) is that for every length under 4 weeks it is possible to maintain consistent cadence. Setting a calendar month as your cadence just seemed counterintuitive to maintaining consistent length.

Thanks for everyone’s answers. It’s not something that particularly bothers me, I just thought it was an interesting discussion point :).

Ryan Brook, let me add more to what Curtis Slough explained.

I have seen successful teams whose sprint lengths are 3 days and 4 days ! This will help the team hyper focus and greatly reduce technical debt and improve quality and increase the opportunities to learn through inspection from frequent feedback. 

I would say the focus here should be the reason for a upper limit of the sprint length rather than whether is is 28,30 or 31 days

When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost. - Scrum Guide

Sure we can propose to change the word "Calendar month" to a more strict units of time like 30 days or 20 working days etc. But the principle is still as mentioned above, "to reduce the risk and enable predictability by ensuring inspection and adaptation."

Exactly. Another point, while the days themselves may not exactly match, going with "calendar month" adds another sprint length option that # of days or weeks doesn't allow. Sure that means your sprints will fluctuate between 30 and 31 days mostly and then Feb comes in and it's only 28 days. You're still following a consistent sprint length because the sprint length follows the calendar month. Doesn't really matter that the majority of teams using Scrum have 2 week sprints, the SG saying "Calendar Month" allows for even more flexibility. That is the point of it being a Framework, not a process. 

Not read all the replies above so excuse me if I'm commenting on what's already been said. A quote that Ive read and teach in our organisation is a quote from Ken Schwaber, who says, “A Sprint should be as short as possible and no shorter.” Makes a lot of sense when you think about breaking down complexity and limiting risk.