What's the right sprint length for your team?

From the Easy in theory, difficult in practice Blog
by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

Progress is the secret sauce of motivation...

Personal development action planning starts with the "What?" and "Why?" before the "How?"

I, for one, welcome our new PM AI overlords

The importance of radical candor for delivery teams

What are some of the underlying causes of ineffective project risk management?


Categories: Agile, Risk Management


The Scrum Guide calls sprints the "heart of Scrum" and also indicates that they should be one month or less. The Guide also cautions about setting sprint durations longer than a calendar month to ensure that inspection and adaption is happening frequently which will reduce the risk of wasted team effort or of building the wrong product. This aligns with the third principle from the Agile Manifesto which encourages teams to deliver value frequently, from a couple of weeks to a couple of months.

A research survey conducted by Scott Ambler+Associates found that the most common duration used by teams following a sprint-based delivery model is two weeks, but how should a team decide what is the optimal sprint length for them?

Their decision should consider a number of factors including:

  • How "new" the team is
  • Their delivery process
  • Constraints on their being able to complete product backlog items
  • The maturity or capability of the team to disaggregate work items to a small enough size so that they can complete multiple items in a sprint
  • Expectations from the stakeholders who will participate in sprint reviews

For teams which have just formed or are working with technologies or a product which is new to them, too short a sprint duration may prevent them from being able to complete anything meaningful. This could cause them to get discouraged and might frustrate the stakeholders who are expecting to see progress every sprint. On the other hand, if the team is new to flow-based delivery approaches and they start with a long sprint duration, they could revert to traditional behaviors where they complete batches of work items in phases over the life of the sprint.

When in doubt, it is usually better for a team to choose a shorter sprint duration as this should encourage them to identify, elevate and eliminate the real constraints which limit their ability to deliver. With the longer duration, while they might be aware of the constraints, their sense of urgency may be less.

The team should not change sprint lengths on an ad hoc basis, but if they have identified triggers which suggest that they need to increase or decrease duration then such changes might be done after a major product release. Improvements in the team's productivity or a high degree of volatility in the product backlog are two possible triggers. Another example is if the stakeholders attending sprint reviews consistently feel overwhelmed with the content of the product increment being demonstrated to them.

Sprint duration is another case of Goldilocks and the three bears - finding out what's "just right" will take some trial and error!

Posted on: May 05, 2019 07:00 AM | Permalink

Comments (8)

Please login or join to subscribe to this item
One of the factors to consider is whether or not you have automated testing. Automated testing was not available for my last agile team, which resulted in spending about one week of a four week sprint on testing. We also had to factor in a couple of days for the apple store to review the release. As long as the UX team had the designs ready by the start of the sprint, the developers could expect a solid three weeks of development.

I guess my point is that you need to understand your processes, constraints, and dependencies to determine an initial sprint length, and then eliminate the waste so you can improve your processes and deliver value more quickly. In my opinion, an important part of agile is learning, adapting, and improving over time (quickly whenever possible).

Very interesting thanks for sharing

Thanks Aaron - totally agree. Delivery approach and constraints to deliver will definitely affect what the optimal length is.

Thanks Eduin!

A potentially shippable increment with a value attached to it can also help in deciding the length of the Sprint in which a workable solution can be delivered. Very interesting blog with strong factors for deciding the Sprint length. Thanks for sharing it Kiron.

Sprint duration is constrained by two opposing factors:
1. Faster delivery: Team stays focused if sprint duration is small (2 weeks) and daily progress is tracked at much more serious level. Also risks and variances can be identified earlier by stakeholders.
2. Finished functionality: Smaller sprint duration means the changes might not be finished and functionality being developed might have no business value.

But agile is all about handling change and risk in each sprint. So trade-off should usually be to lower sprint duration as much as possible. Else it might revert to a waterfall model.

Thanks for sharing.

Good one, Kiron and thanks for sharing.

Please Login/Register to leave a comment.

ADVERTISEMENTS

Vote early and vote often.

- Al Capone

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events