Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I estimate work

seangoedecke.com

Post reply on HN
Print view View original

221–230 of 326 posts

Re: How I estimate work

#221

Post by zmj »

I was prepared to disagree with the thesis that estimation is impossible. I've had a decent record at predicting a project timeline that actually tracked with the actual development. I agree with the idea that most of the work is unknown, but it's bounded uncertainty: you can still assert "this blank space on the map is big enough to hold a wyvern, but not an adult dragon" and plan accordingly.

But the author's assessment of the role that estimates play in an organization also rings true. I've seen teams compare their estimates against their capacity, report that they can't do all this work; priorities and expected timelines don't change. Teams find a way to deliver through some combination of cutting scope or cutting corners.

The results are consistent with the author's estimation process - what's delivered is sized to fit the deadline. A better thesis might have been "estimates are useless"?

Re: How I estimate work

#222

Post by turdprincess »

samastur wrote: post #179
crazygringo wrote: post #174

Not a single mention of planning poker and story points? They're not perfect (nothing is), but they're actually pretty good. Every task has to be completable within a sprint. If it's not, you break it down until you have a part that you expect is. Everyone has to unanimously agree on how many points a particular story (task) is worth. The process of coming to unanimous agreement is the difficult part, and where the r…

I used to work for a company where we spent a day every 2 weeks doing this. And I had a headache at the end of the day every two weeks. Great that it works for you.

Same - my new team doesn’t do any scrum or story points and it’s an amazing breath of fresh air - don’t miss those days just yelling random numbers at the zoom call for hours.

The truth is on most teams one or two people who are closest to the task have enough context to estimate, and probably only after they spent some time starting or prototyping the task.

Those people can give a reasonable estimate, in time not some strange point system.

Sometimes the estimate is wrong and that’s ok.

It’s fine to have a meeting catching everyone else up on the context but those pther people still likely don’t have enough to give an accurate estimate and shouldn’t be involved in estimation

Re: How I estimate work

#224

Post by [deleted] »

stavros wrote: post #205
loloquwowndueo wrote: post #154

Earlier quoted context omitted.

If the competitor already has it why are you talking to me? :)

Because you have other benefits, so we'd really like to switch over to you, but we can't unless you support this dealbreaker feature that your competitor we're currently using has.

[deleted]

Re: How I estimate work

#225

Post by loloquwowndueo »

stavros wrote: post #205
loloquwowndueo wrote: post #154

Earlier quoted context omitted.

If the competitor already has it why are you talking to me? :)

Because you have other benefits, so we'd really like to switch over to you, but we can't unless you support this dealbreaker feature that your competitor we're currently using has.

No, parent said they’d go talk to the competitor. They didn’t say they were already with them. Don’t change the scenario.

Re: How I estimate work

#226

Post by andrewingram »

Ambiguity increasingly feels like the crux of estimation. By that I mean the extent to which you have a clear idea of what needs to be done before you start the work.

I do a lot of fussy UI finesse work, which on the surface are small changes, so people are tempted to give them small estimates. But they often take a while because you’re really learning what needs to be done as you’re doing it.

On the other end of the spectrum I’ve seen tickets that are very large in terms of the magnitude of the change, but very well specified and understood — so don’t actually take that long (the biggest bottleneck seems to be the need to break down the work into reviewable units).

In the LLM age, I think the ambiguity angle is going to much more apparent, as the raw size of the change becomes even less of an input into how long it takes.

Re: How I estimate work

#227

Post by crazygringo »

turdprincess wrote: post #222
samastur wrote: post #179

Earlier quoted context omitted.

I used to work for a company where we spent a day every 2 weeks doing this. And I had a headache at the end of the day every two weeks. Great that it works for you.

Same - my new team doesn’t do any scrum or story points and it’s an amazing breath of fresh air - don’t miss those days just yelling random numbers at the zoom call for hours. The truth is on most teams one or two people who are closest to the task have enough context to estimate, and probably only after they spent some time starting or prototyping the task. Those people can give a reasonable estimate, in time not so…

Let me be clear -- nobody finds planning poker or story estimation fun. The same way nobody finds writing tests or documentation fun. So of course it'll be a breath of fresh air if it's not part of your job.

But the fact remains that in most environments, it's extremely useful for medium-term planning and especially in surfacing high-risk features that can send people down the wrong path for a long time. And it's meant to benefit stakeholders -- the people paying the developers' salaries -- not individual developers. It's about de-risking.

