Stefan Roock

All About Agile and Lean

Shades of Scrum: Sprint length

The Sprint length in Scrum is 30 days or less. Most teams work with 2 or 3 week Sprints and the most common recommendation for the Sprint length seems to be 2 weeks. 30 day Sprints seem to be very rare.

The general thinking here is that shorter Sprints lead to more frequent inspect&adapt regarding the product (Sprint Review) and the process (Sprint Retrospective). When a team is capable of doing 3 week Sprints it should therefore try to work with 2 week Sprints and then 1 week Sprints.

But I think there is missing an important aspect: When the team is capable of delivering within a certain Sprint length there are actually two possibilities for further improvement:

  1. Shorten the Sprint length to reduce feedback cycles and allow more frequent inspect&adapt.
  2. Deepen the teams capability by reducing the Definition of Ready (start the Sprint with a less formal specification) or increasing the Definition of Done (e.g. by including live deployment).

Which direction to take is – of course – dependent on the specific context.

Shorten the Sprint length is valuable if

  1. the Product Owner is actually able to react that fast to feedback about the product
  2. the team is able to create and implement process improvements that fast

Deepen the teams capabilities by reducing the Definition of Ready is valuable if

  1. cross-functional work seems valuable not only for the implementation but also for the definition of the „what“ (remember the benefits of cross-functional work: more creativity, higher quality)
  2. the Product Owner is overloaded (e.g. he is a Jeff type of Product Owner but is forced to work like a Walter or Marty)

Deepen the teams capabilities by increasing the Definition of Done is valuable if

  1. the product increment isn’t really shippable until now (e.g. integration tests are missing; the demo is done in a branch)
  2. there are often problems in the downstream processes (e.g. operations has problems with deploying the product increment into production)


  • When your team becomes more capable you should discuss if you want to shorten the Sprint length or deepen the capabilities of the team.
  • When your team is capable of doing the current Sprint length but not a shorter one, you should discuss if it would be valuable to extend the Sprint length and deepen the capabilities of the team.

Related Posts

Published by

8 Antworten zu „Shades of Scrum: Sprint length”.

  1. Hi Stefan,

    it is unusual for me to *think* in Sprints. But when I commit to doing so, in fact, the deeper the process is integrated, then there may be a good reason for a longer sprint length, to not disrupt the value chain during important features. We currently see a lot of discussion on integrating UX snuggly into the delivery chain. I think that is – in parts – due to the issue that UX is defying the sprint concept … it just takes time. No matter how lean you do it.

    But there again you see both sides of the medal: Just extending the sprint length may be a great thing for advanced teams. For Shu teams it might be the sign to not take waste out of the ‚process‘.

    Interesting thought anyway!



  2. The counter point of Sprint length, is two weeks sprint encourage the PO to only look at results at the end. a longer sprint forces the PO to engage and sign off during the Sprint.

    Also, 4 week sprints give you a true business lump of function. a 2 week sprint will give you business functionality, but is it truly useful? I have seen in quite a few organisations, 2 week sprints, but then 3-4 sprint releases. They launch to market every 8-12 weeks. Surely launching every 4 weeks would be a better approach? You are also more likely to get stakeholder feedback (USEFUL stakeholder feedback) on a slightly longer cadence. Too many people do not use the Sprint Review to empirically steer the product.

    I think people go far too quickly to the „2 week“ sprint length. The variability is now there to assist with other options.

    P.S. The last survey I saw on sprint length said that 3 weeks was the most common.

    P.P.S. I hate 1 week sprints except in highly exceptional circumstances. They are not sustainable pace.

  3. Very good observation, IMO.

  4. Avatar von Matthias Hochschulz
    Matthias Hochschulz

    Great article, but I was awaiting your opinion on increasing the sprint length.

  5. @Matthias: I think it depends on the context. When innovation is needed I would prefer longer Sprints with a wider responsibility of the team, especially for upstream activities like UX and definition the User Stories.

  6. […] Shades of Scrum: Sprint length – the article describes some advantages of longer Sprint lengths (which may be the result of folding a pipeline into Sprints) […]

  7. […] Sprint length: The article compares shorter and longer Sprint lengths and shows that longer Sprint lengths have their value – not only for beginners. […]

  8. […] Die Sprints in den Fallbeispielen sind relativ lang (eher Monatssprint als 2-Wochen-Sprints). Das harmoniert meiner Meinung nach sehr gut mit der Besetzung der Product Owner-Rolle durch Top-Manager. Auch über die Sprint-Länge habe ich an anderer Stelle gebloggt. […]

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

Du kommentierst mit deinem Abmelden /  Ändern )


Du kommentierst mit deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

%d Bloggern gefällt das: