I'm currently the PM on a project that is scheduled to run for about 14 months. The current sprint structure is 4 weeks of development; week 5 allows us to show the progress to the client, deploy it for their testers, eliminate bugs and discuss the next sprint.

Given the length of the sprint is 4 to 5 weeks, it will generate about 13 to 14 sprints. Is this a reasonable number of sprints, or should we look to have fewer sprints (say 8-10) for a project of this duration? Is there a rule of thumb on a reasonable number of sprints for a project with several man years of budget?

  • I edited your question. I think you meant to say "Given the length of the sprint is 4/5 weeks...."
    – jmort253
    Commented Apr 30, 2011 at 21:20
  • @jmort253 no problem.
    – amelvin
    Commented May 3, 2011 at 22:20

16 Answers 16


If you were new to Scrum and sprints, I would say you should start with some given length (3 weeks or 30 days) and check if it works for you and make changes if necessery. Instead, it looks like you are already familiar with sprints, so question is: what is your experience with sprint duration? Do you have any doubts which makes you ask the question?

I can see couple of influencing factors:

  • Sprints come bundled with some additional time cost (meetings, plannings, demo, free day also?). Too short sprint means work/cost ratio will be low.
  • Sprints should deliver. If you choose too short sprints, some of them will be dummy ones: with sprint goal not achieved, with almost nothing interesting to show on demo, sprint goal will be a stub itself and retrospectives will tend to be dull. In other words, sprint will fail to deliver.
  • ...and deliver frequently. If you choose too long sprints, you will probably notice: overcrowded demo, too many goals per sprint and retrospectives where nobody remember what happened at the begining of the sprint. Client will be "flooded" with features once the sprint is over, so sprints are not frequent (agile) enough.
  • There should be no delays between sprints. Do the demo, retrospective, backlog evaluations, (day off if there is such rule) planning meeting and start the next sprint. You should take a closer look at the 5th week as it takes 20% of your time. You can probably eliminate bugs in sprint time, make deployment easier and regarding PO's: they should have tasks for the next sprint prepared already, shouldn't they?

I can not give you the exact number of days sprint should take, as what I said above is tightly connected to the team quality, technology and architecture used, and product you are working on. It is probably not the best idea to change the sprint length too often because it affects your and team ability to predict velocity.

  • +1 but disagree about no delays between sprints. Given the size of the project and company, it may be impossible to have the backlog fully prioritized and rearing to go at the start of each sprint.
    – ashes999
    Commented May 1, 2011 at 22:30
  • Not sure if it is not a better idea to start such sprint anyway. Well, I don't have enough information to judge. Commented May 2, 2011 at 5:32
  • +1 Not my first sprint - but the longest project I've faced in an agile fashion. I'm concerned that in the early stages when the project shape is still settling down whether longer early sprints may make sense on the work/cost ratio.
    – amelvin
    Commented May 3, 2011 at 22:23
  • Usually a team gets momentum rather by doing more of the technical tasks and removing impediments than by setting sprint length. I would also recomend watching the outcome of the retrospectives - are the impediments/improvements found and are the proper actions taken? Commented May 4, 2011 at 6:03
  • 1
    Bartosz - you made a factual error. The timeboxes for the Scrum ceremonies scale linearly with the length of the Sprint so they should be a now issue. Commented Dec 17, 2013 at 19:21

The shorter the sprint - the better. That's the rule of thumb. However there are many obstacles which do not allow us to deliver every, say, week. Some of these obstacles are:

  • project sponsor/customer has certain bureaucracy
  • resources (people) are slow in delivery
  • some tasks take longer and can't be broken down to sub-tasks

These are the most important. Analyze yours and try to fight with them in order to make your sprints as short as possible. In general, your 4/5 weeks duration looks reasonable for average circumstances. But again, I would recommend to try to make it shorter.

  • Does this assume that the sprint has planning, retrospective, and daily standups and demos and all other meetings? ...or I guess that would fall under bureaucracy.
    – user27307
    Commented Apr 5, 2017 at 18:35

In general the shorter the sprint, the better even when you are starting. The shorter the sprint, the sooner to inspect and adapt. Shorter sprints will also encourage better agile practices: reducing work-in-progress, reduced batch size and better throughput. Longer sprints can encourage old waterfall habits. In a recent webinar we delivered to 2,800 people we polled attendees for the most common sprint length and slightly over 50% responded with 2 weeks. This is the sprint length we generally recommend although there are more mature teams that have no sprint at all.

  • I don't think this works considering that non-agile methodologies like waterfall are essentially sprints of months (possibly even up to 2 years for enterprise). Short sprints from that perspective might hinder adoption.
    – ashes999
    Commented May 1, 2011 at 22:32
  • Do you by chance have a link to that study on sprint length? I'd like to check it out, if possible. Thanks!
    – jmort253
    Commented May 2, 2011 at 5:18
  • jmort253 this was a poll question asked at a recent Rally webinar. The recording can be found here rallydev.com/events/agile_webinar_series/…. The question was asked about 20 mins in. The results were gathered and shared with attendees but not published (at least not yet).
    – Ken Clyne
    Commented May 10, 2011 at 4:31
  • 1
    ashes999 thanks for the response, i am always happy to hear other perspectives but my experience so far is that generally shorter sprints work better. longer sprints add risk with work remaining partially complete for too long and the inspect and adapt cycle essential for continuous improvement under nourished.
    – Ken Clyne
    Commented May 10, 2011 at 4:39

