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

311–320 of 326 posts

Re: How I estimate work

#311

Post by n4r9 »

xn wrote: post #289
n4r9 wrote: post #202

Earlier quoted context omitted.

What if the project involves trying one approach for a week, then assessing whether that approach still looks viable vs moving onto a different approach? This happens a lot with challenging projects, you basically just keep trying different things until one works.

Then you know that it's going to take at least, say two weeks, one week for the first implementation and a week to finish it if it works. On the high end, could it take more than 2 years? 1 year? 6 months? Stop when you are 80% confident that it won't take longer than some period. So your estimate might be between two weeks and six months. Is that an acceptable estimate for the "buyer"? If not, is it worth expending…

Yes, this is basically what happens. Except sometimes there's no realistic way to narrow the estimate. In research-focused teams you don't "scrap" a project that you can't break down. Instead you need to have a way to manage wide estimate windows.

Re: How I estimate work

#312

Post by cadamsdotcom »

This sort of stuff has parallels outside software - the book “how big things get done” is amazing, and one interesting thing it implies is that solar installations tend to go the best because they’re modular and lessons learned can be applied to the next phase of a project.

Whereas the worst overruns are nuclear power plants; which are either switched on and working, or completely useless and taking up space!

So my takeaways were: try to make estimates modular and work out how to carry learnings as your project goes on, and you’ll have an easier time hitting your estimates - and probably get a great reputation for delivering!

Re: How I estimate work

#313

Post by genghisjahn »

carefulfungi wrote: post #35
genghisjahn wrote: post #13

Earlier quoted context omitted.

Anyone from a sales roll care to speak to this?

Sales gets fired (or not paid) for missing their estimates (quotas, forecasts) and often have little empathy for engineering being unable to estimate accurately.

Are you in sales or have you ever worked in sales?

Re: How I estimate work

#314

Post by crazygringo »

mitthrowaway2 wrote: post #309
crazygringo wrote: post #295

Earlier quoted context omitted.

If a story-sized task takes 4x more effort than expected, something really went wrong. If it's blocked and it gets delayed then fine, but you can work on other stories in the meantime. I'm not saying it never happens, but the whole reason for the planning poker process is to surface the things that might turn a 3 point story into a 13 point story, with everyone around the table trying to imagine what could go wrong.…

Try systematically collecting some fine grained data comparing your team's initial time estimates against actual working time spent on each ticket. See what distribution you end up with. Make sure you account for how often someone comes back from working on a 3-point story and says "actually, after getting started on this it turned out to be four 3-point tasks rather than one, so I'm creating new tickets." Or "my fir…

That's literally what retrospectives are for. You do them at the end of every sprint.

Granted, they're point estimates not time estimates, but it's the same idea -- what was our velocity this sprint, what were the tickets that seemed easier than expected, what were the ones that seemed harder, how can we learn from this to be more accurate going forwards, and/or how do we improve our processes?

Your tone suggests you think you've found some flaw. You don't seem to realize this is explicitly part of sprints.

I'm describing my experiences with variances based on many, many, many sprints.

Re: How I estimate work

#315

Post by crazygringo »

Magmalgebra wrote: post #307
crazygringo wrote: post #298

Earlier quoted context omitted.

I guess my experiences are quite the opposite. Maintaining the process couldn't be easier. I don't even know what it means to "corrupt" points...? Or for points to become "dishonest"? I'm genuinely baffled. I'm not aware of any citations, just like I'm not aware of any citations for most common development practices. It seems to be justified more in a practical sense -- as a team or business, you try it out, and see…

By "dishonest" I'm saying they become measurements of time, which is what we were trying to avoid. Stepping back - my experience is that points are solving a problem good organizations don't have. The practice I see work well is that a senior person comes up with a high level plan fror a project with confidence intervals on timeline and quality and has it sanity checked by peers. Stakeholders understand the timeline…

> By "dishonest" I'm saying they become measurements of time, which is what we were trying to avoid.

On the one hand, they simply can't. They're a measurement of effort, and a junior dev will take more time to finish a story than a senior dev will. On the other hand, at the sprint velocity level, yes of course they're supposed to be equivalent to time, in the sense that they're what the team expects to be able to accomplish in the length of a sprint. That's not dishonest, that's the purpose.

> The practice I see work well is that a senior person comes up with a high level plan fror a project with confidence intervals on timeline and quality and has it sanity checked by peers... I just don't see what points do for me other than attempt to "measure velocity".

Right, so what happens with what you describe is that you're skipping the "wisdom of the crowds" part, estimation is done too quickly and not in enough depth, and you wind up significantly underestimating, and management keeps pushing the senior person to reduce they're estimates because there's no process behind them, and planning suffers because you're trying to order the backlog based on wishful thinking rather than good information.

