Estimating how long it will take you to write software is a crucial yet often ignored skill. No matter the size of the project, it’s good to get into the habit of estimating your projects.
You don’t really need a complex system to achieve this. Here is a sample of a simple spreadsheet to get things of the ground.
This method was borrowed from Joel Spolsky book http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/
Some important points to note concerning software estimation:
As usual we are back to our beloved principle, your estimation platform should be as simple as you can make it. That is tasks should be as fine grained as reasonably possible. You should be thinking in tasks lasting 30 mins to at most 2 hours. In short a coding session.
It’s possible that you have longer coding sessions but I still believe you should keep it to this chunks.
Let the developer do it
There is evidence that letting people set their own schedules leads to boosts in productivity. Below is the findings of research carried out by Lawrence and Jeffrey from the University of New Wales. http://www.amazon.com/Programming-Productivity-Mcgraw-Hill-Engineering-Technology/dp/0070328110
Of course there is a caveat to this general rule as can be seen above, system analysts generally give better estimates. This is because they have more estimating experience. Still unless you have the budget for a system analyst, stick to the rule.
This is a living file
The column Curr Estimate and Elapsed time should be continuously updated. It is my suggestion that you take 10 mins after your coding session to update this values.
When you start of, your estimates are likely to be spectacularly wrong, however, if you discipline yourself to always update the estimates you will slowly but surely get better at this task as you learn from your mistakes and hone your estimating skills.
Version your estimates
It is critical that your estimates are part of the source. Whenever you commit your code, ensure there is a csv with your estimates within your project.
This gives you an opportune time to actually update your estimates before a commit as well as help you track the time used over long periods.
On this item you can either decide to use a time tracking software such as Toggl or use general estimates based on time spent.
This really is a matter of personal choice though you should strongly consider time tracking software if you or your agency bill by the hour.
It is important that you include other items that affect the schedule but are not programming tasks, this would include:
- vacation and family time
- debugging time
- buffer time
- deployment time
I hope I have been able to show the importance of scheduling and a simple way of achieving it. If you agree or have an even better method, share with us on the comments below.