And if you really have the kind of team you seem to describe where everybody only works on their specific type of task and can't even estimate anybody else's work, then that's a danger situation when they leave or get sick or whatever and nobody else can step in and everyone's blocked because the only person who can do X is gone. Usually, you should be actively getting other developers to work on these features (usually the easier/smaller ones) and involving them in the estimation.

Re: How I estimate work

#228

Post by bogeholm »

Fire-Dragon-DoL wrote: post #209
bogeholm wrote: post #203

Earlier quoted context omitted.

> The only moment time it makes sense is when you have a SHARED understanding of the smallest point AND you can translate it to time. When you do that, story points are useful. I’d like to disagree on that one. A single story point shouldn’t be translated to time, but should reflect the relative complexity between tasks (ie. a 7 is harder than a 3 and so on). You could assign relative complexity based on a number of…

An estimate is composed of two parts: - Time - Risk of being wrong When you do what you just said "I am not estimating time, I'm estimating risk". "This will take between 1 and 3 days" gives you both: the risk (complexity, hardness) which is represented by the gap, and time: how long it takes. When a non engineer asks for an estimate, they usually mean one of these two things: 1. How long it takes? 2. Have you had ex…

> For the first one, you CANNOT use what you just described, since it doesn't represent time, so you cannot give dates in any form.

Exactly - that’s the point.

Story points assigned to a SINGLE task is not for estimating time spent on that task.

Story points can - given prior data - give you an estimate of time spent on a GROUP of future tasks

Re: How I estimate work

#229

Post by shoo »

firefoxd wrote: post #168

We estimated a single sprint to move from our plain text passwords. Easy! Add a new field in the db for secure pass, and one to force password update. Update the api to take the new fields into account... It took 6 months. Why? Well it was a legacy app, and we learned that passwords were case insensitive because the customer sent a video of him entering his password that failed. On the video, we could see a sticky no…

Your story reminded me of Bent Flyvbjerg and Dan Gardner's book "How Big Things Get Done". It's a pop science book communicating the research of Flyvbjerg & collaborators who collected data of actual schedule & budget outcomes for many large projects, along with recording the estimated schedule and budgets from the time the go/nogo decision was made to invest in the projects.

For accurate schedule and budget estimates, Flyvbjerg strongly recommends figuring out which broader class of projects your project belongs to, then going and looking at accurate historical data with actual schedule and budget outcomes for projects in that class, and using historical averages as your estimates.

There's a great table in an appendix at the back of the book, offering statistics for each category of project, ranking them by mean cost overrun.

The absolute worst category of project, for mean cost overruns, is nuclear storage, with a mean cost overrun of 238%.

IT projects are the 5th worst category of project, with a mean cost overrun of 73%, behind nuclear storage, olympic games, nuclear power and hydroelectric dams.

The table also has statistics on "what percentage of projects has a cost overrun of 50% or greater" and "of those projects with a cost overrun of 50% or greater, what is their mean cost overrun". For nuclear storage projects, 48% of them have a cost overrun of 50% or greater, and of those, the mean cost overrun is 427% (!).

For IT projects, 18% of them have a cost overrun of 50% or greater, and of those, the mean cost overrun is 447% (!!).

Some of the chapters in the book discuss some of the structural or political pressures that set projects up to fail --- e.g. in some fields its an open secret that estimates are always wildly optimistic, as if the estimates were actually realistic, no one would ever agree to fund a project.

Re: How I estimate work

#230

Post by Gooblebrai »

crazygringo wrote: post #215
spike021 wrote: post #199

Earlier quoted context omitted.

I've been on teams that tried various methods of estimating and the issue I always encounter is that everyone estimates work differently, but usually people will side with the person with the most context. For instance someone says a ticket is two days' work. For half the team that could be four days because people are new to the team or haven't touched that codebase, etc. But because the person who knows the ticket…

Remember, estimation is in points not days. It doesn't matter if it's 2 days work for a senior engineer or 4 days for junior devs, it's still the same number of points, e.g. 8 points. This is intentional. Skill is accounted for in the fact that a team of all senior devs might deliver 200 points a sprint, whereas if half the senior devs got replaced with junior devs the team might only deliver 100. This is intentional…

"estimation is in points, not days" doesn't tell me anything. Is not like tasks have an intrinsic attribute that everyone can agree on (e.g. the sky is blue)

How are you estimating the points if not thinking about how hard the task is for you and how long is it going to take you?

And then another matter is that points do not correlate to who later takes that work. If you are 5 seniors and 3 juniors and average on a task being a 3, but the task falls to a junior, they will take longer as is expected for his experience.

Post reply on HN