From my experience I found it good to have 7-10 day sprints at the beginning and increasing it to 15-20 days later on as the team got to the norming/performing stages.

  • 1
    Hi Adrian and welcome to Project Management Stack Exchange. Can you elaborate on why it's best to start with smaller sprints and then increase them later? If possible, please try to back your answer with references. If references won't apply, such as in this case where the answers are based on your personal experience, you could explain why this approach has worked for you and qualify the answer with your own professional experience. Thanks for participating, and I'm personally looking forward to hearing why this is helpful. :)
    – jmort253
    Commented May 2, 2011 at 5:16
  • 1
    I was thinking of the other way round - how did lengthening the sprints work for your project?
    – amelvin
    Commented May 3, 2011 at 22:30
  • @jmort253, thanks.
    – Adrian B
    Commented May 4, 2011 at 14:07
  • 1
    As the team for the project is usually a newly formed one, they would need to go through the 4 phases of team formation - Forming - Storming - Norming - Performing. During the first 2 phases the teams productivity is quite low, the main driver being the need to shine vs the team shining (This is especially true if there are new-comers to Scrum in the team). In order to make the team uniform and make the team members feel responsible as A ONE, I found it useful to make them feel the whole life cycle of a Sprint as frequent and as early as possible.
    – Adrian B
    Commented May 4, 2011 at 14:15
  • 1
    Another thing is the PO's view on the product that is in development. The experiences I had, the PO and the Business Stakeholders get a sense of what they want after the first 2-3 sprints - when they can actually roam around in the product, that is the moment when they come down to Nice, Big, Juicy User Stories or Epics, that would require a longer sprint to produce, that is why they grow a bit to that moment. As @amelvin said, sprints would decrease in size late when the product would be in maintenance, but I would suggest moving to Kanban at that moment. PS: Sorry for multiple resplies
    – Adrian B
    Commented May 4, 2011 at 14:20


I worked on a three-team project where for a 15 month effort we ended up using two week sprints - this (for us) was the optimal length.

I say "ended up" because we quite deliberately, in the first few months, tinkered with a number of the basics, and sprint length was one of them. Longer sprints (IIRC, 4 weeks was longest we tried) was not effective. We felt feedback was taking too long to get (retrospectives), stories were less precise, and problems seemed to drag on rather than get closed down quickly. I don't believe this is a simple given - another project's teams might handle this better - but our experience was that shorter is better.


There is no rule here. The most common sprint length is 2 weeks. Vast majority of teams, I'd say more than 90% of those using time-boxing, would have anything between 1 and 4 weeks.

But then I don't believe there's a universal solution which suits everyone.

There are no rules regarding how many iterations you should have in the project or how the number of people in the team affects the sprint length. You can often hear "the shorter the better" but it's really about feedback loops. Ask yourself how short, or long, feedback loops you need. How often do you plan check up of your course? Since the end of each iteration is a natural occasion to perform such check it may be a good hint there.

Anyway, probably the best piece of advice if terms of deciding on sprint length you may get is: experiment.

Try with whatever feels good, you may choose one of industry standards if you have no better idea, and then look how things are going, adjust it and evaluate results. If you have 14 months for the project you also have enough time to find the right rhythm for you.

After all, much depends on people in the project team and this is something which can hardly be evaluated using simple methods. It's better to check what works and what doesn't than to make extensive analysis on the subject. See Nathan Furr's article on planning versus experimentation as a reference.

  • +1 Thanks for the reference; experimentation should be possible.
    – amelvin
    Commented May 3, 2011 at 22:27

According to ScrumMethodology.com, a sprint is 30 days long. However, I can see advantages and disadvantages in having both longer or shorter sprints. In fact, the Scrum.org website's Scrum Guide describes a sprint as being no more than 30 days for the following reasons:

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

The longer the sprints become, the less agile you really are, especially if you follow the scrum methodology rules that don't let you interrupt or change the sprint in the middle.

The smaller the sprints, the more agile you become; however, it may be more difficult for the development team to get more work done since the product must be in a working version at the end of each sprint.

