How to Calculate Man-Hours for A Software Project: Explanation with an Example
How to Calculate Man-Hours for A Software Project: Explanation with an Example
Estimation of a project's cost, time, and scope are all essential in Agile development, and estimating man-hours is an essential part of that.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Costs estimation is at the heart of the software development process. It is important for every business to have the ability to have an estimate for each project they have. Estimation can be thrown randomly to advance quickly but that would not really make sense. There is a long process that leads to cost estimation. Besides costs, there is another important aspect that needs to be taken into account: how long would it take to deliver the product? When answering these questions, there are few things we need to understand: how do you calculate software? How does software development project estimation work? How should you calculate man-hours for a software project?
How Does Software Development Project Estimation Work?
In order to make an accurate estimation and get how to provide estimates for software development, it is important to understand the scope of work. We have already explained this in a previous blog post. Let's just sum up the main steps in few bullet points when going through estimation process.
- Understanding the scope of work.
- Understanding the overall complexity of the project
- Divide the whole complex projects into simple manageable tasks and therefore easy to estimate
- Based on experience, familiarity with the task and expertise; estimate these tasks one by one
Most of the project estimation processes start with these steps. The most important point is to break the project into small units, which are simpler to estimate. It is much simpler to estimate how long would it take for an intermediate developer to develop an API to perform LDAP authentication for instance than to estimate time to secure an application.
Now when it comes to measuring project estimation, it is important to give estimation in man-hour. Trying to get man-hours needed to complete a project will help us answer how to estimate software development time. Why is it important to estimate projects in man-hours? And what is man-hour?
Understanding the Man-Hour
Estimation is important because it helps not only have a knowledge of the budget needed but also have an idea of the time needed to complete the project. The time estimation can be easily translated into budget once we know how much a man-hour costs and after analyzing the dependencies of all tasks we can compute the time it will take to complete the whole project.
So what is man-hour? A man-hour defines the amount of work done by an average IT specialist during one hour worked without any interruption. There are two separate concepts in man-hour:
- Man: the specialist doing the task (developer, tester, etc.). It is important to define and differentiate each team involved in order to make a good estimation. Considering a backend developer when estimating load testing is not relevant. Each estimation has to be made on the correct "man."
- Hour: 60 minutes of continuous work. It is important to note and understand the absence of interruption while doing the estimation. A total hour spread over two days will still be counted as one hour; resources optimization should be done during planning in order to avoid discontinuity as much as possible. We will see in the following section how to estimate hours for a project.
Now that we have seen the two important components of time estimation which are "man" and "hour," it is important to stress that having an accurate estimation of each role is crucial since planning will be based on the output of this estimation.
In order to use efficiently the hour worked by the specialist involved in software development, it is important to understand what may prevent him from working on his task in a continuous way. Does he need to wait for other resources, other features to be completed, etc.? A thorough understanding of dependencies and anticipation for resources needed are ingredients of a good planning. A good planning means scheduling a task at its favorable moment, defining exactly the precedence constraints, availability of the developer or tester etc. For a successful planning, the question how to estimate software development time should be addressed efficiently.
The value of man-hour can be defined in two different ways:
- Intermediate level: while defining man-hour, we were referring to average IT specialist which means an average developer or average tester. The time it takes to complete a task will differ depending on the experience level of the IT specialist working on the task. A junior developer will need time to figure out how to implement a solution when an intermediate will implement it faster and in theory a senior level will be the fastest.
- The average velocity of the team: this can be computed by dividing by the number of works the time they have spent completing the tasks. In this case, a man-hour can be very different from a team to another depending on the experience level of all the team members that form the development team.
Defining intermediate level can be difficult, even intermediate developers can have disparate velocity. This is why sometimes basing estimation on team's velocity can be a very good idea. The latter implies that we already know the team members involved.
How to Estimate a Software Project
Now that we have gained more understanding on man-hour at what it represents, we are going to see how to estimate a software project and especially how to estimate a software project in man-hours.
When implementing a software project, there are several methodologies and good practices that development team adopts. Agility was accepted as a good methodology to ensure the quality of delivery. Agile encourages the involvement of the development team at its design stage and during the estimation of the loads.
Before we browse some software development project estimation techniques, let's define some concepts we need to better understand these techniques.
- Backlog: A backlog is a group of tasks that need to be completed in order to complete a project.
- User story: A user story is a simple unit of tasks, it defines what needs to be done in order to achieve a specific goal.
- Story points: A story point is a unit of measure that translates the amount of work needed to complete a user story.
With these definitions in mind, we are going to see how to provide estimates for software development.
Planning Poker or Scrum Poker
A planning poker is a practice introduced by Agile methodology. During a planning poker, when the project is broken down into stories and everything is put in the backlog, the development team comes together to discuss the time needed to complete the project based on stories in backlog.
The term poker may suggest gambling or a random estimation of a task. Actually, during a planning poker, those who are going to realize the project will give their input on every task and discuss when estimations are very divergent.
Each member of the development team is given a card to express his perception of the complexity of each task. Cards contain the value: 1, 2, 3, 5, 8, 13, as they are akin to the Fibonacci suites, only we will have 20, 40 and 100 instead of 21, 34, 55, and three extra cards containing non-numeric value: the coffee card, the question mark card, and the infinity card.
Developers will first agree on the simplest user story in the backlog, which will serve as a reference and will be affected a story point value 1. Numbers that are closer to the value 1 express user stories that are simple and those that move away from 1 have a higher complexity. Infinity defines a very complex user story that has a complexity higher than 100. The question mark is used when the developer doesn't know how to estimate the user story.
During a planning poker, tasks are not yet measured in man-hour or man-day; it is estimated in terms of story points. Story points are computed using the average estimation given by the developers. At the end of the planning, we will have the estimation of the whole project in terms of story points.
Now, from the story point, how to calculate man-hours for a software project? The simplest user story will be estimated in man-hour so that when all the stories for the whole project will have their story points, man-hours for all the user stories in the backlog will be computed as simple as the multiplication of the total points with the man-hour value of a story point.
Another approach consists of doing the estimation based on similar projects, the actual man-hours needed to complete them and adapt to the context of the software project to estimate. At this point, it is important to evaluate the complexity compared to the past projects taken as references. Once the complexity is defined, the actual man-hours needed to complete the similar projects will be multiplied by the complexity factor.
If the person who is trying to do the estimation has not the required background or knowledge to perform the estimation or is not familiar to how to estimate hours for a project, he can ask an external team, since it is important to have an accurate estimation.
There can be two different phases during which cost estimation is computed: first during the first discussion when clients' requirements are gathered. Then, after having a global idea of their needs, we do a first estimate. This estimate is refined at a later stage when the development phase starts and we have a complete understanding of what is going to be implemented. The more detailed the requirement is, the more accurate the estimate is; it also leads to a more detailed technical specification.
Tools for the Estimation
Now that we are aware of how to estimate a software project in man-hours, we are going to browse some tools used during software development project estimation. We have already discussed earlier that it is important to break the complex project into small tasks that are easier to estimate.
JIRA (or any Agile/Scrum tools)
With Jira and other Agile/Scrum tools, you can do estimation first using planning poker techniques. We first estimate story points and then transform them into man-hours. Since estimation process in software development is an evolutionary process, past projects can be used to refine the estimation process. Time tracker is an excellent feature in Jira. Time tracking is made easier and can be very accurate since we can start tracking as soon as we start a task and pause whenever we are waiting for resources, and each time the task is assigned to another person, the time tracker is paused until the person is actually acting on the task. Tracking time will help refine future project estimation and will help us compare between actual time spent and estimation.
Easy Redmine is one of the most popular and widely used add-ons for the Redmine. Worth to say that many users have never worked with pure Redmine apart from this redesigned version. Easy Redine has very simple yet effective and easy to use Cost Estimation feature which allows users to assign a cost or hourly rate for each task and thus see the final cost of each action performed by the development team.
Ecosys Projects is a highly configurable Excel-like solution for project estimation. The most important feature here is the possibility for tracking changes made in the estimation tools, changes are versioned easily. It is able to not only estimate projects in man-hours but can also provide the corresponding cost in other types of measure like currency.
Excel is widely used for estimation process in software development. Excel can perform from a very simple calculation to a complicated formula. Since estimation process can be improved based on past experience, Excel estimation tools can be updated with lessons learned from past projects. You can first start with a very simple sheet with few columns: one for tasks to estimate, one for each actor involved. For each task, you put the estimated man-hours needed by the corresponding actor. You can start with an existing template and adapt it to your needs instead of starting from scratch.
For every tool used to perform estimation, it is important to have in mind that these tools will make the estimation process easier, but they won't do the estimation for us.
Example of the Estimation
First, we are going to divide the login page into simple tasks that are easier to estimate. In order to break down this feature, we are going to identify all use cases and from these use cases identify the tasks needed to achieve them. Once we have all the simple tasks needed to complete an authentication, we are going to copy and past these tasks into excel (see table below). Based on previous experience estimating authentication, we are going to give an estimate of these tasks.
Let's identify all possible use cases:
- The user clicks on the sign in button and gets redirected to a login page.
- The user has entered valid credentials and gets redirected to another page.
- The user has entered invalid credentials and gets redirected to wrong credential page
- The user can log in using a Gmail account
- The user has forgotten his password and asks to reset his password
From these use cases, we can define the tasks that are needed in order to allow users to have access to these features.
- Design the login page so that user can have access to it
- Authenticate the user against a database: check that the user has permission to access the page.
- Redirect user according to authentication result: if the user is authorized to access the page he is redirected to an authenticated page and to an error page otherwise.
- Authenticate user using an existing Gmail account.
Let's evaluate these tasks using man-hour estimation approach.
After estimation, this login page will require 12.25 man-hours: 2 man-hour project manager time, 9 man-hours developers time and 2.25 man-hour QA engineer time.
Even though developing an accurate time estimates is time-consuming, it is an important ingredient for the success of software development so it is important to understand how to calculate software development cost. When software development time estimation is not done properly, it can lead to frustration for both the clients and the development team. Developers may be frustrated because they may have to do lots of overtime in order to deliver the software at the date agreed with the client. On the other hand, the client may be frustrated as well if the delivery date is constantly postponed or late, or there is a constant need to review the budget after the implementation has started.
Sometimes the software to deliver is quite large so that it may be necessary to perform estimation using man-day where man-day represents the amount of work done during a workday, a work-day can be defined as cumulative eight hours of uninterrupted work.
Whether the time estimation is measured with man-hour or man-day, it is important to invest time and adopt the right method to have a time estimate as accurate as possible. Also, involving the development team during estimation phase can be very useful since they have a better understanding of how to build software plus they will be more committed to respecting the agreed deadlines since estimation was done based on their input.
What method do you prefer when making the estimation of your software development costs? Leave your questions and opinion the comments section below. Need the help of professional offshore software development company with the estimation of the project development costs?Drop us a line via or at our website and we'll get back to you shortly to help.
Published at DZone with permission of Victor Osetskyi , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.