What is the rationale for scrum teams implementing short sprints

artificats events roles Scrum sprint

Need a fast answer for the question, "What is the rationale for scrum teams implementing short sprints?" here you go...

The rationale for scrum teams implementing short sprints is to get more feedback and limit schedule risk.

Shorter sprints mean your teams get Sprint Reviews more often, which, is valuable because Sprint Reviews are when customers give you feedback on your product.  

The schedule is de-risked because you are less likely to build the wrong thing.  With more feedback you can be sure your effort is valuable.  

Level up your agile and get professional training.

Scrum Master Certification

The one big thing

Picking the right length of time for your sprints is very important because you will live with that decision for a long time.  You keep a constant sprint length from sprint to sprint.

Do you know what else is important?  Becoming a Scrum Master, checkout our post on that topic, how to become a Scrum Master and don't forget to check out how to certify your entire team as scrum masters

When in doubt, just go with one-week sprints.

The full story

If you want to know why teams choose short sprints, keep reading this post.  

    You may also be curious what is the rationale for scrum or what is the recommended length of an iteration

    Why do teams use short sprints?

    OK, ready to start?

    Why shorter sprints are better for development teams

    Let's learn why the professionals prefer (and recommend) shorter sprints for your Scrum team.

    In a nutshell, the rationale for scrum teams implementing short sprints is to get more feedback.  

    Here's a concrete example.  If you do one week sprints guess how often you get customer feedback?

    Once a week.

    If you do four-week sprints guess how often you get the same customer feedback?  Drumroll please...

    That's right, every four weeks.

    I don't know about you, but I'd like to hear from my customers more often.

    If you'd like to learn more about how to make the best use of your time with your customers I'd highly recommend the post, Triple R: a new technique to accelerate your progress (the images below are from their excellent post).

    Getting more customer feedback puts you on the "skateboard ramp" as shown by the CRE table below and keeps you off of the "cliff".  

    What that means is that more customer feedback ensures your project meets your customers expectations.

    An image showing why shorter sprints produce better outcomes

    Longer sprints are worse because you get less feedback, this graph shows how less feedback is bad for product development

    OK, let's learn more about how sprints fit into the Scrum framework.

    What is a sprint

    "Sprints are an integral part of agile development. They are one of the most important elements of the Scrum framework. A sprint is simply a set amount of time, typically between one and four weeks, during which a team works together to accomplish a set of goals."
    An agile sprint is a time-boxed (the time-box can be from one week to one month in length) iteration that delivers potentially releasable product. The time-box provides a clear and narrow focus for development, as well as a clear end-point for testing, in the form of a customer-ready product.
    The time-box allows for time-based development, and for the delivery of potentially shippable functionality.
    A sprint begins with a sprint planning event, which the Scrum team uses to identify and agree upon a set of functionality that will be developed during the sprint.
    The set of functionality will be implemented, integrated, tested and potentially released into production during the sprint. The team will also commit to some level of functionality that will be developed during the sprint.
    The sprint ends with a sprint review and retrospective, which is an opportunity for the Scrum team to inspect and adapt their work. The sprint review is held at the end of the sprint.

    Sprints and time

    A sprint in Scrum is a fixed duration of time in which the product owner and the development team work together to create a new or improved product. A sprint is typically between one week and one month.

    A sprint is a time-boxed period of time (usually one to four weeks) during which the Scrum Team collectively works on a set of tasks. 

    A sprint should be long enough to allow the team to complete the work, but short enough to avoid getting mired in details.

    The length of a sprint is typically one to four weeks. The Scrum Team decides how long each sprint will be, based on the amount of work that can be accomplished in that time.

    A sprint may be as short as one week. The length of a sprint is usually one to four weeks, but it can be longer or shorter when appropriate.

    he Scrum Team decides how long the sprint will be, based on the amount of work that can be accomplished in that time.

    Sprints and teams

    A team works inside of the Sprint.  This is a key concept.  

    The sprint is where all the work happens.  Said another way, the team does everything inside the sprint.

    The team owns the sprint backlog and therefore the team manages the sprint backlog.

    A team’s goal is to deliver value at the end of the sprint. The purpose of a sprint is to deliver marketable software.

    Based on my experience, I would recommend this approach to any size organization. Even if it's a large enterprise, teams of small and large sizes can follow this small team approach to creating working software that helps the organization run more efficiently and make more money. 

    Work and short sprints plus rationale for scrum teams

    Short sprints let you iterate more often. Iteration allows you to test, explore, learn more.  All this adds up to a powerful truth, shorter sprints let teams accelerate faster and learn more.

    Scrum lets teams learn and iterate making them more effective. Learn more about the rational for scrum teams.

    Here's how a team delivers work inside of a sprint,

    The project lead for a sprint describes the problem, vision, and solution.

    The team brainstorms solutions, the team chooses a specific set of possible solutions to deliver in the sprint, and then work on them. 

    By the end of the sprint each solution must be production-ready. 

    No further work starts until the team completes these solutions. Then we demo these briefly to demonstrate their viability, before closing the problems with no more work needed on them for now (a problem closed is a good feeling). We typically produce about two new solid working features per sprint. 

    Some teams repeat this process to get multiple features done per sprint, although we normally aim for 20% more than this in order to have time for fine-tuning and quality assurance before releasing a product or feature into production or development environments! 

    Many teams also start new projects mid-sprint. All work however must come from inside a single project's backlog as stuff can't move between projects mid-sprint.

    Each project gets one storyboard that shows all of its stories (deliverables). If that doesn't make sense be sure to check out how to implement Scrum.

    This allows everyone in that project to see how everything fits together into some form of overall vision creation.


    The key ingredient here is that while we focus only on delivering stories through iteration we try never to add anything else new unless it's part of another ticket that is already planned.

    Always focus on completion of tickets related directly to solving real user problems rather than other stuff considered important by people inside or outside our organization...even if related technically! 

    An iterative approach works best when we have a good relationship with our clients.  Communication is the key



    Sprints typically last between one and four weeks, and they include several key events, including:

    1. Sprint planning: A collaborative event in which the team decides what work will be completed during the sprint and how it will be accomplished.
    2. Daily scrum: A 15-minute time-boxed event in which the team meets to discuss progress, identify roadblocks, and plan for the day ahead.
    3. Sprint review: A collaborative event in which the team demonstrates the work that has been completed during the sprint and receives feedback from stakeholders.
    4. Sprint retrospective: A collaborative event in which the team reflects on the sprint and identifies opportunities for improvement. Each of these events is time-boxed, which means that they have a set duration and are designed to keep the team focused and on track.
    Note, you must understand velocity to understand Scrum.

      How to do development in a short sprint

      Now for the easy part.  Short sprints work great for development work.  Here are a few keys to being successful when you move to short sprints.

      • Short PRs
      • Clear product backlog items
      • Split the product backlog items at the dependencies
      • Don't change scope during the sprint

      Straightforward, right?


      In this blog post you learned that the rationale for scrum teams implementing short sprints is to get more customer feedback.  This has some really amazing benefits including

      • More agility
      • Better customer feedback
      • Align to market opportunities
      • Iterate products faster than your competitors

      Registered Scrum Trainer, Scrum Expert, and author

      Hey, I'm Jon the owner and writer here are goagileworks.  I'm a registered Scrum Trainer and a Registered Scrum at Scale trainer with over 20 years of leadership experience. I have certified hundreds of students as Scrum Masters from government, non-profit, the military, and many industrial sections. You can reach me by submitting a contact form through this site. I also write and publish at https://drink-mix-artist.com/ where I have fun helping people find great drinks and the best rum.


      Older Post Newer Post

      Leave a comment

      Please note, comments must be approved before they are published