6 reasons you should never use man-hours estimation

Let’s think about the reasons we need work estimation to begin with. In traditional project management it was quite straightforward. You assume that building the foundation will take you 10 days, then walls and roof will be constructed within 15 days, plumbing and electrical works will take another 5 days, and voilà, 30 days after the construction started you can start internal decorative works. This approach to planning allows you to arrange for resources to arrive at the right time and helps you to see the overall picture. The construction company that does this planning usually would have quite an accurate estimate for each phase of work and number of people required to complete it. You will probably have 5 people pouring in the concrete into the foundation, but only 2 working on light fixtures and plumbing.

Man-hours (as well as man-days or man-weeks) concept comes from this world of project management, but it goes one step further. It tells us, that if some work requires 5 men (or, I’d rather say 5 persons) working for 1h to complete, it might as well be completed by 1 person working for 5 hours.

On the paper it looks beautiful and allows for some interesting calculations. For example, if we have a project estimated as 200 man-hours, it can be completed by 4 people within 50 hours. Or we can add one more person and get in done in only 40 hours, yay! If you ever had to deal with the project management triangle - scope, budget and schedule, you should know that they are interrelated and change in one of the sides of triangle will impact at least one more of its sides. Increase the scope, and you will either delay the project or the budget will get out of control. On the surface it seems that man-hours allow us to play with budget and schedule and be very clear about the tradeoffs.

Unfortunately, it doesn’t work like that in the real world. And here are the reasons why.

Sometimes work items take certain period of time regardless of how many people are working on it. The concrete needs to solidify, the water needs to boil, the code needs to compile. Not all the things can be controlled by people, and throwing more resources at one task in hope to compete it faster might just lead to a huge waste. There are cases when the productivity increases until certain point, but then starts dropping. When I get my nails done, adding the second person to work on another hand in parallel would speed things up, but if the third person joins, she will only prevent the other two from doing their job efficiently.

Let’s say you have a senior and junior people on the team, working on similar kind of tasks. Are their man-hours the same? Probably not. What a senior person can do in 20 minutes, might take over an hour for someone junior. So when you estimate your work, which of them would you base your estimates on? On senior? Then you’ll be overly optimistic, set up unrealistic schedule and burn out your team quickly. On junior? Then you might end up with very conservative goals and a bored team. You could, of course, also pre-assign work and ask each person to estimate their pieces, but that would create tension in the team.

It is understandable that sometimes you might need to identify the critical path of the project and calculate by which dates you would need certain resources. But can you really use the historical data? Unfortunately, in most cases the answer is no. Sure, you can calculate how many hours the team has worked and how many man-hours worth of work they have completed. But if in the following period this number drops or increases, does it mean that they were more (or less) productive? Does it imply that they have accomplished more, or just worked longer hours? Unfortunately, man-hours estimation doesn’t give us answers to these questions.

As humans, we are terrible at making predictions about the future. We tend to be overly optimistic (remember the last time you bought the new piece of sports equipment?) and at the same time we often try to protect ourselves from burning out at work and add buffer to our estimates. As a results, the estimates tend to be all over the place. On top of that, we usually don’t account for risks and unexpected events, and I’m not talking about black swans. What if Mary goes on 3 days sick leave? What if Joe has to help out customer support resolving a tricky technical problem? Time-based estimates might work for small work items, but the bigger the piece of work becomes, the less accurate we will be. Also, in most cases we are dealing with uncertainties that might increase or decrease time spent on work. What if the new vendor cannot support the change we introduce? Or what if the new design doesn’t work for the customer and we have to redo it?

Time-based estimates are designed to be precise. But that causes a lot of overhead when it comes to estimation, because people would be questioning each other’s numbers and spending a lot of time arguing over the estimates. Normally, work estimation process is extremely valuable because it helps us to reduce the unknowns and get on the same page. When people disagree about the scope of work, it often is an indicator of poorly defined scope of work or some discrepancies in understanding. However, fighting to decide whether a work item should be 35 or 36 hours is not worth the time spent. It might turn out to be 54 hours - the larger work items are, the more surprises they tend to bring to the team.

Have you heard about Tuckman’s stages of team development? Well, let me fill you in real quick. According to Bruce Tuckman, a famous American psychological researcher, each team needs to go through three stages before they become productive. First is forming, when everyone gets together for the first time and is really excited about the new team and new project. Then there is storming, when people learn about each other’s working styles and things get rough. Personal conflicts, power games, miscommunication and misalignment are very common at this stage. Finally, there is norming, when team members get over their differences and come up with a set of norms and start playing well together and sharing toys. It doesn’t have to be formal or official, but over time everyone just starts understanding how to collaborate with team members efficiently. Why do we care? Because the team only gets to performing stage after these three stages (which might take a while), and adding a new team member is virtually like starting a brand new team - you need to go through these stages again! So, man-hours estimation leads us to a fallacy that we can always just add one more person and bump up our productivity, but it’s not the case. Instead, your team will likely slow down and become less efficient until it reaches the performing stage again.

While I would not say that story points are panacea to all work estimation problems (as much as I’d love to say that!), it is always a good idea to use relative estimates. That means that you estimate not the time, but the size of the work item, comparing it to other pieces of work. The size would include the time you need to spend on it, the complexity, the uncertainties and the risks. And instead of trying to guess the absolute size of the item, you would place it into one of many imaginary buckets. In case of story points, we use a modified Fibonacci scale - 1, 2, 3, 5, 8, 13, 20, 40, 100, but you might as well use t-shirt sizes (XS, S, M, L, XL) or something more creative, like animals (frog, dog, horse, elephant, whale) or how about beer? I’m sure if you measure work in pints, pitchers and barrels, the team morale would go up!