The Art (err.. Science) of Effort estimation
No matter how battle-hardened a software professional one is, one innocent question from either your boss or fellow colleague that will always make one think:
How long would this take?
The question sounds pretty innocuous at first glance but irrespective of whether this is for building a prototype or a full blown product development, contrary to popular belief there is a lot that rides on this question! Most folks underestimate the significance of this step in a project and end up assuming that its either the design/architecture or the delivery/execution steps that gives one more bang for the buck! True, a software architected well is pretty much a foundation on which the product stands on and an execution well handled well gets the product to the customer. But, one aspect that software programmers typically struggle to give the right amount of prominence to is “delivery promise”! A Promise to get things into the market, in the hands of its users, a promise to get the subsidiary activities of a software organization to kick into gear! After all, the true purpose of building a software in the first place is “to solve a real problem for its users, at the right time and at the right price”.
More often than not, the common misconception is that estimation is a job better left to the ones with grey hair! For some rhyme or reason, this is looked at as a form of art where only the ones who have burnt their hands can do a good job. Thats true to some extent, and like every other walk of life experience does come in handy. There is a process to arrive at a fairly confident estimate — discipline and sticking to the basics is all that one needs to be aware off. Here are some of the tips on doing it scientifically and predictably.
The biggest detail most people miss out on is to recognize the basics needed to get the project off the ground. These could be anywhere from getting the folks available to start, to procuring servers. These are the unproductive items that one needs to get out of the way to be be able kick the project into top gear.
2. Use Tools
There are a multitude of free tools that are available today to help one get organized to follow this as a process. If one is not comfortable with these, there is always the good old excel! The trick is to be able to organize the information in a consistent manner.
3. Break down the tasks
The biggest trick to doing this well, is to be able to break down the work into atomic pieces of work. Work that is not too trivial (keep the smallest unit as half a day) and neither too substantial (nothing goes beyond 2 days e.g.). Yes, there will be substantially big chunks of work, but there in lies the discipline of identifying smaller pieces. This would help one to get a more realistic estimate of the work when things get added up!
4. Organize the information
Whatever the tools we decide to use, each task needs to be detailed in the form of 4 Ws — What (name of the task), When (start and end date), Who (will work on the task) and Where (does it fall in he sequence and what other tasks does it depend on).
5. “Unwritten” requirements/NFRs
Developers love to work with specs — true! And the quality of work is directly proportional to the quality of story break down thats been done by the Product Manager. But, any software product would at have pieces that are too technical to be covered by the business owner — deployment / security / performance etc are classic examples of what would go into this group. The fact of the matter is than a product would not go out without these, so might as well account for it to make it all worth it!
6. Understand priorities
Any use cases/stories that one works on, its extremely important that one understands the priorities of these right during the planning phase — this would help one plan the sequence and would help you hedge your bets in terms of the resource allocation.
Do not plan in isolation if its a multi-person project. More often than not, a common mistake that a group can make is to plan different pieces in silos and hope that things would fall in place. Even if a certain Mr Murphy would have liked to shower his blessings, this is a sure shot way of asking for trouble. Yes, code to interfaces, but make sure there is enough visibility across the board.
7. Have Buffers/Plan for “distractions”
No matter which organization you work for, even with the best of plans there would always be “something else” where you would be needed! Or something on the personal front may come up which would need your attention. The golden 20% buffer rule still works well is what I have seen.
8. Work with milestones
Human mind works in mysterious ways and it is common knowledge that working with targets keeps one focussed and aligned to the bigger goal. Any plan that you would line up, always have check points where smaller pieces of the project are ready to go. Milestones also helps one to react/realign sooner to any delays or surprises that may come up during the project.
Like all things in life, a plan needs a second and probably a third look (with a fresh set of eyes)! This is primarily to make sure the resources are balanced correctly and all tasks are aligned and sequenced correctly.
10. Follow through/update your tasks
As you make progress, its important that the plan document (voila, we need the tool again!) keeps getting updated — probably on a daily basis. This would ensure that you can eyeball it at any point in time to get a quick idea of the overall status.
Following these easy and simple processes would go a long way in ensuring you would eliminate the guess work involved in the process.
Originally published at blog.coviam.com