Hacker News Reader

Comment by delichon | Hacker News Reader

We had a backlog grooming meeting yesterday. The boss asked me to estimate a task that was a bug fix for some code I am completely unfamiliar with. If I had a dollar for every time that has happened I think I could buy a used jet ski in good condition. So I did the usual thing. I told her that I didn't know how long it would take. Then she said ok, then this is a task to estimate the size of the bug fix task, how long will that take. Rather than continue to struggle I said "I'm about to lie to you" and then pulled a (Fibonacci) number out of my butt. That was enough to make her happy and we moved on. I'll give it my best effort and there will never be any accountability for my stinky estimate.

This has been my general experience with agile as practiced at three different outfits.

View on HN

This is my pet peeve with Jira culture. Estimates are always exact. You were forced to estimate 15±0 instead of 1-50 which would be a true reflection of your uncertainty.

I have yet to see a project management tool that even lets you write down uncertainty.

I use my own Excel sheet that calculates project risk from each task using a formula based on:

Estimated hours, in whole hour increments (i.e. 1 hour is the minimum allowed estimate). Usually you’d then multiply the engineering estimate by 3 to get something more realistic.

Uncertainty of the estimate, with a scale of 1 to 3, where 1 is “I’ve done this before and have a very good idea of how long it takes” and 3 is “I have no idea and making my best guess”

Impact to the project if it doesn’t get done in time on a scale of 1 to 3, where 1 is a small impact and 3 is high

Then the Exposure which is simply Uncertainty * Impact.

This method highlights the most critical areas so at least people can get an idea of when we’re entering into uncharted waters and to expect more possible delays.

An issue still unaddressed is that when you estimate 40 hours for something, management thinks “ok, great, it will be done in one week”, and then proceed to bury you in emails and meetings completely unrelated to the project.

Care to share the sheet? It sounds like it uses a good mix of parameters.

IIRC LiquidPlanner models uncertainty.

I've been around a bit while contracting and have experienced about 15 organisations, a handful of which did not estimate work except the occasional natural tendency of one engineer to say to another "this seems a bit big". That group that doesn't insist on boilerplate agile ritual is way more effective. The trouble is that some manager or another higher up the chain will assume time and motion studies on tech can be done locally (or at all) demands a dashboard of what is essentially made up information about what kind of work the organisation is doing.

Agile per se isn't killing software innovation: training non-technical people who have no concept whatsoever of what's going on and then insisting they invent arbitrary funny money to express work size.

The ideal way to resist this appears to emerge naturally in most even vaguely experienced engineers: double your estimates.

Taylorism was bullshit in its original form too. I had a history professor in graduate school whose PhD/book was about this. I can try to find it if you’re interested.

I'm incredibly interested as it happens. I had honestly never questioned it before and I'm fascinated.

Hm, the book is about Taylorism from 1945 on it seems, but it’s Stephen Waring, Taylorism Transformed: Scientific Management Theory since 1945. Looks like it was published by UNC Press 1991.

I do remember conversations with him to the effect that Taylorism ab initio was as much ideological in aim as seeking efficiency, but (1) that’s obviously his view (though a considered one after studying the sources) and (2) I don’t have any citations I could give you to support that beyond vaguely recalled conversations after class.

Let’s be honest. Your boss asked a reasonable question and your answer could have been something like “I need a day to familiarize myself with the code so I can give a rough but reasonable estimate. Also, I apologize I and the team fucked up by not sharing knowledge properly with each other and letting knowledge islands emerge”

You are very good at this. Without even knowing what the code is about you are able to discern that it would take me about a day to get to sufficient familiarity. Meanwhile I, who have been working on the project for twelve years and wrote most of it, still don't know. Are you available as a mentor?

So you worked for twelve years on that code base and you still don’t know how to estimate a bug fix? There seem to be other problems then.

And you are right, I don’t know anything about that code base, certainly not enough to know if estimates should be easy or not. But the fact that they aren’t is a sign of problems either way.

And I stand by my point that your boss’ question is reasonable, and the team should do some introspection to learn why such a fair question cannot be easily answered

I have seen bugs, in this project and several others, that range from actually "actually a feature" to both serious and unsolvable. Most of them are somewhere in the middle. But before knowing anything about the code or the bug, I can't tell where this task will land on that distribution. If you coerce an estimate out of me all I can do is guess the median value, which you can fill in without my help, while I go and work on the bug. Asking me for a number before I know anything about it is a waste of both of our time.

Why would you say the question is reasonable?

To me, it is not a reasonable question because there are so many assumptions smuggled in with it.

What assumptions are part of the entirely reasonable question “how long would it take to fix this bug?”

Reply on news.ycombinator.com