TL;DR: Estimating things in man hours do not work in software development. There are better methodologies such as Agile, Scrum, and story points.
What are man hours?
It’s a unit of work done by a person within an hour. It’s commonly use to estimating how long something will take to be completed such a project or a task.
Why don’t man hours work?
For software development, man hours work if and only if:
* the project, feature, or task is well defined and does not change
* everyone has the same minimum skill set needed to complete said project, feature, or task
* software engineer will output 8 hours of work per day
In reality, a software team filled with different people of varying skills and experiences. One engineer’s 8 hour of work is not the same as another engineer’s 8 hour of work due to varying skills and experiences. Projects are constantly change due to new technology, unknown technical debt, or even priority.
The biggest problem is the task will be estimated by one person and may only accurate if that person completes the task. A common scenario that comes up is a senior engineer could estimate task will be done in 2 man hours versus a junior engineer could estimate the very same task will be done in 8 man hours. Both are correct and it depends on who will do the work to get the task done. Which one do you use in your project estimate? There are common solutions which are assign all jobs upfront or use the padding to estimate. All of these common solutions create problems of their own.
Peril 1: Assigning Jobs Upfront
Most of the time, assigning the tasks upfront keeps the project’s estimates accurate, but there are times where it does not work. Something unexpected comes up like the person has a last minute vacation, the person gets sick, the person makes a poor estimate, or an unknown factor makes the estimate inaccurate.
Let’s go with a common scenario and say the person is sick and the task needs to be reassigned to someone else. The estimate is only accurate if the person who estimated it does the task so it needs to be estimated again before it can be reassigned to another person. This leads to the load balancing peril discussed later on.
Peril 2: Bad Estimates
Trying to estimate how to complete a task with so many unknown factors is a ballpark estimate at best. There are different types of people who will estimate things optimistically or conservatively. Each has its own problems.
Let’s say the optimistic person estimates 4 man hours and gets it done in 6 man hours. It’s not bad, but it may led to a domino effect where everything else is delayed by 2 man hours or more. This leads to the load balancing peril or the padding peril.
Let’s say the conservative person estimates 8 man hours and gets it done in 6 man hours. Some people will report they finished early and start on a new task. Most people will play the time game and wait until 8 hours has actually passed by.
Peril 3: Load Balancing
When something unexpected happens or an estimate is incorrect, tasks may need to be shifted around and a load balancing needs to happen. All the man hour estimates are only correct if the individual who estimated does the job. This causes everything to be estimated again to see what is the most effective plan to keep the project on schedule, which causes unforeseen overhead for a project that’s behind. There are many scenarios that lead to load balancing, which may cause a team may have to re-estimate and replan many times throughout the project.
Peril 4: Padding Estimates
One of the common ways to help keep estimates accurate is to pad them by some arbitrary percentage such as 25% to create a safety net. An individual will pad his estimate by 25%. Then his boss will pad all the estimates by 25%. Then his boss’ boss will pad the estimates by another 25%. The project becomes this giant multi-month long project that may never get off the ground due to resource costs.
Peril 5: Bad Culture
Like any software development project, there are always time pressures and schedules to keep. I have seen this cause a bad culture of having the senior engineers do a lot of the work instead of junior engineers to maintain the schedule. Your junior engineer’s growth are stunted and the senior engineers are overworked. There isn’t anyone to train junior engineers since your more senior engineers are busy coding away. Concepts like extreme pair programming are difficult to advocate for because it looks like you’re not efficiently using people’s time. When you’re hiring, you’ll opt for senior engineers over junior engineers because it’s more efficient for the project schedule due to the above reasons.
What to use instead of man hours?
There isn’t a perfect solution but there are better solutions such as using Agile, Scrum, and story points. A very short summary of the benefits are:
- Agile eliminates the heavy overhead of planning and being stuck within a plan by making the project into many short cycles of work and reassessing the priorities at the end of the cycles.
- Scrum eliminates the “time” element within the work that the team completes since everything is about what you can do within a time box.
- Story points are arbitrary units of measurement based off on complex of a task relative to another task. It eliminates the difference of skill and experience in the estimate since the whole team estimates each “story” based on complexity.
There are many other emerging software project management methodologies out there. Find one that works for your team and company.