Reasons for choosing a month sprint over a two-weeks sprint

- When work is too big to decompose and team can't complete within 2 weeks. That said, I am not 100% convinced with this answer. I.e. this is not the primary reason for 1 month sprint in my opinion.
- Project with long time duration commitment (> 1 year?) so that stakeholders/PO are willing to risk 1 month. I.e. loosing 1 month is not that significant loss than loosing 2 weeks (from stakeholders' and PO perspective).
- 2 weeks sprint is getting in the way for company to do other work
- I think 1 month is too long. 2 to 3 weeks is a good balance.
- 1 week sprint is quite normal as well (eventually team will know how to decompose PBIs to fit into 1 sprint)

> What reasons would be reasonable for choosing a month sprint over a two-weeks sprint?

1) When the organization is known to have a release cadence of one month, and half of the two-week sprints would therefore not be potentially releasable
2) When the Product Owner cannot articulate Sprint Goals and the corresponding release of Incremental value in timeboxes of less than one month
3) When the Development Team cannot commit to two-weekly Sprints, but can commit to monthly ones.

When determining the sprint length consider the following:

How long can the team be protected from outside interference?
How long does it take the team to build something of significant value?
How often do we need to inspect the current status and progress of a project/product and adapt the plan?

Answering these questions will help the team decide a proper sprint length.

Wish there was a way to +1 Fredrik's answer.

There's also a slightly different way I'd think about his third point: When you consider the continuous improvement aspect of Scrum, driven by the retrospective, the more often you have them, the more opportunities to discuss and implement improvements.

In general, with teams new to Scrum, I push for 2 week sprints (rather than 4 weeks). This helps us build our scrum muscles more quickly. Depending on how agile the new team is, there can be so much to absorb (you'd think that would argue for longer sprints, but my experience tells me that new teams will wander too much and lose the scrum focus). Some teams have no idea how hard it is to get "done" -- they've never done it (not without 4-6 weeks of QA and hardening). Some teams have never self-organized. Put those two together and you could have a month of chaos (so let's make it just 2 weeks and get to a quick inspection). And that's ignoring important technical practices they may also need to master.

Biting off a small piece of functionality while really nailing the "done" criteria is eye-opening and empowering and encouraging.