A Scrum Team can change the length of a Sprint

I’m not sure I would describe a single experiment over the course of a year or more as being “often”. What do you think the effect would be on predictability for the team you have in mind?

This is a bad idea. There should be consistency in the length of Sprints. The shorter the better. I advise on no more than a one week Sprint. Efficient software organizations should be doing frequently releases to keep up with customer needs and satisfaction.

However, the reality is that large legacy organizations will never get there because traditional Project Management is embedded in their DNA and they are comfortable with Portfolio Governance dictating four releases a year based on bizarre combined milestone Program Plans.

Here is a good article for you.

One thing to consider with sprint length is the ability to craft powerful Sprint Goals.

Shorter sprints offer more frequent inspect & adapt moments, and the ability to change direction more often.

Longer sprints may make it easier to set more outcome focused goals, and allow the team greater opportunities to change direction within a single sprint.

Changing sprint length has an impact on transparency. It makes it harder to understand, based on empirical evidence, what can be done within a single sprint.

But it is expected that the team and organization will try to continuously improve. Given the impact of changing sprint length is understood, and a change appears likely to be beneficial, why shouldn't the team do this? As more is learned, it might seem beneficial to switch back to a previous system. That is also fine.

It could be a good topic to discuss during a Sprint Review, as the change would also affect stakeholders.

In my experience, when people propose a changed sprint length, it's often to solve a particular problem, and sometimes there's a better way to achieve it.

For example, if the assumption is that shorter sprints enable more releases, that's not necessarily true.

There is nothing in Scrum that forbids releasing frequently throughout the sprint.

If it's about changing direction more frequently, consider my opening comments about Sprint Goals.

If the assumption is that it means a reduced waiting time for picking up items (e.g. high priority bugs) discovered during the sprint, again there is nothing in Scrum that prevents the team finding a way to treat this work as "business as usual", and pick up the items as needed.

I think, in big projects, there will be multiple Scrum Teams working together on the same product. So most likely, the work will be equally divided into these teams, unless the team sizes differ or some teams are formed with scpecialized skillset. Also, I believe that all these teams are free to define their own Sprint lengths.One of the outcomes of the Scrum is that team delivers at a sustainable and consistent velocity; and not to maximize the delivery in one Sprint. In that sense changing Sprint length frequently will prove less productive. If the project is encountering such situations frequently, then it indicates that the Product Backlog is not properly groomed and PBIs are not properly 'broken down' and prioritized.

Experts, please let me know your thoughts.

There is no correlation between the length of the Sprint and the cadence of release to production.

Hence, your cadence of release is not a criteria for the length of your Sprint.

There is no correlation between the length of the Sprint and the cadence of release to production.

I disagree. The Scrum Guide can be really unhelpful when having this kind of conversation, as there is such frequent reference to teams producing "an Increment". Indeed a sprint is described as:

a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created.

I certainly take the view that the Scrum Guide doesn't forbid releasing multiple times per sprint, and I remember when announcing the 2017 changes to the Scrum Guide, Ken Schwaber and Jeff Sutherland were clearly positive about releasing more often.

There shouldn't be a correlation (in most contexts), but the current wording of the Scrum Guide does very little to encourage teams to discuss the frequency of releasing, and so by default, there is a strong correlation.

Replacing "a" and "an" with "at least one", when talking about releasable Increments, could be a start.

Creating a "releasable increment" before the end of every sprint and actually releasing the increment when the PO asks the Dev Team to do so is not the same.

Whatever is the length of your Sprint, Scrum is totally open to continuous delivery, or release once a quarter if the PO decide it fits the context, even if the general rule is the more often, the better.

Whatever is the length of your Sprint, Scrum is totally open to continuous delivery, or release once a quarter if the PO decide it fits the context, even if the general rule is the more often, the better.

I think we're generally in agreement. I certainly feel we agree about what Scrum allows, and I suspect we have similar views on the reasons a Product Owner might favour releasing more or less than once per sprint.

I'm highlighting a risk in case Scrum Teams rely entirely on the default accountabilities, with no additional agreements in place.

Release strategy can therefore be relevant to a discussion about sprint lengths, and vice versa.

If by default, we accept that Development Teams are accountable for producing one releasable Increment per sprint, changing sprint length has the potential to impact how often a releasable Increment is produced.

