Software development effort estimation is the process of predicting the most realistic amount of effort (expressed in terms of person-hours or money) required to develop or maintain software based on incomplete, uncertain and noisy input.

In essence, estimation is the essential crux of software development, which is required for following purposes –

Evaluation of the total cost of the project

Decide on number of engineers (developers, testers and/or business analysts) required on the project

Decide tentative release date of the product

Decide tentative release date to deliver a feature (or set of features) into existing product

Estimates based on WBS, even though may not be accurate, they at least identify dependencies, tasks etc. which help in further planning.

When someone gives his/her own estimates

They never match, task is either vastly under estimated or overestimated

Not much efforts are put-in for task breakdown

Unit testing efforts are generally ignored

Documentation is not considered as an integral part of estimates

Testing (by QA) efforts are not considered by developers

Code review and review comments implementation finds no place while estimating

I have seen that an 8 hour estimated task being worked upon across several sprints and still not being complete. I agree that estimates can’t be accurate, however things like this can cause much damage to delivery schedule. There is either utter ignorance in terms of work breakdown or incompetence/lack of skills/vague user story; whatever the reason may be, this is not at all justifiable when there are strict deadlines to adhere too.

Bottom line is – despite being moved to agile methodology, there is still need of estimation to decide scope, size and budget of the project.

Moreover these are estimates for the team and not for an individual developer/tester. When a backlog needs to be worked upon, one must identify all the tasks that are required for the backlog.

Underestimation:

My observation is – either generic tasks are added to work on the backlog or only few tasks are added. Sometimes even test cases are also missed and added on the last day. Whatever the reason may be – procrastination/lack of knowledge/utter ignorance; when tasks are not broken down, things generally don’t go as planned and there is task slippage.

Overestimation:

Sometimes tasks are vastly overestimated, and when they complete, rest of the time is filled with other useless non-productive activities.

Expectations from individuals or teams

Great things are not achieved by luck, one needs to work towards achieving the goals to make it happen. I think, an estimation is a step forward towards achieving the goal.

Questions to ask yourself

Have I included unit testing/test case estimates? (Shouldn’t I write VSTS test cases? Or Coded UI test for my UI?)

How many features I am going to cover during implementation of the backlog? Can they be broken down further? Does backlog/user story can be further split (if cannot fit into one sprint)?

Conclusion

Estimations are very much important, and we as a software developer are compelled to provide these all the time. So we must take proactive steps to eliminate all the roadblocks (as far as possible) and come up with estimates and then refine estimate as we work on the tasks.