[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.