Sprint Maximum Duration

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.

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

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.

Thanks for the response.