I feel like the complexity of the current sprints could very well dictate their length. If you're at the phase of the project where you're just resolving minor bugs, then maybe smaller sprints are easier. However, if you're making major changes to the system that require a lot of focus by the development team, then longer sprints may be more appropriate.

Finally, consider that if the sprints need to be longer than 30 days, you may need to check with the development team and ask them if they're designing the system with agile best practices in mind. Many techniques that are popular today, such as using a RESTful architecture, allow for independent deployments of modular components, which helps prevent bugs in other systems and create an environment where deployments can in fact be made more frequently.

  • +1 Just finishing the first sprint - wondering whether the sprints might benefit from being longer to start with and then shorter once momentum builds.
    – amelvin
    Commented May 3, 2011 at 22:26
  • 2
    The information on that site about sprint duration, is not correct if you have a look at the scrum guide from scrum.org. what the guide says is that the sprint should be NO LONGER than 30 days. While 2 weeks is the usually recommended size, extraordinary circumstances may require that it extends UP TO 30 days. Commented Apr 13, 2014 at 23:14
  • Thanks for pointing that out, @JorgeCarvalho. I went ahead and included a quote from the Scrum Guide.
    – jmort253
    Commented Apr 14, 2014 at 0:12

You can see good coverage on your specific question, but how is you 4/5 week length working for your team, client, system?

Have you tried other lengths? Did they deliver better results, was it easier to plan, deliver value, was the team happier?

How is your overall implementation of agile going? Is the 4/5 week time box helping you adopt the other part of the agile/scrum receipt for software development?

Have you stopped improving? Where did you start with your sprint length? Are you and your team actively managing the duration down like Ken Clyne talked about?

Based on those answers, I would say that you need to actively manage it yourself and skip the rules of thumb.

  • 1
    +1 First sprint at a new company; actively managing the sprint length seems a good tactic.
    – amelvin
    Commented May 3, 2011 at 22:29

In one of my projects which last 60 weeks (similar to yours) my team has worked in 4-week sprint and it has been going well.

However, to answer your question: There is NO rule of thumb on reasonable number of sprints. I have been managing many projects, currently 5 projects at the same time. Some of them last for less than 10 sprints, some last 10-30 sprints, and some particularly long projects take > 50 sprints. And each project can have different sprint length (1, 2 and 3 week).

In Agile group where I participate, many teams choose 30-day period, while many teams choose 2 weeks and 3 week.

So how do I determine the sprint length? The decision is made after considering: Estimated length of project, nature of product, nature of your team.

1) Estimated length of project.

The estimation needs not to be precise 100% to give you a sense of how long the project will last. If it last more than 6 months, it makes sense to consider 3-week length or 30-day length.

2) Nature of product.

You need to ask yourself:

  • Does this product need to adapt frequently to market/real users’ need to make value for stakeholders? If it does, you should shorten the sprint length and give more frequent workable version to get public’s feedback.
  • Technically, is it possible to deliver product in short iteration? As you know, short iteration is encouraged, but you cannot do it 100% of the time due to technical difficulties. In some project we need to implement complex algorithm for example, before showing it to stakeholders.

3) Nature of your team

Does your team work most efficiently in 1-week sprints, or in 30-day sprints? If you have worked with the team on several 2-week sprint and you feel that they work well, why not consider it?

You may have the temptation to try 1-week sprint, but keep in mind that the actual work of coding is reduced, due to the (almost) same amount of effort spent on Agile (meetings, communication, etc..).

In my current projects, for maintenance projects we often choose 1-week sprint and for others, we are working efficiently in 3-week sprints, and 4-week sprints, for to share personal experience.


I think it depends on the project -- I managed project with 1 week sprints and 3 month sprints, so it really depends on what are the goals. I also believe that setting the realistic goals is most important.


Shorter Sprints generally Trump longer Sprints.

From a much longer blog post Shorter Trumps Longer


  • Since the team has more but shorter retrospectives they have more opportunities to try smaller changes. This also provides more opportunities to learn.
  • More frequent Sprint Reviews give the Product Owner more feedback and more frequent opportunities to change. This should largely eliminate the need for the Product Owner to ever ask for a change (i.e. new Story) in the current Sprint.
  • Impediments and Slowdowns are highlighted more quickly, since the team is expected to get the feature(s) to done by the end of every Sprint. This forces the team to come to terms with things that are slowing them down.
  • Shorter cycles make planning easier, which increases focus and reduces the amount of “dark work”. Forces teams to do a better of job of slicing Stories or Features into smaller chunks. This increases visibility and gives the Product Owner better control over prioritization and deprioritization.


  • It’s harder to get to a finished product at the end of one or two week cycle. Caveat this is true at first however most teams are able to get the hang of it after three to four Sprints.
  • Working in one week Sprints can be more stressful at first.
  • Overhead – people say that the Sprint Meetings are too much overhead for a one week Sprint. However sprint meetings scale linearly with the length of a Sprint. So a one week Sprint will have 2hrs of Sprint Planning, a two week Sprint have 4hrs and so on.

