Man-Hours: What Are They and Why Don’t They Work for Us?


Using manpower is one of the most common techniques for measuring work.  It relies on an estimate of the amount of work that can be completed by one person within one hour.  While manpower is easy to understand, there are a few drawbacks to this technique: 

  • Some tasks are difficult to estimate precisely.  
  • If a project or task is completed faster than someone else thought it would take, it creates inconsistencies in the estimates across your whole team, which means they're no longer an accurate way to measure productivity.  
  • The time needed to complete a task will vary depending on the programmer's experience on the job.
  • People often underestimate the effort required to get something done and overestimate their ability to meet deadlines or get through a project.
    The sad reality is that such optimism usually fails and it's not until things go wrong that most people start realizing just how wrong they were, missing your deadline by weeks or months if not more. That's why we offer so many alternatives for our clients to choose from depending on how they work most efficiently, whether you prefer keeping things simple with estimates in man-hours or you want something more sophisticated like Story Points estimation which allows you to evaluate various estimates quickly and easily, making sure the team headed by the Product Manager understands what needs to be done without micromanaging workers at every turn.

What is a Story Point and how to use it to estimate your project

Making an app costs a lot of time and effort. Apps are created by teams of individuals working with one another in different areas. Story points are used to track their progress in the development process, using metrics for three aspects:

  • Amount of work needed to be done on the project which is performed in minutes.
  • The complexity of tasks performed is about the amount of effort that goes into getting them accomplished.
  • Any additional risks or uncertainties associated with the completion of the task may end up adding more time to it if not properly dealt with.

The Story Points approach is based on the comparison of features of one project with features of a previous similar project. In case the estimation is performed for the first time, a team needs to identify a Base Story and create a Matrix for Estimation drawing from this base story.

Why is Story Points better than Hours in 2021?

Both developers and project managers would like to think that story point estimates are the same as man-hours. However, this is not true, as they can vary from each other because of different factors. Story points give advantages over man-hours by:

1. No correlation with skills and experience of the estimator

As we already mentioned, a specialist who estimates a task isn’t always the one who implements it. Senior and Junior developers need different amounts of time to complete the same task. The only way to avoid all this is to make a developer who estimates a project also implements that project.

Story points eliminate this problem because they are a universal measurement across the whole team. The estimate doesn’t depend on who’s implementing the story. All team members with different skill levels can discuss it together and come to a single conclusion.

2. Velocity is Tracked

Another key to the power of Story Points estimation is velocity. Velocity is a powerful capacity planning method that demonstrates how much product backlog effort a software development team can successfully accommodate every time they take on sprints.

The main goal here is to not only increase your teamwork’s velocity but also work towards meeting an end goal; if you’re working with speed, then that means that at some point there will be successful completion of any tasks present in that particular project. This also means more things being done within a set period while maintaining perfect focus at all times - critical factors while working with engineering teams!

But velocity changes with time or as new tasks are incorporated into the project. So it may not be wise to use this value to re-estimate your project. Instead of resorting to estimating in man-hours, you can find other people who will help you keep pace during your product's development.

3. No Re-Estimation if Velocity Changes (Flexibility)

Another advantage of the story point system is that you can easily change deadlines without having to re-estimate tasks if team members are changed. If one person estimates a project, but other people complete the tasks, then Story Points become indispensable.

Let us describe several examples.

Example 1: Our company has a project at $200 that one developer starts working on. The velocity of this developer for this task is $1 every three hours. The start date is May 30th, so based on this information, it’s easy to calculate the project completion date.

1. The time needed to finish all the work:

One can estimate a project's size by using the formula where Qsp is the general quantity of SP in the project and t is the time to complete 1 SP.In this case, 200x3 = 600 (hours).

2. The number of workdays:

It stands to reason that if in our company there are 100 workdays in a year, in 6 hours per day we can get 600 productive hours, in which case for 100 workdays the number of SPs will be equal to 60 thousand. If for some reason development is carried out by another company with 50 people working 8 hours a day with productivity equal to one story point per 1.5 hours, then `the number of workdays will be decreased to 20 and the release date will coincide with August 5th.

Example 2: Our project should be done by the time the month ends. The team has completed 40 per cent of that amount by halfway through the first month. That means that if they keep up that pace, then it will take another ~10 weeks to complete. This means that if everything goes as planned, then your final product should be available for download by late September.

Let's say that using our 20 SP velocity, it should take us 5 sprints to complete the project. The release date is August 8th. Let’s further say that because our team is now working harder, we’ve decided to move our sprints down to two weeks (two 40 hour work weeks) instead of four weeks (weeks with Friday off).

The release date has been recalculated to July 25th. During iterations, this data is very precise and allows our Product Owner to make a better decision about the project’s timeline. We can easily convert abstract Story Points into more understandable dates that occur within weeks from now or beyond after any changes in the team. This gives us flexibility as a team to revise our timelines if it makes sense because we're all working together to see to completion what has been compiled.

4. Perfect for high-level estimation

Story Points are a unique technique for an initial estimation purpose of the scope of work related to User Stories. Where estimating hours is almost impossible without defined data models, precise requirements and other necessary information, Story Points will help you understand the range of work that might be included in your project on high-level terms based on your experience.

When making estimates it is important to take into consideration dependencies. For example, if you plan to integrate something that requires an API then story points are probably the best approach to choose because it allows you to account for any uncertainty related to the work item being estimated. A great example of where third-party integrations are essential is when dealing with Google APIs.

Let’s just say you have a User Story for your marketplace startup, and it involves working with a third-party inventory management system. Before you can schedule a time to work on the integration, you have to do some research first. In this case, more research can equate to higher costs! As some of our clients report back from time to time, there may be unforeseen charges. That is why some people skip out on researching something beforehand and instead surprise themselves with work that may be more expensive than they anticipated.

Imagine that there are 200 total story points for a project and you estimate that a certain feature is 5 story points.

Let's assume that we've considered all the risks and difficulties of the project. However, after you gain access to the documentation, you find out that it's more complicated than expected and need to re-assess the features point count and bump it up accordingly. Now it's easy to recalculate if needed.

Let’s sum up

Story points have been used to keep records of a project's development since its inception. This way one can easily track the team's progress and anticipate future releases. Although this approach is effective, many specialists favour a combination of both Story Points and man-hours.

However, because our team has a high number of years of experience in web development, we'd like to share with you why we prefer using Story Points for project planning purposes because they represent hours well spent on tasks without having to have precise records for every hour worked.