21 Tips on Choosing a Sprint Length

Many teams that I work with choose their Sprint length without too much thought.  Often enough, that’s okay and it works out.  But, in some cases, it helps to think clearly and deeply about what length of Sprint to choose.  Here are 21 tips on choosing a Sprint length.

  1. Don’t ever go longer than 4 weeks… if you do, by definition it’s not a Sprint anymore.
  2. Scrum is about fast feedback – shorter Sprints mean faster feedback.
  3. Scrum is about continuous improvement – shorter Sprints give a team more opportunities to improve.
  4. High-performance teams need pressure to form – shorter Sprints provide pressure.
  5. Each Sprint is, ideally, an independent project – longer Sprints may make it easier to get a potentially shippable product increment truly done every Sprint.
  6. “False” Sprints such as “Sprint 0” or “Release Sprints” may feel necessary if your Sprint length is too short – try to avoid the need for false Sprints.
  7. If you have lots of interruptions that are disrupting your Sprint plans, shorten your Sprints to match the average frequency of interruptions… and then just put them on the backlog.
  8. If you feel like you team starts out by working at a leisurely pace at the start of a Sprint and then “cramming” at the end of the Sprint, then shorter Sprints will force the team to work at a more even pace.
  9. Don’t lengthen your Sprint to fit the “size” of your Product Backlog Items… instead, get better at doing “splitting” to make the items smaller.
  10. Small failures are better than large failures, shorter Sprints help.
  11. If you are using Agile Engineering practices such as TDD, you should probably be able to do Sprints that are 1 week in length or less.
  12. 2-Week-long Sprints are most common for IT and software product development.
  13. Most Scrum trainers and coaches recommend Sprints to be 1 or 2 weeks long.
  14. Teams go through the stages of team development (forming, storming, norming and performing) in fewer Sprints if the Sprints are shorter.  E.g. 5 Sprints if they’re 1 week long, but 20 Sprints if they’re 4 weeks long.
  15. If your team has trouble finishing all the work they plan for a Sprint, make the Sprint shorter.
  16. Every Sprint should be the same length for a given team so don’t let your Sprints get longer just to “get everything done”.
  17. Experiment with extremely short Sprints to see what is possible: 1-day long, for example.
  18. If you are doing a project with a fixed release date/end date, then make sure you have at least 6 Sprints to allow for sufficient feedback cycles.  More is generally better which means shorter Sprint lengths.
  19. If you are working on a product, consider Sprints that allow you to release minor updates more frequently than your main competitors.
  20. Sprints need to be long enough that Sprint Planning, Review and Retrospective can be meaningful.  A 1-day Sprint would allow a maximum of 24 minutes for Sprint Planning, 12 minutes for Review and Retrospective each.
  21. When a team is new, shorter Sprints help the team learn its capacity faster.

Author’s Note: this is one of those articles where I thought of the title first and then worked to make the article meet the promise of the title.  It was tough to think of 21 different ways to look at Sprint length.  If you have any suggestions for items to add, please let me know in the comments (and feel free to link to articles you have written on the topic). – Mishkin.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

9 thoughts on “21 Tips on Choosing a Sprint Length”

  1. Thanks for the post! Can you please clarify on Item 15, “If your team has trouble finishing all the work they plan for a Sprint, make the Sprint shorter”?

    1. This is actually quite simple: if a team is having trouble finishing its work, it is often because the team cannot predict the future. This is natural and is often a consequence of the “Horizon of Predictability“. Doing a shorter Sprint allows the team to have a greater level of certainty about their work and improves the chances that they will predict / forecast / estimate accurately.

  2. Hi ,
    Can any one help me for solving the below questions , as i am new to agile and learning.

    I) Your Product Owner has not been available lately. Your VP says “Hey Scrum Master , I need PO for some other project, why don’t you continue to run the show?”. What would be your reaction?
    II) Why do you need Sprints? How do you decide Sprint length?

    III) You are just about start your first Sprint and during the Sprint planning, your development team says “Hey PO, we need about 3 sprints to build initial framework and then only we can focus on customer features”. PO agrees. What would be your reaction and why?

    IV) Your PO says “Guys I got the estimate from the team I used to work with before. Now please deliver these in 10 sprints as I believe 1 Story point = 1 hour and we have so many hours”. How do you handle this situation?


    1. Satya,

      Great questions. I think this article actually answers part of your question II. The other questions are quite detailed. Here are some quick thoughts:
      I) My reaction to this would be: “I’m not the PO and it is a conflict of interest for me to be both the SM and PO. Please let me know which one you would like me to do and I will do it to the best of my abilities. Since I am the ScrumMaster right now, the best of my abilities means that I am informing you that I cannot also be the PO.”
      II) We need Sprints to create cadence and synchronization within the Scrum team. This, in turn, creates systematic and reliable opportunities for feedback and improvement.
      III) Fire my PO. I PO should _never_ accept such an excuse from the team.
      IV) Send the PO to CSPO training 🙂 You can find our training here: http://www.worldmindware.com/. The use of Agile estimation techniques and the principles behind Agile estimation can be found in other spots on this blog. For example, here is a list of articles tagged with “estimation”.

  3. Nice list!

    We are currently on a 2-week schedule. I’m wondering if it is better to expand to 3-week schedules. Our DoD is to develop, to do a systemtest and to do an acceptance test(done by Business Units).

    Although I agree on the facts above, it’s quite problematic to have 2 week schedules at the company I work at;
    – The DoR (Definition of Ready) is not met. But under pressure of CEO/Projectmanagers, we MUST start building.
    – Implementing from Development to Test, Acceptance takes almost 4 days.

    So basically we have one week to develop under uncertain conditions. Almost every sprint this leads to goals not being met.

    Any advice on this?
    Thanks in advance,

    1. R. Thanks for your comment. My advice is almost always to have shorter Sprints not longer ones. The idea is that the Sprint length is a way of putting pressure on the organization to improve processes, skills, tools, etc. to enable faster delivery. Short Sprints are one of the main reasons organizations start adopting DevOps and automated testing – both of which are very good! The “Definition of Ready” is also not a very good way to fix this; it simply pushes the problem to other people outside the Sprint. Instead, the organization should work to encourage cross-functional Scrum teams with no dependencies outside the team. This is tough. So… if you don’t have support to get better at product development, then perhaps 3 week Sprints will be a way to have a better life 🙂

  4. Suggest #14 should read (asterisks around edits): “Teams go through the stages of team development (forming, storming, norming and performing) in *less time* if the Sprints are shorter. E.g. 5 *weeks* if they’re 1 week long, but 20 *weeks* if they’re 4 weeks long.”

    1. Hi “JonERotn” – the wording is deliberate; the longer the Sprint, the more Sprints it takes for the team to go through the stages of development. Shorter Sprints put pressure on the team to gel faster. Longer Sprints allow teams to be more relaxed about their team dynamics. Therefore, to convert the statement to weeks, I would write: E.g. 5 weeks if they’re 1 week long, but 80 weeks if they’re 4 weeks long (4 weeks/Sprint x 20 Sprints).

Leave a Reply

Your email address will not be published. Required fields are marked *