Skip to main content

Does shorter sprint(eg : 2 weeks) has more overhead than the longer sprint( eg: 4 weeks)?

Last post 02:53 pm April 29, 2019 by Sander Dur
8 replies
11:42 am April 18, 2019

I am not sure about the overhead and additional cost of shorter sprint. In the book "Software in 30 days" by ken and Jeff ,there is a costing table of short vs long sprint.

where short sprint has a accelerated increase in cost with decrease in sprint size.I am confused about the costing as the events in scrum  scale linearly.(for example: sprint review is for 4 hours for 4 weeks sprint and for 2 hours for 2 weeks sprint).How short sprints has more overhead than the long sprints.


12:35 am April 19, 2019

Using the maximum allotted timeboxes per the Scrum Guide, in a 4 week / 1 month Sprint, assuming that each Scrum Team member participates in all events, each person would spend at most 8 hours in Sprint Planning, between 4.5 and 5 hours in Daily Scrum, 4 hours in a Sprint Review, 3 hours in Sprint Retrospective, and 80 hours performing refinement. This is a total of 99.5-100 hours in Scrum events per Sprint, out of a total of 800 hours in the Sprint, or about 1/8 or about 13% of capacity.

Assuming that each event is scaled down proportionally for a shorter sprint, during a 1 week Sprint, each person would spend 2 hours in Sprint planning, between 0.75 and 1.25 hours in Daily Scrum, 1 hour in Sprint Review, about 1 hour in Sprint Retrospective, and about 4 hours performing refinement. This is about 20% of a person's normal work week.

I made the assumption that all Scrum Team members participate in all events equally, which is not necessarily true. For example, the Daily Scrum is primarily for the Development Team and may not need the attendance of the Product Owner and Scrum Master. It also assumes the full timebox is used for all events, which also may not be true. This also only accounts for spending time in Scrum-mandated events and activities and not other coordination events.

I'd point out that the relative time spent in events isn't that different, especially as teams mature and understand the purpose behind their events and get better at executing them. Rather than looking at overhead, you should consider the ability of the team to do work that is worth getting feedback on. In some cases, stakeholders outside the team simply cannot provide feedback on a weekly cadence, so 2, 3, or 4 week cadences allow the team more time to do more work and have a larger set of work to review and get feedback on. However, this also does increase the risk of the team doing the wrong work and needing to course correct. So it's all about tradeoffs.


04:39 am April 19, 2019

Thanks Thomas for replying.I want to know why you assumed hours spent on backlog refinement for 4 weeks sprint is 80 hours and that of 1 week sprint is 4 hours.Why there is a huge difference between the two and why it is not scaled down like other scrum events.


04:40 pm April 19, 2019

Not going to put words in @Thomas' mouth but notice that the Scrum Guide says:

Refinement usually consumes no more than 10% of the capacity of the Development Team.

Given the total time for Sprints of differing length his calculations are much clearer.  

Hope that helps. 


04:58 pm April 19, 2019

How short sprints has more overhead than the long sprints.

Does the administrative overhead required to hold a good, productive event scale linearly with the time-box allowed for it?


09:39 am April 20, 2019

I think we should be careful when we talk about the overhead of any sprint length, or any way of working.

This kind of question often leads to talk of efficiently utilizing the time spent on various initiatives; without necessarily discussing how effective that is.

It might be that 2 week sprints involve more context switching, and more time spent in meetings. I'm more interested in what can be achieved within 2 or 4 weeks (or any other length), and whether a certain sprint length provides better opportunities to learn more quickly and change direction.

Although shorter sprints theoretically allow this, having longer sprints can allow for more outcome focused Sprint Goals, and provide better learning opportunities.

Being able to inspect and adapt is generally more important than maximizing the amount of work done or product developed.


09:03 pm April 20, 2019

Thanks Thomas for replying.I want to know why you assumed hours spent on backlog refinement for 4 weeks sprint is 80 hours and that of 1 week sprint is 4 hours.Why there is a huge difference between the two and why it is not scaled down like other scrum events.

I based it on the 10% of the Development Team's capacity. However, I also totally botched the math for the 4 week Sprint. Assuming a 40 hour work week, there would be 160 hours in a 4 week Sprint. 10% of 160 is 16, not 80. This results in 8 hours for Sprint Planning, 4.5-5 hours in Daily Scrum, 4 hours in Sprint Review, 3 hours in Sprint Retrospective, and 16 hours performing refinement activities. This results in a total of 35.5-36 hours of allocated activities, which is about 23% of capacity. This makes it even closer in total capacity to the time spent in a 1 week Sprint in terms of effort.

However, as I mentioned in my last paragraphs, I would also like to concur with Simon Mayer's thoughts. There are more important things than overhead, and that's the ability to synchronize with business events and with external stakeholders. What makes the most sense for the team to produce something that is worthy of inspection by external stakeholders?


01:59 pm April 25, 2019

Even if it costs more in overhead, you get faster feedback with shorter sprints. Faster feedback means more effective product increments and higher value. 


02:53 pm April 29, 2019

Valuable points mentioned in the arguments above. I'd like to add that the longer the duration of the sprint, the higher the risk of either stakeholders changing their minds, the initial planning needs to adjust on a larger scale, etc. etc. Although 4 weeks is still a short period of time, these things are more likely to happen in a 4 week sprint than in a 2 week sprint. 

On the other hand, the impact of the larger amount of work done in a 4 week sprint usually leeds to bigger "ooh's" and "aah's". So like Thomas already said, it's about trade-offs.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.