As per title, who is in charge of the decision?

I am tempted to say that the dev team should chose it, but then again there are considerations about stakeholders to be made and management in general (how long can they go without changing their mind, how dynamic is the market etc.)

Therefore I would say the PO should also have a role in deciding how long the sprint should last.

What do you think?

3 Answers 3


The Scrum team decides the length of the Sprint (dev team + PO + SM). They do the actual work, so they choose the duration of the time-box they feel more comfortable with in order to produce a product increment.

With that being said, there are of course all sorts of other things happening in the company that may influence what decision the Scrum team makes. You mention some of them in your question. If that happens, the team can always change the sprint duration. You don't need to keep the same length all throughout the project. You start with whatever works for you, then inspect and adapt.

Maybe you start with two weeks but stakeholders might want to have a shorter feedback loop, so you switch to one week sprints. Or maybe you work in some complex domain and the PO might want to have more "meaty" increments, so maybe they suggest three week or four week sprints. But then maybe you see that a greater iteration length introduces too much risks or assumptions, so you go back to something shorter.

It's a good idea to retain a constant sprint length throughout the development of your product (helps with planning, forecasting, etc), but if you realize that a different length would be more beneficial (for whatever reasons) you can switch. You are not stuck with one sprint length forever.

  • Should be the sprint length, start and end point sync over the whole dev department? Or team by team? I worked often in a synced environment, and so the decision was done by "management" and not by team. All teams were able to discuss it during the retros.
    – KargWare
    Aug 31, 2020 at 10:55
  • @KargWare: if teams work on the same product, it's easier if they choose to have the sprints start and end at the same time. It helps with plannings, communication, coordination, releases, etc. If different teams work on different products, they should choose watever sprint length they see fit, independent of the other teams. There will of course be various things that influence what the sprint length is, as I mentioned already in the answer.
    – Bogdan
    Sep 1, 2020 at 15:53

The Scrum Team Decides, Based on Framework & Project Requirements

The entire Scrum Team collectively decides the optimum length for their Sprints. No one outside the Scrum Team should be defining the Sprint length, although they may certainly have an impact on defining success metrics that influence the team's decisions.

Deciding on an optimal Sprint length rests on a number of factors:

  1. Framework requirements.

    The Scrum Guide says that a Sprint may not be longer than one calendar month. That's the upper bound. The lower bound is selectable, and will depend on other factors.

  2. Typical size of Product Backlog Items (e.g. user stories).

    Each item that is ready for Sprint Planning must be sized to fit within a single Sprint. Smaller stories are more agile, but smaller stories may not accomplish as much. It's usually best to right-size the story size to fit the Sprint and optimize for INVEST criteria.

  3. Backlog item complexity.

    While complex work can benefit from shorter inspect-and-adapt cycles, it's also true that some complex work simply won't fit into very small time boxes. You need to right-size your story size and Sprint length to accommodate the optimum level of decomposability, interdependencies, and delivery time to meet your typical Sprint Goal each Sprint.

  4. Sustainable cadence.

    The Scrum implementation (especially the cadence of its events) should be predictable for the team and its customers/stakehodlers. The cadence must also be sustainable for the full life of the project. It's important to pick a Sprint length that will work indefinitely and that won't require constant rejiggering to meet changing requirements.

  5. Stakeholder availability.

    One-week Sprints place a lot of demands on stakeholders to feed the Product Backlog and attend Sprint Reviews. The Scrum Team members are also stakeholders, and very short iterations don't allow much flexibility for sick days, family emergencies, or organizational demands outside of the product development cycle.

  6. Optimum feedback cycles.

    Shorter Sprints provide more inspect-and-adapt opportunities in a given period of time. However, that comes at the cost of an increased frequency for Scrum events, and thus more framework overhead.

Generally speaking, shorter projects require shorter iterations because the project needs faster inspect-and-adapt cycles. For example, a three-month project with only three Sprints is unlikely to provide sufficient empirical control or process-improvement opportunities.

On the other hand, shorter iterations create more process overhead and reduce the amount of work that can be accepted into each Sprint. It's very much a trade-off, and the whole team needs to weight the pros and cons based on the product schedule and complexity.


Decide such major changes by consensus

Industry practice is 2 week long sprints. However, you can change it by consensus. Sprint Retrospective is an opportunity to inspect and adapt. It is meant to bring up issues faced by the team and look for ways to improve.

However, here are some key points to keep in mind regarding sprint length:

  • Scrum Guide recommends a maximum of one month for a reason. If you make it longer than that, you may get frequent disruptions by way of requirements churn. Also, opportunities for inspect and adapt are less frequent.
  • If you make it too short, development team may struggle to complete a shippable increment and quality will suffer. Also, it may be difficult to break-up some stories to fit within a short sprint.

Most importantly, when you change the sprint length, team rhythm will be impacted and you will have to develop new metrics all over again. So, change if there are overwhelming reasons and there is team consensus.

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.