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

291–300 of 326 posts

Re: How I estimate work

#291

Post by crazygringo »

n4r9 wrote: post #277
crazygringo wrote: post #212

Earlier quoted context omitted.

Because, for whatever psychological reason, estimating in time leads to a false sense of accuracy, people pointlessly argue over whether something will take 5 days vs. 6, and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc. Estimating in points that are basically a Fibonacci sequence keep estimation precision limited and avoids implying false guarantees. Yes, in t…

Can't you do that by just limiting the precision? You can only vote 1, 2, 3, 5 or 8 days. Not sure what "points" are adding. As far as I can tell, it's an attempt to account for estimation difficulties by introducing a "velocity" concept. But I think it makes things more complex without actually solving the issue.

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 both team expectations and management expectations more reasonable.

Re: How I estimate work

#292

Post by HEmanZ »

cryptonector wrote: post #272
HEmanZ wrote: post #138

Whenever this comes up I feel like I work on completely different kinds of software than most people here. (Giant, backend, distributed systems projects at FAANG) I’ve never worked on anything large in software where the time it will take can be reasonably deduced at the accuracy some people here seem to assume possible. The amount of unknown-unknowns is always way way too large and the process of discovery itself ex…

I've worked on codebases all the way tens of millions of lines of code. Obviously not in the sense of knowing all the dusty corners of such codebases, but still, I did enough work on them that I had to navigate my way around millions of loc. It's not easy! The problem is that you can't possibly know even a sizeable fraction of such a codebase well. Instead you can know small corners well and know your way around the…

Did ZFS deliver on a tight timeline that was well established before any work began?

Re: How I estimate work

#293

Post by HEmanZ »

jkubicek wrote: post #245
HEmanZ wrote: post #138

Whenever this comes up I feel like I work on completely different kinds of software than most people here. (Giant, backend, distributed systems projects at FAANG) I’ve never worked on anything large in software where the time it will take can be reasonably deduced at the accuracy some people here seem to assume possible. The amount of unknown-unknowns is always way way too large and the process of discovery itself ex…

> what the contingency plans are if new work is discovered (reducing specific scope, moving more people (who are hopefully somewhat ramped up), moving out timelines) I think this is the most important. You can't just HAVE contingency plans, but you need to be clear in who you need to get approval / sign-off on those contingency plans and who you need to notify. As a developer, knowing that you're going to need to dro…

Yup, the whole chain of command needs to be bought in. All of this is not “in my head” but “well established with m1, m2, pm”

In my experience this is a really hard conversation and you have to build a lot of relationship/trust (aka politics) within the company to be direct about it. But it saves you and your team from burnout, because it eliminates the expectation of “if you fall behind you’ll work 80hrs/wk until the timeline is caught up” which is what I’ve seen happen too many times.

Re: How I estimate work

#294

Post by cainxinth »

When someone comes to me and says: “I need this project by this date,” I’ll look at the project and my calendar, and then say one of three things:

- “That seems doable, but I’ll let you know if any problems arise.”

- “That is going to be really tight. I’ll do my best, but if I think it can’t be done in that timeframe, I’ll let you know by the halfway point.”

- “I can’t get that done that fast. I’ll need more time.”

In the third case, when they follow up with “How much more?” I’ll give them a timeframe that fits the second case and includes the notification plan.

Re: How I estimate work

#295

Post by crazygringo »

mitthrowaway2 wrote: post #275
crazygringo wrote: post #258

Earlier quoted context omitted.

> 2-12d conveys a very different story than 6-8d. In agile, 6-8d is considered totally reasonable variance, while 2-12d simply isn't permitted. If that's the level of uncertainty -- i.e. people simply can't decide on points -- you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing once you have a more accurate estimate. You would never just blindly d…

If you measure how long a hundred "3-day tasks" actually take, in practice you'll find a range that is about 2-12. The variance doesn't end up getting de-risked. And it doesn't mean the 3-day estimate was a bad guess either. The error bars just tend to be about that big.

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.

You should not be getting 2-12 variance, unless it's a brand-new team working on a brand new project that is learning how to do everything for the first time. I can't count how many sprint meetings I've been in. That level of variance is not normal for the sizes of stories that fit into sprints.

Re: How I estimate work

#296

Post by mactavish88 »

xyzzy123 wrote: post #254
mactavish88 wrote: post #110

Earlier quoted context omitted.

The exact same way you'd treat any other investment decision. In the real world, if you've got $100k, you could choose to invest all of it into project A, or all into project B, or perhaps start both and kill whichever one isn't looking promising. You'd need to weigh that against the potential returns you'd get from investing all or part of that money into equities, bonds, or just keeping it in cash.

