Truth behind 40-hours weeks
Now that you know how to count the size of your application, it’s time to get some data to base estimates on. Yes, the estimation is nothing more than an extrapolation of history data and size. The important thing to know is that the estimates will only be as good as you are. With an estimate based on history data, the estimate is based on your own real performance. Of course, if you took an average of 1.5 hour per size element (what ever you end up counting with), there is no reason to believe your next project will take only 1.2. Beyond these straight facts, only as good as you are also relates to the quality you produce. Bad size approximation or timesheets will only lead to bad data.
Size counting is subjective and beyond basic rules, there is nothing much that can be written down. On the other hand, collecting time is a lot more deterministic. Seconds, minutes and hours are well defined. Problems arrive when you speak of days and weeks. While a typical day of work is 8 hours and a week is 5 days, most can probably speak of days closer to 10 hours and weeks closer to 6 days. Writing down 40 hours per week on a project won’t give you much advice.
In a perfect world where there is no overtime, 40 hours a week is a good measure for the time spent in the office, but’s it’s not any close to the amount of worked time. In a typical day of work, a few hours should be taken off for those discussions about the football game the night before, coffee breaks, extended lunch breaks, time watching the score of the football game, personal phone calls or what ever employees do. This is not a bad thing, it improves the social interactions and probably even helps on the long run. With all these things, the original 8 hour is probably down to 7 hours (conservative value here).
Now, from the time spent working, those 7 hours remaining, how long can really be spent on a single project? Once you’ve removed the time spent helping a co-worker resolving a problem, pointing the manual to users, debugging the previous project, staff meetings and all those other distractions from the real work to be performed, I wouldn’t be surprised that the original 7 hours went down to 4. The worst part is that those hours are probably not consecutive and won’t allow you to be concentrated long enough.
Now, what should be entered on the timesheet and counted on the project? I count that remaining 4 hours. Knowing hour much time is used on a project is necessary to build the history data. How many hours a day is spent on a project is also important, since the past value is probably going to reflect the future values. If you think 4 hours a day is bad, Humphrey indicates that the average is closer to 12 or 15 hours per week.
Of course, you could decide to include the staff meeting time in the project. Again, as long as you remain constant, it shouldn’t be a problem (that is, as long as the meeting remains on topic).
Once you have history data, making an estimate is very easy. Multiply the counted size with average time per size element and you get the amount of work hours required. Divide the total work hours by the daily (or weekly) hours worked and you end up with a date. Even an history of two projects can provide impressive precision. I had 5-10% prevision on my first estimates, which were on 15-20 hours projects. The results obtained depend a lot on how regular you are in performing your work. If you are not very experimented with the language you are using, you are as likely to find a solution fast or stay on a problem for hours. Don’t expect to get good results in those situations.
As the history database grows, most analysis is possible. Average value is probably going to be replaced with linear regression. It will be possible to divide data is smaller groups to obtain greater correlations. This entry discussed generic topics you could read about in almost any book. The next entry will be about more specific techniques I use to sort my data.