Skip to main content

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

Last post 11:07 pm January 2, 2014 by Millard Ellingsworth
4 replies
10:22 am December 15, 2013

Hi everybody,

One question about Scrum framework.

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

Thank you in advance.

05:47 pm December 15, 2013

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

06:00 am December 16, 2013

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

02:49 pm December 18, 2013

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.

11:07 pm January 2, 2014

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.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.