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

Story points are pointless, measure queues

brightball.com

Post reply on HN
Print view View original

11–20 of 300 posts

Re: Story points are pointless, measure queues

#11

Post by bboygravity »

quantified wrote: post #2

Story points were only ever an approximate unit of time. To fit them into a clear unit of time such as a sprint is a clear indicator of this. To call them complexity or anything else is misleading- transcribing a dictionary by hand into a CSV file is super simple (1 pt) and takes a long time (how many points is 3 FTE-months in your calibration?). Eatimating effort-time vs completion time are quite different, serving…

I just don't get what the new terminology is for. Like how is this helping anybody?

Manhours = story points Task = story Subtask = sprint Upcoming tasks = backlog Task turn around time = ?? Project goal(s) = epic(s)

I'm probably not even doing this right, but what are we doing here anyway?!

It gets real fun when the project involves software/firmware + mechanical engineering (think machines, robotics, etc), gotta love their faces when you teach them the special magic advanced project words for special software people.

Re: Story points are pointless, measure queues

#12

Post by ooterness »

As someone looking at algorithms for managing buffer bloat, this resonates.

In IP routers, the goal is to keep the congested link busy. i.e., Idle time from a momentary hiccup is wasted time. You need a small buffer to do this, but piling on more data adds latency without actually doing any good.

Algorithms like CoDel realized that a lot of previous attempts to make this were noisy as heck. Minimum latency through the queue is the signal that makes sense. Everything else is misleading or gives inaccurate predictions. Why should it be any different for managing tasks for human workers?

[1] https://en.wikipedia.org/wiki/CoDel

Re: Story points are pointless, measure queues

#13

Post by mikeocool »

Given the size of my scroll bar, I rate reading this article a 13. My PM has decided I shouldn't bother reading it, as the likely value isn't worth the effort, because whenever we take on a 13, it ends up dragging on for like 4 sprints, and preventing a lot of other higher value/lower effort stuff from getting done.

Maybe at some point in the future, we'll break the article and have a few people on the team each read it part of it for lower effort, and then synthesize their take aways.

Re: Story points are pointless, measure queues

#14

Post by throw310822 »

ozim wrote: post #10
andrewstuart2 wrote: post #4

Story points aren't time (as OP states). They're relative complexity, and uncertainty (hence the fibbonacci sequence building uncertainty in to larger numbers). And stories should be able to sized as big numbers. I've never been on a team comfortable with more than a 7, at least not since my first agile experience where we all took an agile/scrum training together for a few days. We'd frequently give things like 21 o…

I agree - just countless times I have to beat that up into peoples head and even people who I would consider smart "points time". After the sprint you can kind of infer the time but it should not be guideline for next estimations unless these are tasks like "fix typos".

If they're not time, why use numbers? Use fruits: easy peasy, it's a lemon. A really tough story, a coconut. You can't add them in any case, because they're not time.

Re: Story points are pointless, measure queues

#15

Post by ozim »

quantified wrote: post #2

Story points were only ever an approximate unit of time. To fit them into a clear unit of time such as a sprint is a clear indicator of this. To call them complexity or anything else is misleading- transcribing a dictionary by hand into a CSV file is super simple (1 pt) and takes a long time (how many points is 3 FTE-months in your calibration?). Eatimating effort-time vs completion time are quite different, serving…

But you have !sprints! and if you have laptop crunched you either have other dev taking over - so something else doesn't get done - or story that dev with crunched laptop is not going to deliver. That's just life and I also understand how disconnected management can be - but a lot of time you cannot say "exactly" when something will be done, because that is just not possible.

Re: Story points are pointless, measure queues

#16

Post by wewtyflakes »

ozim wrote: post #10
andrewstuart2 wrote: post #4

Story points aren't time (as OP states). They're relative complexity, and uncertainty (hence the fibbonacci sequence building uncertainty in to larger numbers). And stories should be able to sized as big numbers. I've never been on a team comfortable with more than a 7, at least not since my first agile experience where we all took an agile/scrum training together for a few days. We'd frequently give things like 21 o…

I agree - just countless times I have to beat that up into peoples head and even people who I would consider smart "points time". After the sprint you can kind of infer the time but it should not be guideline for next estimations unless these are tasks like "fix typos".

Ultimately, we are bound by time, not complexity. Why does it matter how complex a task is? The product managers and customers wont care how hard we as engineers have to think or reason about a problem; to them, the only thing that matters is time until delivery.

Re: Story points are pointless, measure queues

#17

Post by ozim »

throw310822 wrote: post #14
ozim wrote: post #10

Earlier quoted context omitted.

I agree - just countless times I have to beat that up into peoples head and even people who I would consider smart "points time". After the sprint you can kind of infer the time but it should not be guideline for next estimations unless these are tasks like "fix typos".

If they're not time, why use numbers? Use fruits: easy peasy, it's a lemon. A really tough story, a coconut. You can't add them in any case, because they're not time.

That is one of the complications - one thinks developers should be smart as in abstract thinking so they should understand (just like all the other numbers humanity made up): "numbers we call story points are not having property to add them and they are not convertible to time".

*Properties of Whole Numbers:

    Whole numbers are closed under addition and multiplication.
    Zero is the additive identity element of the whole numbers.
    1 is the multiplicative identity element.
    It obeys the commutative and associative property of addition and multiplication.
    It satisfies the distributive property of multiplication over addition and vice versa.
*

Re: Story points are pointless, measure queues

#18

Post by egeozcan »

Story points are pointless on their own, but estimation meetings are invaluable. In those meetings, story points serve as shortcuts for expressing gut feelings. However, after the meetings, they become completely useless, and even harmful, because, as the article mentions, people start treating them like precise numbers and do arithmetic with them.

Re: Story points are pointless, measure queues

#19

Post by bsder »

KothuRoti wrote: post #7

My personal experience with story points is that the number never really mattered, but the process of the team discussing how to rate the complexity of a task was very useful. In terms of having utility of estimating how long something will take, I personally have never been able to translate story points into a reliable indicator for that for many reasons (e.g team changing, domain changing, variability in operation…

In addition, I like the whole "Full Queues Amplify Variability" chart.

It's intuitively obvious, but I never realized it was that bad.

I'm going to have to run that down and see if it's actually backed by real data. Too many business books are complete flimflam.

Re: Story points are pointless, measure queues

#20

Post by immibis »

KothuRoti wrote: post #7

My personal experience with story points is that the number never really mattered, but the process of the team discussing how to rate the complexity of a task was very useful. In terms of having utility of estimating how long something will take, I personally have never been able to translate story points into a reliable indicator for that for many reasons (e.g team changing, domain changing, variability in operation…

"Plans are useless, but planning is indispensable."
Post reply on HN