5 ms·

If measuring as a team, then it evens out. Unless you have a specialist that would be better placed on other tasks, and a generalist taking that specialist's ta

If measuring as a team, then it evens out. Unless you have a specialist that would be better placed on other tasks, and a generalist taking that specialist's tasks, that junior engineer is going to take longer than the senior engineer that has been on the team for a while. So, if you are measuring the team's capacity, it usually doesn't matter what task the junior engineer does - it's going to take longer and require assistance from the senior engineer. If you measure on size of task with modifiers for tasks novel to the entire team, the differences will usually average out.

sizing 5y ago
I’d love to believe that but I’ve never seen it in practice. The misses always outweigh the hits and it creates a frustrating team dynamic. You end up with seniors steam-rolling through estimates (hah! I did a large in a day! Applaud me!) and juniors stuck on a small for a week. External stakeholders may see that over time you end up with performance and estimates averaging out to match up, but that’s very vulnerable to turnover in a team (a few juniors join and the team is underperforming and it’s all the juniors fault) and the internal team dynamic does not mirror the external. Tasks and engineers are not fungible, allocating the right developer to the right task and giving it a developer-specific estimate will have much greater results.
wppick 5y ago
This is why it can be better to just -prioritize- without -estimating-. Make sure you clearly and strategically prioritize the work to do, and plan for continuous delivery, or release milestones. Assume that your engineers will work just as fast as if they made inaccurate estimates (keep in mind overestimates might result in engineers slacking off to fill the over estimated time). You can always look at the work that engineers deliver, see how long it took them, and senior engineers will be able to tell if that engineer spent a reasonable amount of time for that task. You could call this post-estimates vs traditional pre-estimates. So tl;dr: just do good prioritizing and do post-estimates to gauge whether people are slacking off
- aahortwwy 5y ago
  Found the Taylorist. Estimates are there to help you forecast what you can get done within a particular time period, which in turn helps you prioritize units of work. Using them as post-hoc commitments and second-guessing your team is toxic.
  - ebiester 5y ago
    Agree and disagree. I agree as a default scenario, you are correct. However, we always need evidence to show if a team member is struggling and needs extra assistance, or in the worst case is not contributing positively to the team. This is not over a single blown estimate but rather a larger pattern of underperformance. This is the failure mode, however.
  - wppick 5y ago
    Will have to read more about Taylorism, thanks for putting this on my radar. I can see how the post reviews could be toxic, but pre estimates could also be toxic especially if estimates suddenly become hard deadlines. I think it comes down to nuance in both cases. Post estimates could tie into performance reviews and bonus allocation as well. Where your bonus and performance would be a tight feedback loop, and determined by multiple peers vs. a single manager. It really depends on each individual org which way works best
    - aahortwwy 5y ago
      > Post estimates could tie into performance reviews and bonus allocation as well. Now your colleagues aren't estimating the task, they're estimating the post-estimate. I'd suggest adding Goodhart's Law to your reading list as well. Every single time I've seen estimates tied to anything performance related they've been actively gamed and lost their utility as a forecasting device.

sizing 5y ago

I’d love to believe that but I’ve never seen it in practice. The misses always outweigh the hits and it creates a frustrating team dynamic. You end up with seniors steam-rolling through estimates (hah! I did a large in a day! Applaud me!) and juniors stuck on a small for a week. External stakeholders may see that over time you end up with performance and estimates averaging out to match up, but that’s very vulnerable to turnover in a team (a few juniors join and the team is underperforming and it’s all the juniors fault) and the internal team dynamic does not mirror the external. Tasks and engineers are not fungible, allocating the right developer to the right task and giving it a developer-specific estimate will have much greater results.

wppick 5y ago

This is why it can be better to just -prioritize- without -estimating-. Make sure you clearly and strategically prioritize the work to do, and plan for continuous delivery, or release milestones. Assume that your engineers will work just as fast as if they made inaccurate estimates (keep in mind overestimates might result in engineers slacking off to fill the over estimated time). You can always look at the work that engineers deliver, see how long it took them, and senior engineers will be able to tell if that engineer spent a reasonable amount of time for that task. You could call this post-estimates vs traditional pre-estimates. So tl;dr: just do good prioritizing and do post-estimates to gauge whether people are slacking off

aahortwwy 5y ago
Found the Taylorist. Estimates are there to help you forecast what you can get done within a particular time period, which in turn helps you prioritize units of work. Using them as post-hoc commitments and second-guessing your team is toxic.
- ebiester 5y ago
  Agree and disagree. I agree as a default scenario, you are correct. However, we always need evidence to show if a team member is struggling and needs extra assistance, or in the worst case is not contributing positively to the team. This is not over a single blown estimate but rather a larger pattern of underperformance. This is the failure mode, however.
- wppick 5y ago
  Will have to read more about Taylorism, thanks for putting this on my radar. I can see how the post reviews could be toxic, but pre estimates could also be toxic especially if estimates suddenly become hard deadlines. I think it comes down to nuance in both cases. Post estimates could tie into performance reviews and bonus allocation as well. Where your bonus and performance would be a tight feedback loop, and determined by multiple peers vs. a single manager. It really depends on each individual org which way works best
  - aahortwwy 5y ago
    > Post estimates could tie into performance reviews and bonus allocation as well. Now your colleagues aren't estimating the task, they're estimating the post-estimate. I'd suggest adding Goodhart's Law to your reading list as well. Every single time I've seen estimates tied to anything performance related they've been actively gamed and lost their utility as a forecasting device.