If a sprint length increases from two to four weeks, and the team were previously producing one Increment per sprint, it would be wise for the Product Owner and Development team to discuss their expectations. A Development Team may not wish to accept accountability for producing more than one releasable Increment per sprint.

@vivek you need to look at dependencies, not equal division.  You want to try and minimize cross-team dependencies as much as possible.

I think, in big projects, there will be multiple Scrum Teams working together on the same product. So most likely, the work will be equally divided into these teams, unless the team sizes differ or some teams are formed with scpecialized skillset. Also, I believe that all these teams are free to define their own Sprint lengths.

Vivek, if a Sprint Review leads to a significant shift in the product direction, what would happen to the in-progress Sprints?

If the answer is that they would be unaffected, could it be that these teams aren't really working on the same product?

If they would be affected, could it be more effective to have a single Sprint Review for all teams, where they are all able to adapt in a co-ordinated way, in response to what is learned?

Vivek, if a Sprint Review leads to a significant shift in the product direction, what would happen to the in-progress Sprints?

The Scrum Guide says that -

'A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances.'

So yes, the individual Sprints may be canceled.

If the answer is that they would be unaffected, could it be that these teams aren't really working on the same product?

Yes. It is possible that they are not working on a same product. Or, due to significant change in the product direction it actually results into a totally different product.

If they would be affected, could it be more effective to have a single Sprint Review for all teams, where they are all able to adapt in a co-ordinated way, in response to what is learned?

Yes. I was reading the Nexus guide, and got an impression that answers to these questions may be found in the Nexus framework. The Nexus Integration Team, according to Nexus Guide, is accountable for ensuing that a "Done" Integrated Increment is produced at least once every Sprint. So individual Scrum Team may have one or more Sprints within a bigger Nexus Sprint; and will continuously integrate their individual releasable Increment to the main Product release. At the time of Nexus Sprint Review, if a significant shift in the product direction is identified, still, the Nexus Integration Team has to typically accept the "Done" part of the work.

Nexus Sprint Review replaces individual Spring Reviews that will focus on Integrated Increment.

But Nexus mandates the each Scrum Team should have their individual Sprint Retrospective after the overarching Nexus Sprint Retrospective, which gives opportunity to individual Scrum Teams to inspect and adapt to the integrated environment and process. In these restrospective meetings, Scrum Teams may realize the improvement areas like lengths of Sprints, stronger continuous integration process, integrated release management, etc.

In nutshell, I think that each individual Scrum Team can have different Sprint lengths, but they may realize that in scaled environment it is good to have common time-box for all Sprints.

Apologies for long answer; I just wanted to put my thoughts into words.

The length of current /ongoing Sprint cannot be change 100% true but if there is obstacle or team is not confident deliver commitment due to some reason in that case instead of increasing Sprint length, it can be terminated with PO and team agreement. Agree ?

The length of Sprint can be change during Sprint planning as per the priority of features, story points etc. with the agreement of dev team and PO.

All due respect to @Mark Adams, I completely disagree that "shorter is better" and I have a hard time supporting your stance that you only advise 1 week sprints; that's not up to the Scrum Master or Coach to decide.

Back to the OP's question of changing the sprint length, Scrum is based off Empiricism so if the team finds that their initial decision for 3 week sprints isn't working, absolutely they should inspect and adapt to find a better cadence. The questions I pose for this are:

1. Why? 

2. What is hindering and weighing us down in the current cadence that WILL be resolved in a longer sprint cadence? 

3. What are we hoping to gain by changing the cadence? 

Usually if the team says "we can't get anything done in 2 weeks so we want to go to 3 weeks" that's usually a sign of them taking on too much or not having properly refined backlog items etc etc. Changing the cadence strictly for the sake of changing the cadence is not going to do anything beneficial if they don't solve the underlying reasons prompting the change. That being said, I would not advocate changing them every other sprint or anything. Pick a cadence, go with it for 3-4 sprints and if need be, try a shorter/longer sprint and go another 3-4 sprints to see what works. 

I like Curtis’ idea of validating a Team’s assumption about the Sprint length. I can image that the optimal Sprint length depends on the Team’s experience, current technology, the product, the market and other factors. Why not use the learnings as a feedback loop? The resulting insights can leverage future benefits. Isn’t that what Scrum is about?