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:

1. 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.
2. 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.
3. 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.

User Story Points Approach: After three years with that team and serving four customers, I finally moved to a different project and a different team. The new team almost religiously followed the Scrum methodology. It was not pure Scrum at the beginning, but there was a lot of effort to slowly move toward a pure Scrum setup. Tasks were assigned story points during the sprint planning and were taken up based on the team’s velocity.

Now, the major difference I noticed here was the assignment of user story points and their interpretations. These points were assigned based on the perceived complexity of the task, not just on how much time it would take to finish. It was like saying, I understand that this is tougher than other tasks, so it may take more time. But, there was no commitment to how long it would take to finish, so there was a sense of relief about not being the one who estimated the task wrongly! Of course, the duration aspect of planning was not left alone—team velocity took care of it. As the team progressed across sprints, the velocity was calculated and based on the historical data, and it became quite easy to calculate how long a task would take.

I personally liked this a lot, and I feel that if an organization is serious about growth and simultaneously helping its employees achieve a good work-life balance, the story point-based estimation is a far superior method. In my case, we were still vendors to another company, but there was a huge change in the way we were working. The user story points approach also is far more flexible and easy to use compared to the man-hours approach, which is closed-ended and leaves little scope for future problems the teams may face.

Even the customer-facing managers who were responsible for schedules and delivery were better off in this project due to improved on-time performance and less firefighting during the deadlines. There were a few instances of people being stretched thing at the end of sprints, but it still was much better than when we were using man-hours to estimate efforts. The customers were happy, too, because the promises made at the beginning of sprints were kept, without any known issues.

What are your views on estimation? What method has worked best for you? Let us know in the comments below.