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)

Consequences

• 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

• Shades of Scrum: Product Owners and a Product Owner Shaped Object
• Definition of Ready: a double edged sword