7 ms·

I agree that scrum is dumb but abstract size estimates are dumb too for the same reason. All that matters is time, and if time is variable per person then… reco

by sizing 5y ago

I agree that scrum is dumb but abstract size estimates are dumb too for the same reason. All that matters is time, and if time is variable per person then… record the time it would take per person. I have never worked in a team where sizing ever worked, because junior says large, senior says small, the facilitator settles on medium… and then the junior ends up doing it and takes twice as long as expected. Your anology assumes everyone knows where the building is, that they know how to run etc etc

ebiester 5y ago
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.
kcplate 5y ago
My problem with abstract estimates are as a product manager my dev team cannot seem to provide me a time measurement that will allow me to accurately bill my customers for custom feature requests to recoup development costs and hopefully make a little extra. So abstract estimates might be good for determine sprint velocities…and may be great for carving up releases, but they suck when you are doing custom modifications you need to accurately quote before the work begins. Because I also have a development background too, I just tend to look at custom features through through the lens of “how much time this feature would take me”, then add a few multipliers and cross my fingers that the faster and better devs pickup those stories so we don’t lose money.

by sizing 5y ago

ebiester 5y ago

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.

kcplate 5y ago

My problem with abstract estimates are as a product manager my dev team cannot seem to provide me a time measurement that will allow me to accurately bill my customers for custom feature requests to recoup development costs and hopefully make a little extra. So abstract estimates might be good for determine sprint velocities…and may be great for carving up releases, but they suck when you are doing custom modifications you need to accurately quote before the work begins. Because I also have a development background too, I just tend to look at custom features through through the lens of “how much time this feature would take me”, then add a few multipliers and cross my fingers that the faster and better devs pickup those stories so we don’t lose money.