What points estimation does is provide a process that aims to increase accuracy which can be used for better planning, in order to deliver the highest-priority features faster, and not waste time on longer features that go off track where nobody notices for weeks. Management can say, "can't they do it faster?", and you can explain, "we have a process for estimation and this is it." It's not any single employee's opinion, it's a process. This is huge.

> but the moment they treat it as a target engineers juice their numbers.

How? Management doesn't care about points delivered, they care about features delivered. There's nothing to "juice". Points are internal to a team, and used with stakeholders to measure the expected relative size of tasks, so tasks can be reprioritized. I've never seen sprint velocity turn into some kind of management target, it doesn't even make sense. I mean, I'm sure there's some dumb management out there that's tried it. But what you're describing isn't my experience even remotely.

Re: How I estimate work

#316

Post by crazygringo »

theonething wrote: post #249
crazygringo wrote: post #227

Earlier quoted context omitted.

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 me…

> The same way nobody finds writing tests or documentation fun I'm not sure if it's the fun category, but at least they are useful and because of that, satisfying to do. In fact when I finish a solid suite of tests or good, clear documentation, I find it very satisfying. I can't say the same for poker/estimation. I've found to be them a complete waste of time in every job I've had and therefore soul sucking. > you se…

> you're conflating the ability to estimate accurately with the ability to implement.

> Just because I can't estimate a task accurately doesn't mean I can't do it.

Most programmers could ultimately do anything... if given enough time.

But if they're going to do it professionally, you expect them to have some prior experience so they can do it somewhat efficiently. And if they have that experience, they should be able to estimate.

So yes, being able to estimate and being able to do (with reasonable professional efficiency), do tend to correlate, of course.

Re: How I estimate work

#317

Post by crazygringo »

n4r9 wrote: post #310
crazygringo wrote: post #291

Earlier quoted context omitted.

Let me repeat myself: > and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc. > But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep…

> and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc. > people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days Okay I think I'm with you. In my team, the PM pre-calculates the number of available days in the sprint per developer before taking any estimates, factoring…

> I guess points are kind of a crude way of doing the same thing.

Right. But you sound awfully judgmental in saying "crude". I'd call it robust, and not trying to produce some kind of false over-precision. In other words, appropriate to the task at hand.

Re: How I estimate work

#318

Post by mgfist »

Leherenn wrote: post #285
mgfist wrote: post #268

Earlier quoted context omitted.

My most productive team did no time estimates at all (short of very very rough project estimates i.e. "yeah I'll work on this project for at least the next quarter then we'll see"), and instead of spending endless time in planning meetings determining how complex a task was, we instead spent that time just doing the thing.

How did you align with other teams? I agree it's best if working in isolation, but if you need to synchronise then estimations make sense. If you need 3 months to implement something, and another team 1 week, and both need to be ready at the same time; then if you actually know those estimations the second team can wait until then and do something immediately useful in between.

Yes, then you must have a rough estimate for that. Or in the other extreme example - in the case of an outage, estimates must be much more precise (i.e. "we should have a workaround in ~30 minutes").

But neither case requires too much thought or discussion. My point was more that estimation ends up overwhelming time and energy, when you can just do the thing instead. I've worked on teams where we've spent more time arguing about how complex a task than it would've been for someone to crank out a solution.

I also don't mean engineers shouldn't collaborate, just that it should be more ad-hoc and not manager/tpm/scrum-master driven.

Re: How I estimate work

#319

Post by n4r9 »

crazygringo wrote: post #317
n4r9 wrote: post #310

Earlier quoted context omitted.

> and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc. > people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days Okay I think I'm with you. In my team, the PM pre-calculates the number of available days in the sprint per developer before taking any estimates, factoring…

> I guess points are kind of a crude way of doing the same thing. Right. But you sound awfully judgmental in saying "crude". I'd call it robust , and not trying to produce some kind of false over-precision. In other words, appropriate to the task at hand.

So how does your team adjust capacity planning in case of disruptions like annual leave, company all-hands days, public holidays etc... ? How do you figure out how many points to reduce by?

Re: How I estimate work

#320

Post by mysteryihs »

pan69 wrote: post #165
wreath wrote: post #159

What often baffles me with engineers and especially engineering managers is that they don't derive the estimates from metrics of prior projects, especially for long running teams (as opposed to project teams). You don't need to estimate down to the minute, but you already know how many tickets/work items the completes at a given time interval with how many people in the team etc. This should give a rough estimate of…

How long does it take to do a crossword puzzle or play a game of chess?

A different variation of the ol' how long is a piece of string question
Post reply on HN