3 ms·

At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work. If you estimated the lowest on multiple

At most of the places I worked at where we did estimations - the person with the lowest estimate got assigned the work. If you estimated the lowest on multiple things - you got the one where you deviated the most. If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...

ignoramous 5y ago
> Tf you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer... This is but a different kind of a rat-race?
- onlyrealcuzzo 5y ago
  Code quality should be handled in review. If you're deliver buggy code, then thay should be addressed as the bugs come up. Is that something that should've been caught in integration tests? Why did it pass review then? As long as it's not a pattern, it's not a problem. If something super severe happens - that's an organization-wide problem...
strzibny 5y ago
That sounds like a horrible place to work!
pvorb 5y ago
The place where I work, we discuss the estimates until we agree on a shared estimate. If there are no outliers, we just take the average.
- thesimon 5y ago
  We usually start by discussing the outliers on both sides. This makes it easy to uncover simpler solutions (if everyone had a higher estimate) or pitfalls (if everyone had a lower estimate).
  - pvorb 5y ago
    Yes, that's exactly what I meant to describe.
A_non_e-moose 5y ago
> If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer... It's very hard to find axiomatic statements like those, that actually work in the possible multitude of contexts. Which assumptions are behind that statement? Does the team have uniform experience working in a single product? That statement feels more applicable here. Or are there multiple work streams that aren't even touched by a few members and everyone is involved in estimations for everything? That statement feels less applicable here, and trying to enforce it could lead to experts in one workstream to be considered low performers, which motivates a consulting style lowest bidder environment, probably ending in overworked people and low quality code reaching prod.

ignoramous 5y ago

> Tf you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer... This is but a different kind of a rat-race?

onlyrealcuzzo 5y ago
Code quality should be handled in review. If you're deliver buggy code, then thay should be addressed as the bugs come up. Is that something that should've been caught in integration tests? Why did it pass review then? As long as it's not a pattern, it's not a problem. If something super severe happens - that's an organization-wide problem...

strzibny 5y ago

That sounds like a horrible place to work!

pvorb 5y ago

The place where I work, we discuss the estimates until we agree on a shared estimate. If there are no outliers, we just take the average.

thesimon 5y ago
We usually start by discussing the outliers on both sides. This makes it easy to uncover simpler solutions (if everyone had a higher estimate) or pitfalls (if everyone had a lower estimate).
- pvorb 5y ago
  Yes, that's exactly what I meant to describe.

A_non_e-moose 5y ago

> If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer... It's very hard to find axiomatic statements like those, that actually work in the possible multitude of contexts. Which assumptions are behind that statement? Does the team have uniform experience working in a single product? That statement feels more applicable here. Or are there multiple work streams that aren't even touched by a few members and everyone is involved in estimations for everything? That statement feels less applicable here, and trying to enforce it could lead to experts in one workstream to be considered low performers, which motivates a consulting style lowest bidder environment, probably ending in overworked people and low quality code reaching prod.