Frankly, those “hard blocks” you mention in #2 are the worst idea I’ve heard in a long time. What happens if a top-priority bug is found at 4.45pm and the guy who has the ability to override your blocks is off sick? As for #3 – you’re suggesting punishing people for doing their jobs.

If the team are consistently working overtime to complete sprints, then either they have an interest in working overtime – e.g. overtime pay or getting overtime back as holidays – or they are committing to doing too much work in the sprints.

If they have an interest in working overtime, remove it. Development isn’t something you can do for 60 hours a week and stay productive, and there are numerous studies out there that prove this. If overtime pay is the issue, get rid of it and improve their base pay so they’re getting what they’re worth.

If there is too much work going into the sprints, this is usually for one of three reasons:

1. The developers are being told what they must achieve in a sprint/aren’t being consulted on what’s achievable/are being ignored when they say there’s too much work.
2. The developers are consistently underestimating how much time tasks will take/how many units of work are involved in each task.
3. The developers keep being pulled onto tasks which aren’t part of the scrum.

If it’s #1, you’re doing it wrong. No two ways about it!

If it’s #2, the usual cause is inexperience – either with doing time estimates, or with the system being developed. A good way around this is to stop doing time estimates and start estimating ‘units of work’. Use some abstract unit, just make sure it isn’t real-time hours (ultimately you’re still representing a time interval, but the abstraction is important!). You can then start calculating how many units of work actually get done in a week, then set up sprints using that data.

If it’s #3, you need to start factoring in those other tasks somehow. If it’s consistent it should be easy to account for (see #2 above). If it’s frequent but unpredictable it’s much tricker to deal with. You’ll want to take a look at why it’s happening (e.g. serious bugs in ‘live’ code => is your testing thorough enough?) but if that can’t be fixed then ultimately scrum might not be the right approach for you. My team recently switched over to Kanban for this very reason…

Edit: Clarified my criticism of the ideas presented in the question.

First of all, it sounds like they got too much work on a sprint if they have to work overtime to get it done. Are all the hours logged? If so then you could count how much actual work is a story point and use that number to calculate work for next sprint.

It is also important to make sure the team understands they are only harming themselves by taking too much work. Even the agile manifesto talks about sustainable pace:
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Working overtime all the time is not sustainable.

All in all, I’d suggest communication instead of force and penalties. I’d imagine that would only lead to demoralization of the team.

The devs working overtime are likely responding to some incentive, either actual or perceived. The is to either remove the incentive if it is actual, or to communicate that a perceived incentive is not operational.

Each suggested hard limit has some workarounds or other problems. Source control blocks would just lead to developers holding onto their commits until the window opens again. Workstation blocks would have to go as soon as there was some support issue or one of the devs needed to shift his hours for some reason. Penalty systems will just lead to hiding or burying overtime hours.

I think the problem is more fundamental — the team has some incentive (or believes they have an incentive) to work overtime.

This is what needs to be addressed. Are their performance appraisals tied to their velocity numbers? Does management work overtime? Are promotions and awards given to those who work long hours? Are they contractors who are paid for overtime?

Simply tell the team not to work overtime. Period.

This may cause them to not be able to finish some work. That’s not a problem, that’s a data point. They can then use that data point in planning the next sprint. Again, don’t let them work overtime. Whether they finish or not, they have another data point. Lather, rinse, repeat.

No amount of tricks or limits are necessary. Just don’t work overtime. Learn how much work you can accomplish, and adjust your sprint planning accordingly.

Maybe there is an issue of not how “much” they are working but when. This can be a problem when there is a scheduled work day, but much of the normal hours are made up of meetings and other social and personal distractions. Are they working during over-time periods because they just feel more productive.

Cut down on the amount of work in the sprint and start working on flex time. Allow them to come in later. The person in charge needs to just tell people to go home; it’s all right. There are some corporate cultures that create an environment where leaving early can bring some frowns.

I struggled with this when I first switched to scrum. It’s natural to want to put in extra effort near a deadline, but scrum has deadlines every two weeks so it’s an adjustment. In addition to the suggestion others have made to cut back on the committed story points every iteration, I would also suggest ensuring the stories are broken down enough, so each developer can finish at least two or three in an iteration.

That not only ensures each developer feels like they have accomplished something each iteration, it also gives you some slack in your scope. When your burndown shows you won’t be able to finish a story, you can pull it out and reallocate people to the stories that can be finished. When people see that scope can be adjusted, they will be less likely to stress out about unrealistic deadlines. If you start an iteration with every story in progress, you have no room for adjustment.

An ideal cumulative flow chart should look something like this if everyone is finishing two stories per iteration:

It never looks like that because in reality it’s very difficult to time all the stories to end on the last day while keeping everyone busy, but it’s a good rule of thumb. If you are overcommitted, the red area will be larger and you can remove stories. If you are undercommitted, the blue area will be larger and you can add stories. If your stories are too big, the green area will be larger and you should split stories.

To avoid overtime, you have to cut the scope of the project.

The following chart shows where uncertainty lies in a project:

If you notice, at the product definition and requirements phases, you have a huge variance in estimation of effort. You can’t be sure if it will take a month or a day to implement the feature.

I’m betting that none of the tasks are done done because they’re simply too large and unspecified and there’s too many of them.

If your team can handle 10 tickets in 5 days, and they’re assigned 20 tickets, cut that number down, kick it up to the product owner/project manager/manager/client and tell them to prioritize.

At this point that’s the only way to save the team from overtime. You can’t deliver everything, but whatever you do deliver will be less likely to have bugs.

I would also advise looking for a new job and helping your team mates to do the same and fix up their resumes and professional portfolios. A company that expects overtime is one no one should work for and the software produced will be buggy as hell.

I advise strongly against “hard blocks”. Such controls could be perceived as micro-management and may fail to address the underlying issue.

I suggest that you find out why programmers are working overtime. The answer may surprise you. It sounds like you are an “outsider” (not an employee of the company), and programmers may be willing to be candid with you if you meet with them privately (one-on-one).

Is the reason for working overtime truly the workload, or is the reason more to do with culture or expectations?

Workload reasons could be

• The committed backlog is too big
• Either programmers or the product
  owner is “gold-plating” (making features more complex than needed)

Expectations could be

• Some sort of financial or recognition reward for working overtime
• Fear of failure. The programmers are afraid that they will look bad or be punished if they do not meet the deadline
• The programmers are underestimating the harmful long-term effects of working overtime.