You mean… by making a forward-looking estimates of cost, time-to-value, return? (even if it's implicit, not documented, vibes-based?). When devs refuse to estimate, it just pushes the estimating up the org chart. Execs still have to commit resources and do sequencing. They’ll just do it with less information.

What you're asking is the equivalent of going to a company whose equity you've bought and asking them: what's the price going to be in 6 months' time?

Re: How I estimate work

#297

Post by crazygringo »

Leherenn wrote: post #283
crazygringo wrote: post #258

Earlier quoted context omitted.

> 2-12d conveys a very different story than 6-8d. In agile, 6-8d is considered totally reasonable variance, while 2-12d simply isn't permitted. If that's the level of uncertainty -- i.e. people simply can't decide on points -- you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing once you have a more accurate estimate. You would never just blindly d…

> you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing That's just too slow for business in my experience though. Rightly or wrongly, they want it now, not in a couple of sprints. So what we do is we put both the investigation and the implementation in the same sprint, use the top of the range for the implementation, and re-evaluate things mid-spri…

That's definitely one way of doing it! And totally valid.

I think it often depends a lot on who the stakeholders are and what their priorities are. If the particular feature is urgent then of course what you describe is common. But when the priority is to maximize the number of features you're delivering, I've found that the client often prefers to do the bounded investigation and then work on another feature that is better understood within the same sprint, then revisit the investigation results at the next meeting.

But yes -- nothing prevents you from making mid-sprint reevaluations.

Re: How I estimate work

#298

Post by crazygringo »

Magmalgebra wrote: post #276
crazygringo wrote: post #238

Earlier quoted context omitted.

> I've never met someone for whom points didn't eventually turn into a measurement of time The goal isn't to avoid time estimation completely, that would be crazy. People estimate how many points get delivered per sprint and sprints have fixed lengths of time. You can do the math, you're supposed to. The point is that points avoid a false sense of precision: https://news.ycombinator.com/item?id=46748310 The process i…

> The process is quite easy to implement Having implemented it myself, I agree it is easy to implement. My argument is that it is overly difficult to maintain . My experience is that incentives to corrupt the point system are too high for organizations to resist. Funnily enough - I work closely with a former director of engineering at Atlassian (the company whose guide you cite) and he is of the opinion that pointing…

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 if it improves productivity and planning. If so, you keep it. I've worked at several places that adopted it, to huge success, solving a number of problems. I've never once seen a place choose to stop it, or find something that worked better. If you have a citation that there is something that works better than points estimation, then please share!

It's just wisdom of the crowds, or two heads are better than one. Involving more people in making estimates, avoiding false precision, and surfacing disagreement -- how is that not going to result in higher-quality estimates?

Re: How I estimate work

#299

Post by cryptonector »

HEmanZ wrote: post #292
cryptonector wrote: post #272

Earlier quoted context omitted.

I've worked on codebases all the way tens of millions of lines of code. Obviously not in the sense of knowing all the dusty corners of such codebases, but still, I did enough work on them that I had to navigate my way around millions of loc. It's not easy! The problem is that you can't possibly know even a sizeable fraction of such a codebase well. Instead you can know small corners well and know your way around the…

Did ZFS deliver on a tight timeline that was well established before any work began?

That I wouldn't know, but I know it took longer than anticipated, and towards thee end Sun pulled a lot of engineers from other projects and put them on ZFS for the final push.

Re: How I estimate work

#300

Post by cryptonector »

tfrancisl wrote: post #284
jawns wrote: post #20

Here's my (somewhat tongue-in-cheek) rubric: - If it's an internal project (like migrating from one vendor to another, with no user impact) then it takes as long as I can convince my boss it is reasonable to take. - If it's a project with user impact (like adding a new feature) then it takes as long as the estimated ROI remains positive. - If it's a project that requires coordination with external parties (like a cli…

My issue with the second one is that, as an engineer, I am almost never the one trusted with managing ROI. In r&d this just means your product people expect delivery earlier and earlier, and will accept lower and lower quality if they think it has some return for the product.

Exactly. For many software projects ROI is just not measurable the way it is for more pedestrian products. Sometimes you can estimate the cost of replacing one product with another, and then you can estimate the "value" of enhancements to the current product that keep you from having to spend the cost of replacing it. Other times you can measure happiness of your product's users but not the ROI strictly defined. Other times you can say "this project enabled _that_ project, and that project has a measurable ROI, therefore so does _this_ project". You just can't count on always having a measurable ROI.

So far the only metric I've seen that works is KTLO fraction, where lower is better, because that means with the rest of the time you can be adding value, and that value is socially determinable by asking your peers and users. KTLO fraction can't be gamed because your peer managers will call you out on it if you try to cook it. To drive KTLO fraction down you also have to address tech debt that cause high KTLO fractions, and addressing that tech debt enables value-add because between spending less time on KTLO and having a cleaner architecture/design you enable the addition of valuable features.

Post reply on HN