Ideal Iteration Length, Sprint Length, How Long should be a Sprint or Iteration

New teams struggling with Scrum or Agile adoption more than often struggle with their Sprint or Iteration Length. [Whether or not a Sprint or Iteration is a good thing or needed for Agility is a debatable topic in itself though]. Most of the teams pick up iterations or sprints month or even two months long. Then their idea of Iteration is moulded in Waterfall Phases [this is a Design Sprint, this is a Coding Sprint, this is a QA sprint and this is a Release Sprint] – this is for another day. When deciding on the length of a sprint or iteration, many factors need to be considered:

  • Administrative Overhead : Each iteration needs a planning meeting/ game to kick start the iteration. Each iteration would also need a closing/ review meeting. And there will also be a retrospective at the end of iteration. Although one can say that the size of these meetings [minutes consumed] would depend on the length of sprint, so as long as these meetings comprise say just 10% [you can come up with your number] of overall time available for a sprint/ iteration, it should be fine. I personally think this reasoning is fine. If meetings are taking longer, then there are generally Process Smells – Product Owners who have not done their homework correctly or have not had the chance to review the deliverables properly.
  • Feedback/ Flexibility : Shorter the duration of the sprint/ iteration, earlier the feedback and correction and more flexibility, longer the duration of the sprint/ iteration, longer the correction – more chances of canceling the sprint and more chances of things being obsolete [competitive advantage erosion].
  • How good is the marketing team : If the marketing team is good [Product Owner is good], then he/ she will break the stories or tasks small enough to keep sprint/ iteration length small. He/ she would know the worth and priority for each story or task and help the team pick up most important stuff – minimizing stuff thats not needed – helping the team become Agile.
  • How Fast can the team move : This is generally the most important factor in deciding a sprint length. Assuming the team has a good marketing leadership, one reason the team does not commit to a smaller iteration is lack of confidence in themselves. If they had confidence in themselves [they were doing refactoring, TDD, shared code or just were good group of people together].
There was a certain slant for a smaller iteration length in the post. This is because:
  • Short sprints make certain bad habits impossible to get away with and certain good habits more attractive to learn.
  • Shorter sprints or iterations are difficult for product management team but also most desirable as they can make changes quickly.
  • Shorter sprints or iterations force continuous evaluation regularly and quickly.
  • Shorter sprints or iterations also allows the team to establish
    an empirical velocity very quickly.
Some people and trainers say that when teams are new to Agile/ Scrum, they could start with 2 week sprint. I generally advise against this. I would rather have them do 1 week sprints with lesser stories – allows them to learn quicker and faster. However, important point to note is that each team is unique and each product is unique as well – hence, there might be cases for 2 weeks as well as 2 months sprints. I haven’t come across any so far though.
About these ads

