Does Scrum have any rules about overtime?
Recently, the Quality of Life issue has been revived. This is a good thing to talk about regularly and I applaud Erin Hoffman, Jason Della Rocca and others for not letting this topic die. A recent Gamasutra article discusses how things have progressed since the EA Spouse days of 2004. It doesn't sound like much has improved.
I've heard people say that Scrum avoids overtime because teams can decide to drop some of their Sprint goals if they are faced with too much to do within 40 hour weeks. I disagree with this interpretation. I think it creates problems.
Teams commit to a certain amount of work that they estimate can be completed in a 2-4 week Sprint. Estimating 2-4 weeks worth of work can still have uncertainties though. There can be many unanticipated problems that can occur during the Sprint that can impact progress. But this doesn't mean the team can or should dump goals at the first sign of trouble.
Teams should take commitments seriously. This creates a pressure on them to find more effective ways to work to meet commitments. We want the teams constantly looking for small improvements. Even a 1% improvement each Sprint will add up big in the long term.
Don't Punish Overcommitment
Sometimes a team will push too aggressively on their goals or hit major problems that they couldn't anticipate or were out of their control. If we insist that they complete all their goals even if they have to work insane hours, they will not continue to push the limit on future sprints. They will sandbag to avoid the pain. Teams should know when there is too much to do in a reasonable amount of time and should go to the product owner to discuss dropping some goals when there is too much to do.
So how much overtime should a Scrum team do? It's up to them. If it's the last Sprint before a major release we'll see teams putting in a couple of weeks of late nights and rarely a weekend. If they find that they are doing this too often, they need to improve how they estimate.
One thing for sure is that when management doesn't dictate overtime to the teams, the attitude about overtime changes. When a team decides to do overtime, they do it as a team. They help each other out. It can actually be a strong team building experience.
Teams should find a sustainable pace that they can work over the long term. This might mean working close to 40 hours per week most of the time with periods of crunch that don't last too long.
How long should crunch last? There have been studies that show the real effectiveness of crunch. For us, the proof came the last time management enforced company wide overtime (in 2005). We "asked" the teams to work 6 days a week at 10 hours a day to finish Darkwatch. The proof came from the velocity observed in burndown charts.
The following chart shows how much time the teams averaged in burning off their estimated hours per week:
The first week was a normal ~ 40 hour week. Weeks 2-5 were the 60 hour weeks. The first thing you notice is that the overtime in week 2 caused the velocity to greatly increase. More "stuff" was getting done! However the velocity decreased until we get to week 5 where the velocity was even less than a normal week!
How is this possible? It's simple. People get tired. They make more mistakes. They lose the incentive to create value.
This is what I love about Scrum...it creates simple empirical evidence about what works and what doesn't. This is why there is no "rule" about overtime in Scrum. There doesn't need to be a rule. If your teams are truly using Scrum to find the best way to work, they'll quickly discover that after several weeks of moderate overtime, the value is lost and you might as well not continue. It becomes common sense.