Today most teams I encounter pick two weeks Sprints. Some go as short as a week.


I think a good sprint should be around 4 weeks. so basically equal to an iteration. An iteration does not necessarily have to be a production grade release, but should at least be an internal release for testing. Each sprint should aim at completing several user stories ready for testing


The developers on the team should decide what works best for them. It may be that short sprints work best at the start, then longer sprints in the middle, then shorter sprints at the end. Or vice versa. Or all the same size, at 4 weeks. Or maybe 4 weeks turns out to be too long for the empirical approach that is Scrum, so the developer team may decide to cut it back to 3 weeks.

Fortunately for the PM, the length of the sprint is not the PM's concern. Assuming the PM is the product owner, and not one of the developer team members.



A few thoughts about what you shared with us. I understand you must adapt the framework to the specific circumstances of your company, but here are a few things I would personally advise against.

Why the 5th week pause? One of the goals of scrum is to maintain a sustainable pace. If you need a break every 4 weeks that suggests to me that you might be overworking the team the other 4. Will you be able to sustain that for 14 months?

Deployment tasks should be included in the sprint. or even better, As much as possible aim for deployment automation. they should not be the excuse for the off week either.

The need for bug fixes raises the question of quality control. How are you ensuring quality in your sprints? How has your definition of done evolved? Having a bug fix week leads the development team to cut corners and reduce the quality. It feeds the line of thought that problems "can be dealt with it during the bug fix week". And before you know it, items you thought were done, keep coming back for fix after fix. A healthy DoD is crucial for transparency and transparency is key for project success. My advise is to be strict with your definition of done and push the team to make it grow on every retrospective. Non-Functional requirements are great candidates for Definition of Done check points.

The last activity you seem to bundle into your off week is estimating and PB grooming. You don't need to have the entire backlog estimated and prioritized but you should have 2 to 3 sprints worth of stories ready to go at all time. To do this, the product owner should be regularly checking the priorities and the team needs to set time aside during the sprint for a poker planning session or whatever estimation approach you use.

Have a read through the scrum guide from scrum.org, and I would suggest getting the whole team going through some formal Scrum training from either .org or from the Alliance. Most decisions need to be made by the team. E.G. Sprint duration should be determined by the Scrum team. It's always better when everyone understands the basic guidance and the reasoning behind it.

Good luck for your project


I'm more on the development side, and I just wanted to chime in here.

One common mistake I see PMs make, is to try to lock blocks of work into a regular schedule, rather than scheduling the block of work.

For instance, consider a situation with 6 planed blocks:

  • Feature A (1w 3d)
  • Improvement B (4d)
  • Feature C (1w 1d)
  • Approved BugFixes (3d)
  • Refactor 5 (2w 4d)
  • Error Handling Improvements (2d)

Attempting to chunk these into 2 week sprints will force ordering them in a way which will create more work for your dev team, and break up some blocks into multiple sprints. This is exactly what agile is supposed to avoid.

Instead, consider planning the blocks that need doing, how much time each will take, and the logical order they should be delivered. Then make each block its own sprint, and schedule them. Let there be a 2-day sprint for Error handling. Let there be a 3 week sprint for the refactor. Project Management and scheduling should manage the project, not drive it.

  • Having the team work in 2 week sprints can create some additional work for the dev team. But this is done for very specific reasons; that is to allow regular opportunities to inject changes into the work and to regularly demonstrate progress. Remember that Agile is all about responding to change. It is not about creating the most efficient development path. This is why Agile is a fundamentally different approach to development than the traditional approach. Commented Jul 30, 2016 at 8:51
  • 1
    @BarnabyGolden, the purpose of agile is to break a larger project into iterative development via stories. However, stores shouldn't be broken apart just so that all sprints can be the same size block of time. By taking such an approach, management processes often return to being top-down rather than agile. At least that's been my experience. Commented Aug 2, 2016 at 0:49
  • This is actually a good approach and mirrors typical project management practices. You cannot always know how long some of these tasks will take so instead of feeling bad because you didn't deliver everything at the end of a sprint, you have a buffer of a time that can be used to make sure the feature is delivered, though it took longer than the original 1 sprint deadline.
    – user27307
    Commented Apr 5, 2017 at 18:37

This is a tradeoff. If the sprint duration is extremely small, there are higher overheads such as # of retrospectives, demos etc. So the transaction costs are high. If the sprint duration is too long, then the completed features reaching in the hands of customers takes longer resulting in delayed revenue. i.e. Higher Holding Costs. Your optimum Sprint duration is when your transaction and Holding costs meet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.