[mewpmewp2]

I've been considered high performer everywhere I went, only when I was beginning I usually gave very low and naive estimates, experience has taught me otherwise. Of course it will also depend on who and why I'm giving those estimations to.

Usually there are just too many unknowns that higher estimate is justified to avoid having to explain why you didn't make it by certain deadline. The estimates I give are not median or average that I expected the task to complete, they are so that I can be 95% sure it's possible to do it and then some.

[rightbyte]

Ye and this is the problem with management using estimates as deadline.

When I was naive and believed that Agile was not a sinister micromanagement toolkit to mess with programmers, I tried to explain to people that about half of our estimates should overshoot and half undershoot or they are biased and that there should be more overshoots since there is no upper bound on how much time a task can take if the estimate is wrong.

Ye. No. The burndown chart shouls be as straight as possible.

[mewpmewp2]

Yeah, and even if it is not being done as of moment, there is always a possibility of someone clueless from leadership deciding it is a good idea to check how many story points you have completed by some rough statistical analysis, in which case people who put higher estimates and completed those tickets will look better.

[rightbyte]

Ye. The manager need to be a programmer and involved in the project to be able to evaluate the participants.

I guess 'estimation poker' is a way to counteract the obvious strategy to coast and look competent.

In poker you can also look good by underbidding your peers and then snatch the easy ones to look good while the scapegoats look bad.

The strategy need some social status or incubent code knowledge relative to the team though, to get the good tasks.

[mewpmewp2]

I have thought about how it would be fun to have something where people will either openly or blindly estimate and bid. In practice I might be concerned about few things like introducing too much of a competitive culture within the team. Or it could lead to a place where people get too specialized and knowledge doesn't spread around, since everyone will bid on things they have experience with, and so they will be the only one with that experience, which might hurt in the long run. I couldn't actually imagine doing it in my current team. I think people are diligent anyway, and already work more hours than usually would be required. I find it better to just try to protect each other within the team, to drive everyone making higher estimates.

Also doing bidding for those estimates in addition could mean that there might be strong incentives for a lot of corner cutting for certain tasks, etc. People will value short term gains over long term gains when there's such pressure.

[rightbyte]

I think any process step that resembles a game might be problematic.

And a major problem with group estimates is that given how much knowledge a person has about the code, the effective time will vary so much.

So dunno. I have no experiance as a team lead or manager.

I would probably not track task time at all as a manager. It would give the illusion of insight. Rather some loose percent worked by project per programmer.