Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to know if overtime is normal for sprints, or if it is an abuse of this methodology. I feel naive and spineless doing all-nighters if I don't have to.

Question is SCRUM specific. Compare methodologies.


migration rejected from Feb 9 at 4:55

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by MichaelT, gnat, Ixrec, Kilian Foth, Snowman Feb 9 at 4:55

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

all-nighters are never good for productivity -- you can do lot of work in one go, but in the end you have to sleep double. Also, I imagine the code quality after 8+/16+/24+ hours of coding. Sprints are necessary sometimes, but I would not suggest working more than 12 hours for more than 1 week. You're a human, you know :) You'll be tired for next two weeks after. – Timo Mar 14 '11 at 19:39
if SCRUM involves overtime I would call it 'screw' not 'scrum' – Imran Omar Bukhsh Mar 14 '11 at 21:57
That would be UNPAID overtime, right? Voluntarily contributed, for fear of losing your -- I mean, for fear of disappointing your colleagues who also, strangely enough, work unpaid overtime. Need I say more? – Paul Mar 15 '11 at 7:50
Do you have a pointy-haired boss? – HuBeZa Mar 15 '11 at 8:58
Massive overtime is an abuse of whatever system you're using. – kubi Mar 15 '11 at 9:23

11 Answers 11

Does SCRUM usually involve massive overtime?

No, it does not.

I would like to know if OT is normal for sprints, or if it is an abuse of this methodology. I feel naive and spineless doing all-nighters if I don't have to.

The whole point of Scrum and the amount of work you produce in a sprint, is that your velocity (how much you plan on doing) has be defined on a repeatable and sustainable pace. This is extremely important. Once you start violating this, things start to break down, as you have overestimated what you can do.

That being said if you all like working 60 hours a week, by all means do so. Just remember you have to be willing to do that on a normal basis :)


I suspect one problem is the use of "sprint" in SCRUM. In track, a sprint is a short run, very fast, that isn't sustainable. It uses anaerobic energy, energy stored in the muscles for ready use, because there isn't enough time in a sprint for breathing to do anything useful. Sprinters have little energy after the race, and have to spend more than the time of the sprint recovering. Running back-to-back sprints would be silly. It would have to be treated as a longer race, in which the runner would pace himself or herself at a slower but more sustainable speed.

The equivalent of a sprint, in programming, would be to pull an all-nighter or two, accomplishing as much as possible in a day or two without regard for productivity after that. The use of the term in SCRUM can encourage some really bad practices.

The key word is sustainable pace – DisEngaged Mar 14 '11 at 20:46
I agree here: people sometimes use sprint to mean "a weekend of 48 hours of work". Which is not what sprints mean in the context of scrum. I prefer the team "iteration", which avoids this (wrong) association. – RyanWilcox Mar 14 '11 at 22:01

Just the opposite: according to Scrum you should reserve at least 25% of "slack" time. For example work estimated for 8h is expected to be done in 1⅓ days, not in one day. Scrum specifically calls for not doing overtime. Tasks from the bottom of backlog that didn't get done get either dropped or reassigned to next sprint.

That's what I thought. – DisEngaged Mar 15 '11 at 1:40
A reputable source would be very nice. I don't think "some guy on SE said..." will hold much weight. – Buttons840 Jan 20 '12 at 19:35
@Buttons840: meh. Read anything about Scurm. – vartec Jan 23 '12 at 9:32

It sounds like someone in management thought that SCRUM would fix scheduling mistakes. Scrums are for increasing communication, identifying important issues, and removing blockages as early as possible, but it doesn't mean that developers can code twice as fast. I'd recommend against working lots of overtime, as this is not sustainable and will give managers a false short term view of what they'll start to think is a target velocity for future projects.

1 – mmyers Mar 15 '11 at 12:58

One of the key tenets of the Agile movement is working at a sustainable pace. Yes they call iterations "sprints" in Scrum but that doesn't mean you should run at breakneck speed.


The #1 problem with something like scrum is "phase mismatch". It is trivially easy for the person measuring to "be out of phase" with the person being measured. This can cause the perception of problems where they don't exist. Consider the case of a daily scrum with someone doing tasks that take 1.5 days. The impression left in that case can be "not done, not done, not done, etc". A sampling frequency of 3 days, on the other hand would be "on track", "on track", "on track", etc. The cliche "what a difference a day makes comes to mind". As a leader your job is to align your sampling frequency with the nature of the work your team is doing. Sometimes that means sample every day, sometimes that means sample once a month. If you are working overtime to meet an arbitrary sampling frequency, it means you and your boss are out of phase. You should resync with each other on a more natural frequency. Things will be more harmonious that way.


