Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: Improving Your Ability to Estimate

by cbrandtbuffalo (Deacon)
on Feb 12, 2005 at 14:14 UTC ( #430405=note: print w/ replies, xml ) Need Help??


in reply to Improving Your Ability to Estimate

Good stuff for discrete tasks. We have a similar practice, but it's a step removed from the developers; it's our time-tracking and project management software. It tracks estimates and actuals. The problem is, I don't think developers ever go back and look at the differences or review how they did with their estimates. Your suggestions above are directly aimed at being very self-aware to improve the estimates, which is a good goal. I think we've fallen into a slightly different mode where our project managers look at the past data and apply their own factor to each developer's estimates.

In other words, they learn that developer X is routinely short by half, so they double all of her estimates. In some cases we have developers who are over-cautious, so they take 75% of their estimates. Don't know if this is better or worse. I guess the developers don't have to change, but they certainly don't become any better at estimating.

My estimation problems are a little deeper with my position. I act as a technical manager on projects which means I run into two difficult estimating tasks:

  1. In some cases, I need to estimate time for a task without knowing who will code it. It's well documented that coders work at very different levels of productivity. I have more experience, so my estimates would be too low. So I estimate, then double it. When the project starts, we sometimes make another pass once actual developers have been assigned.
  2. Most of my own tasks are very ill defined, so it's difficult for me to estimate for myself. For example, one task might be 'Research bug tracking products,' or even 'Figure out how we should validate our forms.' Lately there has been some great discussion on perlmonks on validation, so I might find that and finish quickly. In other cases, it takes me a while to track down best practices on something. I still have a very hard time estimating these ill-defined tasks.


Comment on Re: Improving Your Ability to Estimate
Re^2: Improving Your Ability to Estimate
by dws (Chancellor) on Feb 12, 2005 at 16:35 UTC

    I think we've fallen into a slightly different mode where our project managers look at the past data and apply their own factor to each developer's estimates.

    Two red flags on this. The first you touched on: developers don't review their actuals vs. estimates, and so don't improve their estimates. If management wants it this way, it says something pretty cynical (to me, at least) about how management views programmers.

    The other danger is that this gives management a bunch of out-of-context data about individual "performance". Data out of context can be used stupidly (e.g., for ranking purposes) and can lead to stupid management decisions.

    When you're in the position of estimating without knowing who (else) will do the work, you're in a bad spot. When a team has data on their own past performance, and has been working to improve their estimates, I'll wager that they can give you better estimates than you can pull out of the air yourself, regardless of who on the team will actually do the work. That's been our experience. We do team estimation (or some subset of the team does for simpler tasks), and our estimate vs. actual history is a lot better than it would be if someone up the chain guessed at task difficulty.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://430405]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (6)
As of 2014-09-23 05:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (210 votes), past polls