Scoping software projects in hours versus story points

Estimating the time required to deliver a software product is one of the most challenging tasks that development teams face. Incorrect estimates may cause schedules disruption or even a project failure.

When it comes to estimating the project scope, even the most experienced specialist won’t provide a 100% accurate figure, just an estimate. Why is that? 

Actually, most of the tasks require finding an optimal solution, taking into account the specifics of the future project or an already existing system. Even seemingly trivial tasks can be much more labor intensive than you think. 

So, the estimate may differ from the actual time spent on the project development, and here are the most common reasons for this:

  • Mistakes in the initial assessment;
  • Changed project requirements;
  • Technical risks occurring during the development process;
  • Poor developer productivity;
  • Urgently changed priorities.

There are only two major approaches toward project estimation - estimates in hours (also known as “man-hours”) and story points.

So, which approach to follow when estimating the project scope? Let’s take a closer look at both of them.

Man-hours

Estimating the project scope in man-hours is a common and fairly universal way. However, based on the experience of hundreds of companies, experts turn out to be too optimistic about the time spent on new tasks. For that reason, an adjustment for unforeseen difficulties and risks truly makes sense. 

And if a task is complex and labor intensive, it becomes virtually impossible to estimate its completion (without breaking down into subtasks). So, “man-hours” often become “man-days”. In addition, an estimate can be accurately provided only by a direct performer based on his own experience. However, if the estimated task is implemented by another person, the likelihood increases that the actual time frame for its implementation will differ from the estimated time,

Story points

In agile methodologies (like SCRUM), the effort is often measured in story points. A story point stands for a conditional value that allows you to give relative weights to various backlog Items.

So, under this approach you estimate the number of story points a team can deliver per iteration. The number of story points delivered per sprint represents the velocity.

When estimating the project scope, you refer not to a specific hour or a day, but for a relative story point. In addition, you need to take into account the following factors that can affect your estimation:

  • The amount of work required;
  • The technical complexity of the task;
  • The potential risks and uncertainties in requirements.

As a result, you get a more flexible and realistic assessment.

The benefits of each approach

Obviously, each approach has its specifics, so you will need to evaluate the effectiveness of each one for your team. To help you with this, let’s outline the main advantages of each method.

Benefits of Man-hours

  • If a team or a product changes, this approach will still be applicable.
  • The range of an estimate is quite flexible (up to an hour);
  • An estimate can be refined by decomposing the task;
  • As a rule, clients find this method rather clear and transparent.

Benefits of Story Points

  • Unlike under the “man-hours” approach, you are not committed to complete a certain task in X hours, which in turn allows the whole team to focus more on delivering value rather than on specific dates;
  • This approach allows you not to stick to the individual performance of developers - the tasks are evaluated relative to each other, so it doesn't matter at all who will take on the task - a beginner or a pro;
  • It allows you to take into account all the risks associated with the development process;
  • Under this approach, you can track the velocity - i.e., how many story points a team can handle per sprint.

Lots of teams have already appreciated Story points approach and prefer it to the traditional method of estimating the project scope in man-hours. As Dr. Jeff Sutherland, the co-creator of Scrum mentioned in his blog post, one of CMMI Level 5 companies determined that story point estimation cuts estimation time by 80%, which lets teams do more estimation and tracking than a typical waterfall team.

To sum up

While many high-performing teams have already abandoned hourly based estimation, today there are still many supporters of the traditional approach to project evaluation in man-hours.

The truth is that there is no one-size-fits-all recipe, and both options can be effective in this or that company, depending on the tasks specifics and the team itself. With time and already gained experience, a well-coordinated team can easily switch to Story points approach as needed, comparing the new tasks with those already completed before and estimating them on their own scale.

Interested in learning how we could help your development goals?