The Rationale for a Maximum Sprint Length of 30 Days

August 29, 2011 — Posted by Al Shalloway

What is the rationale for a maximum sprint length of 30 days?

This was a question that someone on the LinkedIn Certified ScrumMasters group recently asked.

There are three reasons. Two are explicitly part of Scrum. The other isn't mentioned but is one of the foundations on which Scrum is based. The explicit ones are feedback and enforced view of reality. The second is removing delays.

Quick Feedback

You want quick feedback. Waiting longer than 30 days for feedback does not give you feedback fast enough.

What sort of feedback? The feedback that lets you learn quickly. Now, feedback comes in many forms. There is the time from getting a request until delivering it and the time from starting a story until it is complete. But you don't need to write all of the code in order to discover that the customer doesn't want it. Instead, you want to write a little on those stories the customer has clear understanding.  Showing a slice of functionality to a customer enables them to learn more about the rest that they want. 

I often hear "fail fast" as a reason.  I personally would prefer to learn fast.  But if I am going to fail, I'd like to do it quickly. But my goal is learning, not failing.

Enforced View of Reality

By enforced view of reality, I mean that the end of a sprint will tell us where we are - objectively, not subjectively.  If testing isn't done, it isn't done.  The reason for it is likely an impediment to our process. Without hard, fixed dates, it is easy to rationalize why we didn't accomplish what we set out to.  Common impediments are customers may not want to talk to you, build processes may be inefficient, testing and coding may be too separated from each other. By having a time-box in which your work is intended to get completed, those things that work against you will become more visible and painful. These are impediments to your work actually, and instead of avoiding them by making the sprint length longer, you actually need to shorten the sprint to expose these even more. It is also harder to ignore them – if you haven’t tested your code by sprint’s end – it’ll be obvious and irrefutable.

Both of these reasons actually tend to call for even shorter than 30 days sprints. Most successful Scrum teams I know of use one or two week sprints. In fact, I’d go so far as saying teams with three or four week sprints are showing a “smell” of not being engaged enough in solving their problems. This is not always true, but it is true often enough.

Remove Delays

The third reason, which in many ways is the biggest one, is removal of delays.

Since about 2004, I have been claiming that Scrum is a weak implementation of Lean principles. I say “weak” because Scrum does not deal with optimizing the whole (it focuses on the development team) and it leaves out a lot on lean-education and management. But one of the key tenets of Lean is to remove delays so value can be delivered quickly. This is critical because delays between steps of work literally create more work.

Note: For more on this, see the Net Objectives Lightning Webinar, The Real Tenets of Lean: Avoid Creating Waste by Eliminating Delays

Time-boxing in Scrum requires teams to complete their work quickly, it encourages swarming as well. This all reduces delays and therefore avoids incurring work that doesn’t need to happen.

The combination of feedback, awareness and removal of delays drives us to have shorter feedback loops until the overhead of the sprint overcomes the value achieved by them. For most teams this will be one or two weeks. Some teams that discover they don’t need the discipline of the time box will abandon it completely and move to Kanban.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


I rather like "learn" as the way of putting it since "fail" is a scary word which requires more explanation than "learn" would to cover the same idea.

As to Sprint/iteration lengths, I always ask clients to start with no more than 2 weeks so the teams get 3-4 cycles of working within a Agile/Scrum framework as quickly as possible, urging management to focus on the learning and team development rather than raw productivity in these early iterations. Doing even 4 week iterations means it takes 3-4 not a couple months to go through the cycle.

It's also been my experience that it only takes a week or two in a 4-week iteration for things to pop up that need to be addressed. The last couple weeks are often just dealing with what has popped up anyway.

After teams feel like they understand the framework and what is being expected, if they want to lengthen the iterations, I don't argue too vociferously. I do ask them why they want longer iterations and the answers I get are all related to the perception that more output is needed per iteration than two weeks allows for. They see the "extra" planning, review, retrospective time for two iterations per month rather than one as time they could use to code and test. This suggests to me that they aren't comfortable yet with working in a manner that has an sense of limit on workflow or "doneness" and usually suggests there is some feeling of management pressure to produce more, faster.

It is interesting that, in the last almost 9 years of focusing mostly on Agile approaches, only once did someone ever suggest an iteration longer than 4 weeks. However, being willing to even just start with something less than 4 weeks is quite often rejected. I have heard, on a few occasions, folks actually say they didn't think they could get much of anything "done" in just 2 weeks. In examining how they are working, what I have seen is iterative waterfall going on rather than daily, iterative collaboration. In such a case, I am not surprised that it takes them a month to have anything "done" given the handoff approach used during the 4 weeks.

In such cases, though, every team I have worked with has agreed that it only takes them 7-10 days to know what the issues are for that iteration. The rest of the time is used to "catch up" to meet what they said they would try to accomplish during the iteration.

One client I worked for had been working in their "hybrid" version of Scrum when I was asked in to "coach" them to improve their process (though it turned out what more senior management expected was a development manager to "drive the work to conclusion," so I did not encourage them to believe that's what I wanted to do). What they had settled into was 4 3-week iterations per quarter since they had quarterly release expectations for their international sales force that their application(s) supported. However, to deal with the "oops" recognition midway into the 3 weeks, the last iteration of the 4 was "open" to cover all the things undone and being carried over through the first 3 iterations.

In almost all of these kinds of situations, what I think is not learned is how to estimate and commit to what can reasonably be done within 3 or 4 week iterations. At the client I mentioned above, a couple senior developers, knowing the quarterly expectations, basically felt it was a waste to estimate, prioritize, etc. because "we have to get it all done anyway." What was "reasonable" was to get it all done so they took a "stretch" goal that would take more than 3 of their iterations, but could probably be done in 4. (They also worked a 50 hour week which was their "sustainable pace," i.e., an assumed 2 hours of unpaid overtime per day over the week.)

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban