We’ve mentioned on the show a few times that overtime can be a troublemaker when using Agile. Not only does it throw off burndown counts (the number of tasks from your to-do list you finish off each cycle), but it builds over time as fatigue, which then results in slower and slower task burndowns.
On a team, we highly recommend enforcing regular hours to avoid breaking what’s best about Agile, but if you do have to do overtime, there are ways to compensate for it in your data.
The easiest way to compensate is to accurately track the extra hours spent in overtime and make sure that time gets reflected in the burndown data. If, without overtime, a team manages “80 hours” worth of tasks in a 40-hour work week, that means you’re averaging around (80/40 * 8) “16 hours” worth of tasks a day (assuming 8 hours per day). However, if the team is doing “100 hours” worth of tasks in a 40-hour work week with 2 hours of overtime every day (a 50-hour work week), then that means you’re still averaging around (100/50 * 8) “16 hours” worth of tasks a day.
But that doesn’t make sense, right? With the overtime, the team is doing “100 hours” worth of work, whereas if they didn’t do overtime, they’d only be getting “80 hours” worth of work done, so how can those numbers be true?
Well, the “16 hours” worth of tasks a day number isn’t entirely true, but it’s more useful in planning than the “20 hours” number you would get if you simply added the work completed (100/40 * 8), and there are two reasons why.
1) Fatigue : There is always a hidden cost to overtime, even if it doesn’t appear today. If you trick yourself into thinking your team is accomplishing more than it’s supposed to because it’s relying on borrowed time, then you’re going to reach a point later in the project where that mistaken assumption comes back to bite you. Better to build a buffer in advance to help keep to your schedules later.
2) Scaling : Let’s go into a worst-case scenario. Assume that you have three months to a deadline, and you have absolutely no way to complete the tasks you need to deliver using even 10 hours a day. Well, how can you decide how much time you need to put into the project to finish it on time? How can you decide whether you need to call for help? How can you decide what is just beyond your capacity and requires negotiation? That “16 hours” number is how. If you make sure overtime is always reflected in your numbers, then you can scale that figure to however many hours you need.
If you have a week left and you need to accomplish “32 hours” worth of tasks a day to reach the deadline, then you can divide 32 by 16 to figure out you need to work double days (an extra 8 hours a day). Of course, time doesn’t scale because people are not machines, despite what some companies would like to believe, so that number is still pretty fanciful if you were to really consider working the team 16 hours a day, but it could give you a basis for deciding how much help you need, or how many features you need to cut.
Of course the best solution for dealing with overtime in Agile projects is to just make sure it doesn’t exist!