Skip to main content

Length of a sprint

Last post 09:48 am December 5, 2023 by Simon Pittaway
8 replies
01:18 pm April 21, 2020

Simple question, how long should sprints be?

My knee-jerk response to this question has always been '4 weeks maximum and a consistent length unless the team decides to change it'. But the Scrum guide specifically says less than 'one calendar month'.

My question is, why doesn't it say 4 weeks? If the sprint length was set at one calendar month, the length will change, but with 4 weeks it is fixed.

Thoughts?


03:25 pm April 21, 2020

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. 


03:33 pm April 21, 2020

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.


08:16 pm April 21, 2020

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!


05:05 am April 22, 2020

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.


09:29 am April 22, 2020

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 :).


03:20 pm April 23, 2020

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."


05:18 pm April 23, 2020

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. 


09:48 am December 5, 2023

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.