13

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?

Improve this question
2
  • 4
    Related question: pm.stackexchange.com/questions/25/…
    – Kieran Andrews
    Feb 15, 2011 at 23:57
  • 1
    Where are the moderators? We need to get some 10k equivalent users on here so we can take care of questions like this. It's a great question for Programmers SE but not here.
    – jmort253
    Feb 16, 2011 at 3:59

6 Answers 6

Reset to default
9

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.

Improve this answer
1
7

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:

  1. The level of certainty/uncertainty around what needs to be done.
  2. 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?
  3. How much interaction do you need with other developers to accomplish your tasks?
  4. 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...).

Improve this answer
1
  • The only problem I found in this that to create a Work Breakdown Structure(WBS) you need to be little expertise in the field. Because if WBS will not be able to satisfy 100% rule than it may result in excess time and cost.
    – Chris
    Jun 30, 2011 at 11:27
4

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

x

  • 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

x1-worstcase

  • I will take x1 and x1-worstcase and average it. like this:

(x1+x1-worstcase)/2

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

Improve this answer
3
  • Break it down smaller. Never more than 2 weeks; preferably <2 days.
  • Record how you do so you can see are you typically 2x or 10x off. Use bug/task tracking that has this feature, e.g., FogBugz or redmine.
Improve this answer
1
  • Break down task in the smaller pieces, i.e. work pacakages is a good option but usually it is considered that when WP goes beyond the specific level it may result in high cost but lower complexity.
    – Chris
    Jun 30, 2011 at 11:30
3

Get yourself a copy of "Software Estimation" by Steve McConnell. It will help a lot.

Improve this answer
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.