I'm a young programmer who has recently gotten a job at a company that is small but loves programming estimates. Since giving good estimates has been a problem for me in the past I'm happy about this chance to get better at estimating my time. Any advice on how best to improve?
Joel Spolsky recommends no single task longer than 16 hours in his blog. If there is more detail there, break it into subtasks. I prefer 1 day or 1/2 day pieces. And IT guys and developers are regularly optimistic (assume things will work first time, minimum debugging, etc.) Track your estimates vs. actually and use that to cushion your own estimates.
The first phase for a good estimate is to breakdown the problem at hand to smaller pieces. Try breaking down the task at hand to functional pieces. Since you're a programmer, break down your work to the development phases you're expected to follow (research, design, test planning, coding, testing, code reviewing, documenting, etc.).
A good detail level to strive for is having tasks of around 1 day of effort in size.
When you're done with the breakdown, the second phase would be to estimate the various tasks you have. Factors that could affect your estimates are:
- The level of certainty/uncertainty around what needs to be done.
- The technology you're working with - how much overhead do you have in a coding to testing iteration? How long does a build take? How hard is it to test and verify your code in small iterations?
- How much interaction do you need with other developers to accomplish your tasks?
- How stable is your environment and setup? Do you have lots of breakages or outages on a daily basis, that could block you from making progress?
I could go on and on... Try thinking of such criteria that are applicable to your environment. Take these points into account and try adjusting your estimations according to the answers to those questions. There's no one answer or a lookup table to help you pick an estimate given answers to those questions.
The next phase would be to review your estimates with your experienced peers. Don't just review the numbers. Review the rationale behind picking the numbers as your estimates.
Now, the final note here is to practice and monitor yourself over time. Keep a log of your estimates and the parameters that made you pick your estimates, log how much time did the tasks really take you and why. What factors had impact on the actuals? Do a retrospective with yourself from time to time and try to find factors you can take into account the next time you need to provide estimates.
Practice makes perfect (although there's no perfect in effort estimations...).
Hey Ama, Even though I think this question is quasi repeated, I will give you a short and sweet way that I tell our development team to use.
- Have a first swag for your own purpose. Let's call this
- If x is > than your PM tolerance (mine is 40 hours), then break down in simpler logical problems. Let's call this
x1, x2, x3
- Take x1 and the scope of x1, and think what will be the number if everything that can go wrong goes wrong. Your dev environment get broken, you have to ask too many questions because requirements are not clear, etc, etc. Let's call this
- I will take x1 and x1-worstcase and average it. like this:
This number will give you a good estimate in most cases, if you want to be less pessimistic, add a best case scenario.
Hope this helps. Geo
Get yourself a copy of "Software Estimation" by Steve McConnell. It will help a lot.
One GREAT rule in estimation is about managing customers. If you tell your wife you will be home at 5 and come home at 6, she gets mad, BUT if you tell her you will come home at 7pm and then get home at 6, in the end, she is happy. weird but true...basic psychology. Soooooo the most important part in giving an estimate is to make sure it will be higher than what you will deliver and if the PM is unhappy with the estimate, stand by it anyways and deliver it quicker!!!!!! in the end, he will be happy you delivered it early (and most likely will say start estimating better). It is better to be on time then late anyways from the business perspective as they nailed down dates with lots of external parties and want to deliver on those dates.