20 Responses to “Ideal Iteration Length, Sprint Length, How Long should be a Sprint or Iteration”

  1. I would add a couple points to this.

    It’s important to understand the technology your company is using. For example, when we were working on agilebuddy, because we were working with Ruby on Rails, we coiuld achieve meaningful deliverables in very short period of time (Rails is a really Rapid application development environment). So we opted for a 2 Week sprint. However, I recently completed a consulting gig at a company that designs and develops high end ultra-sound equipment. They have mechanical, hardware, embedded software, firmware and “regular” software. The complexities with their environment meant that they needed a minimum of 3 weeks of pure development to get meaningful work done. So in their case we opted for 6 week Sprint length in order to get work totally completed (Code, Unit Tests, QA etc) in a single sprint

    As a general rule, the higher the risk, the shorter you should make the sprint so that you can control the project more effectively and not let the project get too far off track.

    But I would definitely ask the question of your development team as to the minimum amount of time to get meaningful work done in your environment. This will help you with your decision.

    Two more comments,

    Go with monday to friday cycles that way you’re always planning on a monday and doing a retrospective on a friday. That helps with the rythm n the company.

    2 weeks sprints if you can manage also sets up a really nice heartbeat in the company which helps to build trust between the business and development teams.


    • Hi Jack:

      Thanks for stopping by.

      I think you make interesting and valid points. How fast a team can move is something only the team and product owner can together decide. Sometimes, how right the team moves is also dependent on how fast it moves.


      Vikrama Dhiman

  2. Actually, in my opinion noone can decide how fast a team can move. I always say “it is what it is”. What’s cool about agile is you get to measure what a teams velocity and hence what it’s throughput really is. That’s the measurement of how fast a team can go.

  3. I think you can decide if the team is moving fast or not but not “is it moving fast enough”. What can enable finding this out is a frank open environment for discussion between product owner/ manager and the team and having product manager/ owner sit with the team always.

  4. vikashazrati Says:

    Is there a connection between a word to word post on

    I was planning to quote this post in my weekly post on infoq and I think that I am going to quote this one based on the earlier date

  5. Hi Vikas:

    Someone has been copying multiple posts from my blog ditto. Don’t know what to do about it.


    Vikrama Dhiman

  6. We run one we sprints at my company and as you stated it definitely stresses the systems in place. We know very quickly if something is not right and can address it. It has caused the “underestimated” argument to come up a few times, but usually we find it is an over commitment issue. We don’t adjust the size of our sprints to accommodate not hitting our commitment, but we do lower the committed velocity to a more realistic and accurate number after about the 2nd or 3rd iteration.

  7. Hi Pariuri:

    Are you still continuing with the practice of fixed length iterations? Have you felt the need for doing away with iterations?


    Vikrama Dhiman

  8. ClearWorks New Version – 2.4 Released

    Many our customers asking us about enhancements, and we are doing our best to provide requested features and functionality.
    Today’s release is a big update of current Sevenuc best seller product (also known as agile lifecycle tool for hardware & software project)
    and at the same time composition with other software configuration management tools,
    and more automation test tools and build servers.

    Update contains more elements for Lean R&D real-time collaboration platform
    and reflects latest innovations in Lean Kanban created by Sevenuc and other platform vendors.

    What’s New in 2.4

    * Workflow define for deferent project with Lean stage management.
    * Event and status driven mechanism by Triggers.
    * Email classfication for effective customer request life-cycle management.
    * Complete release support for Lean agile project.
    * Lean R&D behavior improvements for all type of statistic charts.

    read more

  9. Other relevant information you can find from

    Beck, Kent; et al. (2001). “Principles behind the Agile Manifesto”. Agile Alliance. Retrieved 2010-06-06.

  10. Excellent post! … for me, running is a healthy way of life!

    and I feel great..

  11. It is good that i find this article. I learn something from it.

  12. [...] New teams struggling with Scrum or Agile adoption more than often struggle with their Sprint or Iteration Length. [Whether or not a Sprint or Iteration is a good thing or needed for Agility is a debatable topic in itself though]. Most of the teams pick up iterations or sprints month or even two months long. Then their idea of Iteration is moulded in Waterfall Phases [this is a Design Sprint, this is a Coding Sprint, this is a QA sprint and this i … Read More [...]

  13. [...] product release scheduling or iteration length, two commonly citied reasons for shorter cycles are increased accountability of the team and more timely feedback from external stakeholders. I would add that shorter iterations force a [...]

  14. Top quality Supervision…

    [...]Ideal Iteration Length, Sprint Length, How Long should be a Sprint or Iteration « Agile Diary, Agile Introduction, Agile Implementation[...]…

  15. I participated in some sprints, and I went a little wrinkled. is quite difficult to deal such a competition. Besides effort, comes disappointment that you did not finish in first place. and only 50 in 1000.

  16. I’ve been saerching for this for a long time,, thank you for this piece of information.

  17. Thank you very much for this valuable piece of informaton. I’ve been searching this for a long time and now I’ve founded on this great site! I appreciate, thank you again.

    cuptor electric

  18. I’m glad you did this post Kevin…it’s a good topic! I simply want to add a little flavor. First, I need to disagree with your point that immature teams need longer iterations and more experienced teams can then move to shorter. My experience is just the opposite and I’ve heard this from quite a few Scrum / Agile coaches. The key point is that it takes quite a bit of experience to plan a 4 week sprint that truly hangs together for 4 whole weeks. Immature teams usually struggle with this length. Give them only 2 weeks to plan and their collaborative planning & tasking for the sprint becomes much easier. If a 2 week sprint team is struggling with planning, I’ve often reduced them to a single week–so that their planning chops improve, and then move them to 2 week sprints. So you might want to re-think that position at You didn’t mention it, but I think there’s a *cost* to your iteration length selection too. Think of S-Curves as representing cumulative work over the life of a sprint. In the beginning, the team is slow to accelerate while they’re starting on new work, so it may take them a day or two to really begin producing. Similarly, the end of the sprint has a flattening as well. Again, I’ve seen it be one to two days, as the team polishes off work, prepares for the sprint review and gets all of the working software “working”. Between those two points is *acceleration*. So the shorter your sprint length, the more you repeat your S-Curve patterns, the more you incur some start/stop waste. In my overall experience, mature teams are most productive with a 3 week sprint length. Thanks for the contribution to our community!

  19. [...] Ideal Iteration Length, Sprint Length, How Long should be a Sprint or Iteration [...]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: