Hacker News Reader

Comment by iraldir | Hacker News Reader

I believe this is the reason why scrum uses story points instead of time estimate. By putting uncertainty on the same level as effort, you give it more weight. And using a fibonacci sequence rather than a continuous amount with the rule you should round up if unsure tend to correct those defects.

View on HN

If regular time estimation has tricky statistical properties when combining multiple estimates, story point estimation is just hopeless. Especially on a Fibonacci scale. When estimating, nobody thinks that an 8-point story is the same as eight 1-point stories. Even the metric itself is nonlinear!

I push back pretty hard on story points whenever I see them. They’re not useful until several iterations in, once you have a baseline for how many points can be delivered in an iteration, and even then one developer’s 1 point story is another’s 5 point.

When estimating I tend to use a coarse scale of hours, days, weeks, and (in extreme cases) months. All estimates then get turned into a range between the minimum and maximum the estimate could mean - for example hours becomes 1 hour to 8 hours, days becomes 1 day to 5 days, and so on.

Anything estimated as weeks or months probably needs scoping until it can be broken down into tasks that will take between an hour and a week.

I find this method works well because it’s intuitive, comes out with a suitable amount of uncertainty relative to the size of the task, and finally results in estimates with units that are useful to project managers and the wider business in scheduling other work needed to get a feature into production.

Yeah in my experience everyone just mentally translates to time anyway so it is pointless. "11 points, that's about 2 days right?"

If you want to make the uncertainty clear it's better to allow ranges, like 2h-5d instead of trying to play stupid mind games.

Story points are like setting your watch 5 mins early so you are on time to things. It doesn't work.

That happens indeed, but the point (!) stands: the fibonacci scale ensures estimates are rounded up, and that small abstraction merges time and complexity into a single number, whereas it feels more difficult to bump a time estimate based on unknowns/complexity.

That's what happens, its all tranlated to hours and cost instantly. I have seen that at several places during poker sessions. The fun starts when management hears this and starts to calculate with it.

there is an uncharitable response to this thread, which is marked dead. I do think there is a kernel of truth in that response, which is nothing more than mocking.

why fibonacci? I think it's reasonable to say time includes an exponential error. an estimated 1 hour task is very different than an estimated 1 week task. i see that 1 hour, 1 day and 1 week estimates are progressively, and likely exponentially, worse.

Is it just the ease of doing the math? (totally reasonable answer, in my humble opinion). or is there something specific about fibonacci that's actually relevant? I think it's the former not the latter. but if you have any evidence to the contrary, i'd love to hear it.

The kernel of truth of that response is that you won't get more certainty about an estimate by adding more uncertainty, no matter in how much pseudo-scientific cargo-culting mumbo-jumbo you cloak it. (Unfortunately, HN readers don't really like sarcastic commentary which requires reader to think it through. Time is precious, and we just want to be coddled, give me your opinion ELI8 straight, because there is no time to think!)

I think you're half right. adding an error band to a far out estimate won't give you a better estimate, but it might help tell you how much you _don't know_ about what you're facing.

Cumulative error is _hard_. see weather prediction.

The reason the Fibonacci sequence is used is because we don't think in an incremental scale but in a logarithm scale. In other words, we think that some simple takes 1 day, a more complex takes 3 and a even more complex takes 5 days. Usually we don't jump from 1 to 2 days when thinking about a task effort.

You could have also used approximately logarithmic scale that everybody is familiar with, namely, cash! You know, 1,2,5,10,20,50,100,200,500..

But no, here we are doing science, that's why we use Fibonacci, hey even plants and rabbits are using it.

I kinda want to grab you by the lapels and re-enact that part from Clear and Present Danger. It doesn't matter what's true, it matters what i can prove!

Unfortunately, the phrasing would be more like, It doesn't matter what's true, it matters what i can sell to management.

In the absence of evidence to the contrary, i think i'm ready to take a side close to yours. It's useful to expand error bars exponentially as you move away from the time of the estimate, but there's nothing special about fibonacci.

> Unfortunately, the phrasing would be more like, It doesn't matter what's true, it matters what i can sell to management.

Yes, that's my main beef with it. SCRUM could be based on science, but sadly, it isn't. Here's an interesting book: https://www.amazon.com/Making-Software-Really-Works-Believe/...

The reason my team uses Fibonacci is that it cuts down on the “is this a 3, 4, 5, or 6 point ticket?” discussion. Each larger value should have more uncertainty, so there isn’t any point in getting more precise. Not being able to argue over 1 point differences but having to choose between 5, 8, and 13 has a clarifying effect on the process.

It is very easy to answer. Different people have different efficiency, therefore, a task completion does not depend solely on its complexity but also on who is executing it.

You should think about it (even though there are no actual physical units you can use to make this work):

Time to deliver a task = complexity / developer efficiency

This is why it is hard to develop a method to estimate time for development tasks.

Reply on news.ycombinator.com