Scrum doesn't automatically increase your velocity - unfortunately, as velocity is a measurable metric, management automatically assume they can tweak it upwards.

The way to keep sprint momentum is to stick rigidly to the 6 hours of productive work per day guideline.

6 hours a day is overly optimistic, especially in an environment with things like SCRUM in place that demand excessive amounts of "progress meetings", "time management planning", etc. etc. (not SCRUM specific, but SCRUM is often a symptom of such an environment). Estimate 4 hours a day overhead per developer in such an organisation, 1-2 hours lunch/coffee breaks, and 2-3 hours productive time. In an organisation where developers can work as effectively as they can manage themselves, 5-6 hours can probably be attained. – jwenting Mar 15 '11 at 6:39
Yeah, i'd say the maximum estimate is 6 hours a day - but each developer should be able to feed in their personal overhead. This actually points to one of the 'problems' with scrum - in order for it to work it has to have heavy buy in and participation from developers. This often ends up with a managers role being squeezed out - or their perception of control being lost (not that they had much control over schedules to start with). – cbz Mar 15 '11 at 15:43

using a planning system like SCRUM gives managers a tool to blame developers even more for not meeting deadlines. After all, the planning was done correctly according to all the guidelines and you still couldn't do it, therefore you're bad and I'm brilliant...

But that's not because of SCRUM (or whatever method is used), but just uses it as another excuse for inept project management practices.


This was a problem all of us lived day-in and day-out at

The truth I think I've learned is that many organizations are too dysfunctional to do SCRUM. For example, things like failing a sprint, or even marking a ticket as 'blocked' would cause a Category 5 shit storm.

If you have a dysfunctional organization like that, SCRUM is destined to fail. My nickname for SCRUM there was "SCREW'EM" -- meaning the developers -- because management (eg the CEO) just couldn't accept the reality of the pace of software development and tried to fix it by repeatedly just saying "Go Faster" -> "Really, Go Faster" -> "Go Faster or we'll find people who CAN."

If you have a healthy software development orginzation they'll see that, for example, it's better to ship what's ready, to embrace reality, to fail a sprint if needed, that any one of those things is not an indication of poor performance but merely an acceptance of the reality of building something complex.

Sporadic OT, maybe for a couple sprints, where you at least feel your management is clued-in, then accept it and slog though. Because the nature of our business is product delivery. I've never seen a product delivered without some pain. It's always hard at the end. No matter your budget, your skill, your team, there's always a crunch at the end. So embrace it and even learn to CONSUME IT and you'll look like a clutch performer.

But wall-to-wall OT is a systemic problem. If that's what you're dealing with, get out of there. Nothing will fix it. At least not anytime soon.

That "crunch" at the end is not inevitable. It's a result of poor estimation. If it lasts more than a few days it's also ineffective. – kevin cline Jan 24 '12 at 22:56

Overtime is a fact of life in software (or in engineering for that matter). I know it's cliche to blame poor management for OT, and sometimes it is. But good work, specially the challenging one will always involve some OT. On average, I've always worked 45hr/week, and when doing consulting, probably 50-55.

It is not just of Scrum and AFAIK, a well-run Scrum project won't constantly put people into overdrive (a truth of most well-run companies, almost independently of the project management methodology.)


Continuous overtime is an indication of either inaccurate effort estimations or an unwillingness to trust or accept the estimations. This is methodology independent.

SCRUM is to some extent self-correcting in this area, if implemented correctly. It's the team's responsibility to provide effort estimations on each issue but it's also the whole team that should sign off on the scope of each sprint. So, if you are constantly working overtime, you are either accepting a scope that is unrealistic OR you are consistently under-estimating the effort required for each issue.

Or, you are simply being made to accept a scope without any input, which is just as common as it is bad. What it is not is SCRUM. SCRUM aims to build trust and responsibility by getting the entire time to sign-off on each sprint's scope.

As a very simplistic example: say the total cost of all issues in a sprint is calculated to X units but at the end of the spring, you only completed (X - 10) units worth of issues. Then, your team clearly can only deliver (X - 10) units of work, so next spring you only add (X - 10) units worth of issues to the scope.

Your project owner/manager might feel that your team should be producing more than you are and he might be right; I don't know what your team is like. It's not relevant to the issue of SCRUM though.

SCRUM does not, in and of itself, increase productivity. SCRUM aids in IDENTIFYING areas of improvment, it makes it easier to MEASURE performance and it makes deliveries more PREDICATABLE. Boosting productivity is still a fairly traditional trade. Remove obstacles and distractions, motivate and develop people and, as a last resort, replace people who don't cut it.


Not the answer you're looking for? Browse other questions tagged or ask your own question.