Hacker News Reader

> * Ben, a junior dev, says a week. > > * Carol, a senior dev, new to the company, says 3 days. > > * Dara, a team veteran, say 1 day, at most.

Maybe it's just me, but usually the estimates get longer with seniority. It might take them as long as you said it would, but the stated length would probably be reversed, since the more senior employees can easily see the pitfalls and the required housekeeping that the task brings.

Hehe, as part of an onsite test I did back when I was doing Devs recruiting was to ask them to estimate how much would it take for them to finish the remaining part of the test (a 10 point programming challenge where they would usually finish 5 or 6 of the points; and each point was to implement certain aspect).

You could see someone was junior, when, after implementing 6 points in the 3 hour allocated, they say they would finish the remaining tasks in 1 or 2 hours. The people that were more senior, took a bit more of time to think about their estimates, given the knowledge they had gained during the past 3 hours, and usually they will give a 4 to 5 hour estimate.

The dangerous thing about inexperienced people doing estimates is that they have no idea of basis on where to do estimates from.

Heh, without knowing the details my default answer would be “I can’t tell you because I haven’t done it yet”

Estimation is a halting problem.

In my experience we take these estimations and have a conversation or set up a pair.

"Great, Ben and Dara can you handle this together?" To give Ben a chance to grow and Dara a chance to show leadership/mentorship/develop institutional knowledge.

Alternately: "Okay, a bit disparate. Dara (or whomever) how are you thinking about solving this?"

My experience:

“I think it will take 5 days but it’s complex and I’m not sure”

“It’s taking longer than I thought because it’s complex. But marketing isn’t ready so it’s not my top priority”

“Marketing still isn’t ready so I’ve deprioritised it”

“What do you mean ‘I promised 5 days and it’s entirely my fault it’s late?’”

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

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.

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.

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.

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.

How will the junior estimate the complexity of something he does not understand? Either too short or too long. So the difference is not that big between points and time.

Also, in all the teams I’ve been the devs had no problem using the points. The managers are the ones that force a link between points and days. In that case the author says: just use the days.

In practice it doesn't matter. Because t-shirts/Fibonacci just become a proxy for time anyway. Any abstract estimate you can dream up will become a measurement of time when it passes through management.

> The distance is independent of anyone's skills. The complexity of the task does not depend on how skilled you are, that's why we're using abstract units, to measure the size, not the time.

So what is the point then? We can abstract away distance. It doesn't help you cross that distance.

I like the distance metaphor, I hadn't read that one before! We estimate stories before any particular developer picks them up, so it's especially important to estimate complexity and not time.

I don't know if the author is being sarcastic but:

> To that, I propose base-2 exponentiation based on the scale you care about in the first place, time.

> 1, 2, 4, 8. Hours, days or weeks.

I think this is actually a pretty good system. The point being that estimates get less fine grained as the size of the task increases, which is pretty sensible.

Isn’t that why many teams opt to use Fibonacci sequence?

All this scrum bullshit is so fucked up. I've left a company just after a couple months because of 1) A terrible product manager and 2) A blindly by-the-book scrum process which led the project to a terrible state, worsening every day.