{{announcement.body}}
{{announcement.title}}

How Long Should a Sprint Be?

DZone 's Guide to

How Long Should a Sprint Be?

If your sprints are lasting more than four weeks, you're doing it wrong.

· Agile Zone ·
Free Resource

Not too fast, not too slow

The key to winning the sprint is not going too slow or too fast.

While there isn't a one-size-fits-all sprint length that software development teams should universally adhere to, I think we can all agree that when it comes to sprints, somewhere in the neighborhood of two weeks is the sweet spot. And more than four weeks simply won't do. Here's why:

Small Batches

Since Scrum is an empirical process, the notion of small batch sizes (aka short sprints) is based on the Theory of Constraints, which says that a system is less limited in achieving its goals by a smaller number of constraints. In software, some of these constraints are backlog items (inventory), throughput (velocity), and ROI (customer value). 

When the batch size is small, you can get faster feedback and dynamically manage your risk.

Faster Feedback

In Scrum, there is always a trade off between the speed of the feedback and the size of the sprint. Every sprint has an administrative cost that goes along with the sprint planning, backlog selection, task breakdown, and daily Scrums. 

For many teams, the balance for this overhead versus working time is in having a two-week sprint. Longer than that, you are increasing your feedback cycle time. But shorter than that, there may not be enough time for the team to really get started.

Dynamic Risk Management

Another advantage of shorter sprints is that it gives you the opportunity to dynamically manage your risks. If the customer changes their requirements, the short cycles give you the opportunity to recalibrate every couple of weeks. If a competitor comes out with a product that changes your product’s value proposition, you get the opportunity to change direction sooner rather than later. 

This is very different than traditional project management, whereby there may be a risk mitigation plan, but no real way to change the direction of the project in mid-flight.

Further reading:

The Problems With Longer Sprints

Does a Shorter Sprint Deliver More?

Topics:
agile ,sprints ,timeframe ,Scrum ,feedback ,dynamic risk management ,small batch sizes

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}