Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Sprint Maximum Duration

Last post 03:54 pm February 2, 2015 by Sujoy Datta
4 replies
11:42 am February 1, 2015

I know it is specifically mentioned in the Scrum guide "Each Sprint may be considered a project with no more than a one-month horizon".
However wanted to understand whether any of you are working on any projects that have more than one month of sprint duration? If yes, does that mean scrum principles are not being followed?


11:35 am February 2, 2015

By definition a Sprint cannot be longer than one calendar month. Therefore any so-called Sprint of a longer duration will be invalid, and it would mean that Scrum principles are not being followed.

Note that the Agile Manifesto allows up to two months betwen each delivery of customer value, albeit with a preference towards shorter timescales. Iterations of greater than a month may therefore be arguably agile, although they would not be Scrum compliant.

Also, bear in mind that Scrum Sprints must result in *potentially* releasable increments and that the time between actual releases may therefore exceed one month. However, if the release of an increment equates to the delivery of customer value, and if release is deferred for longer than two months, then the Scrum implementation (although strictly valid) would not conform with the principles of the Agile Manifesto.

Therefore be sure to time-box Sprints to no more than one month in length, and aim to release an increment into production at least every two.


01:20 pm February 2, 2015

Thanks Ian for the detailed reply.
However, I have one more question. If in a project production releases happen every two months, wouldn't it be advisable to also have the sprint duration for close to two months. I say that for some specific reasons -
1. Saving on the time required to give builds for each environment - QA, UAT and Production
2. Saving on the time for frequent code merging


02:03 pm February 2, 2015

A Scrum Team should take the opportunity to release, at least once per month, into an environment that is as close to production as possible. The Definition of Done should be as close to production quality as the team can make it.

It is better to deliver into a pre-production environment at least once per month than not to deliver. Inspect and adapt opportunities will then be available, and the team should use them to improve the potential for releasing into production at that cadence.

If a Sprint does not actually release an increment into production then the team has scope for improvement:
- perhaps the DoD is inadequate and needs revising
- perhaps the PO has misunderstood the business opportunity
- perhaps the team and/or the Scrum Master failed to anticipate a critical impediment
- perhaps excessive waste was incurred
- perhaps team estimation was poor

The reasons for failing to release an increment into production are varied, and they should be challenged and remedied in the Sprint Retrospective.


03:54 pm February 2, 2015

Thanks for the response.


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.