Effort estimation is a major challenge for all the stakeholders of a project. Most people generally underestimate situations that may block progress and consider only the best-case scenario for a project. Your choice of estimation method may not be helping, though. Which would be better for your team: estimating by man-hours or by user story points?
Effort estimation is a major challenge for all the stakeholders of a project, whether you face customers, manage the budget, or are a developer. In any case, it is important to know how long the task at hand will take, but it’s especially important for the customer-facing managers who need to commit to delivery schedules and face the flak if the team falters.
However, in a pure Scrum-based approach, there is little the manager can do; he depends on the ScrumMaster and team to decide on the efforts for tasks and, hence, the delivery schedule. Here is the catch: We are all human, and we are all equally bad at estimating stuff. Even mundane activkkities like paying bills and grocery shopping sometimes take longer than we would guess. This is because humans account for the best-case scenario without giving a thought to situations that may block progress.
In our quest to find the best possible technique for effort estimation, let’s start with the different categories of estimation techniques available currently. There are three:
- Expert estimation: This is the technique completely based on judgment of the experts. Such techniques are generally more accurate if the team, or at least a few members, are experienced and have been working on the project for long durations. Otherwise, there is a fairly high chance of incorrect estimation.
- Formal estimation: This type of estimation uses mathematical techniques, which may involve a formula derived from historical data. A couple of examples are COCOMO and weighted micro function points. User story point-based estimation also is considered to be part of this estimation category.
- Combination-based estimation: This estimation technique involves both of the above categories and combines the results. The aim is to take the best of both worlds: experience and mathematical equations. Examples are work breakdown structure-based estimations combined with judgmental estimations.
But these definitions don’t provide any insight into which is better. So, let’s go a step further and look at real-life experiences to get an idea of what goes on in the mind of a developer when estimation and reality don’t match.
In my career of five years as a software developer, I used the expert estimation (man-hours) approach for about three years. Then I moved to a Scrum-based team and learned about the user story points concept and the related effort estimation approach.
Man-Hours Approach: The team I worked for at the start of my career followed incremental software development methodology, and we shipped code every two weeks to the customer. There were different teams for different modules, and each team had a list of tasks. Just after a release, teams planned the tasks for the next release based on the number of man-hours available during the development phase and estimated duration of the tasks.
Now, as I said earlier, humans generally underestimate unplanned blockages they might face and consider only the best-case scenario. Our team did that too, so most of the time releases were stressful and long hours were the norm. There was no way we could falter on the delivery; after all, we were service providers and could not afford to malign the reputation of our company.
Being a new member of the team, I started to think that maybe this is just the way it works and I was supposed to slog along and somehow finish the task. I also thought this was justified—there were eighty man-hours available for development, and the task was estimated at sixty man-hours. Still, I could not finish it, so I figured there must be something wrong with my way of working efficiently.