Hacker News Reader

Comment by sizing | Hacker News Reader

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

View on HN

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.

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.

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

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.

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

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

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.

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.

Reply on news.ycombinator.com