One of the common tasks a developer is asked to do is to estimate the amount of time a particular feature will take to develop. According to the literature, we apparently suck at this. Developers are constantly being told that they cannot make good estimates.
So here's some help.
This post describes a fairly common technique, wherein the developer breaks the task down into units that can be completed in a small number of days (2, in this example). It does not specify if the developer is determining this alone or as part of a group.
Another example of a method is here. This provides a little more process, for those estimating as a group instead of individual developers.
The Ninja Way for estimations is not much different in the inital steps - you determine the size of the overall task, break it into sub tasks that are about the quantum you have found reasonably accurate to guess (typically 1-2 days), and add up those times. Next, look over each step, and ask yourself what could happen that would delay your completion of that step without removing the need to complete that subtask - someone else using the test machine for that release, an overnight build failure, etc. Guess at how long that would take to recover from, and add the longest of those single things into the estimate for that step. For example, if the test machine is in use, how log would it take for you to schedule a break with the current user? (And those who are so 21-century who ask "Why only one test machine? Why manual tests?" - wake up to the fact that not everything is run on a commodity web-server, and not all development organizations have the budget for even one machine per released version of their product.)
This should get you an estimate that will cover the inevitable delays.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
