Determining the Length of Sprints

Typically, sprints last anywhere from 1 to 4 weeks. A two-week sprint cycle is a fairly common length. The Scrum Guide indicates that:

“The heart of Scrum is a Sprint, a time-box of one month or less during which a ‘Done’, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.”

Why use such short durations? Although it may seem count counterintuitive, the shorter the time period, the easier it is to estimate the amount work required and to get the work done. Short sprint durations require that you break down tasks into pieces small enough to be completed within that short sprint length. Those smaller tasks are easier to estimate than larger ones.

Let’s say that the project that you wanted to complete is remodeling your kitchen and that you needed to tell someone how long it would take to finish the job (putting in new cabinets, appliances, flooring, tile, wallpaper, etc.)

Do you think that you would be able to quickly and accurately tell them how long it will take? Before you are tempted to say yes, have you ever heard someone talk about their kitchen remodel and how long it took? Did they tell you that you should take the contractor’s estimate of time and budget and double it? You could argue that general contractors are just universally bad at estimating, but somehow, I don’t think that is the issue. I think it is more accurate to say that estimating such a big project is not as easy as estimating how long it would take to complete any smaller piece of that project.

Now, if I asked you how long it would take to install new cabinets, do you think that you could give an accurate estimate? I am guessing that you could produce an estimate that is a lot closer to being accurate than an estimate on the completion of the entire kitchen.

How about if I asked you to estimate how long it would take to just put the hardware on the cabinets? Do you think that estimate would be more accurate than your estimate of installing the cabinets or than your estimate of completing the entire kitchen remodel? I would say definitely yes to both questions.

If we can agree that small projects are easier to estimate, you might be wondering why you cannot have longer sprints that contain lots of smaller tasks. The answer is three-fold.

First, the shorter development cycles compel teams to deliver faster. With less time between sprints, teams tend to stay focused. They are less likely to take on additional work outside of the prioritized sprint tasks. If a team has 3 months to deliver a project, it is a lot easier for them to get lulled into a sense of security that they have plenty of time to get things done and work on items outside of the scope of the current sprint.
Secondly, shorter development cycles help to bring issues up to the surface more quickly so that they can be addressed. Software bugs and design issues are found quickly, since the product gets built and tested more frequently.
Finally, teams are more likely to deliver products that are aligned with the product owner’s expectations and meet with the agreed upon requirements. With sprint reviews every 2 to 4 weeks, the product owner can quickly see the outcome of the development team’s work. The team does not run the risk of working for months to deliver a product to find that they built something that does not meet the customer’s requirements.

You should expect a learning curve when working in short sprints. It takes teams a few sprints to get a sense of the amount of work that they can get done. If you are having trouble completing tasks on time, you should look at how you are estimating tasks and not immediately increase the length of your sprints.