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

51–60 of 300 posts

Re: Story points are pointless, measure queues

#51

Post by jurassicfoxy »

mikeocool wrote: post #13

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…

This article was not written for the reader, but written because the writer loves to hear himself write.

Re: Story points are pointless, measure queues

#52

Post by cassianoleal »

hnthrow289570 wrote: post #46
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…

The points are needed because it's convenient to do reports based off of it. If we used estimation language such as "easy, medium, hard, dummy-thicc" they'd still need to assign points to those labels so they can do math on reports and graphs to watch your performance The biggest sin of course is then trying to predict velocity, but the consequences of that usually just make people doing the reporting look silly for…

> No bonuses for higher velocity is the real reason no one takes it seriously.

Bonuses for higher velocity based on guessed story points would be an even bigger reason for not taking it seriously - or rather to overestimate everything in order to gain the impression of higher velocity and the bonus associated.

Re: Story points are pointless, measure queues

#53

Post by herpdyderp »

Unknoob wrote: post #30

Story points are in fact time, and I'm tired of pretending they're not. You can sugar coat it all you want and say they represent complexity, but at the end of the day(or sprint), the higher the complexity, the more time it takes to complete.

The problem therein is that that time depends on who is given the story. Perhaps that should be part of the estimation itself? (Who is working on it.)

Re: Story points are pointless, measure queues

#54

Post by psychoslave »

xn wrote: post #25

Estimate using time (hours, days, weeks, months, years). Reflect your uncertainty in your estimates using confidence intervals. If your confidence intervals are too wide, break down the work and estimate the smaller tasks and/or spend some time doing the work necessary to narrow your confidence intervals.

I can estimate rather accurately how much time it will take me to cook a meal assuming that:

- I already mastered the receipt as I prepared the very exact same one many times in the past

- I already checked that I have all the ingredients required at hand

- I will cook in my own kitchen

- no entropy engine (aka family members) was thrown before in the kitchen to put utensils in an other place than the place were I tidily store them (admittedly without conducting formal formation of the rest of the disruption forces)

- no one will interfere because the way I do it is not the super fancy other way in which it could also be done

- no external catastrophe happen which obviously need to be taken care of immediately, just at this point in recipe where by the time I will come back most of what I did so far will be better started again from scratch because the underlying laws of physics I was assuming so far changed so significantly that the left ongoing work is now utterly incompatible with the divergences that universe bumped to

Meanwhile, in the easier transparent stationary landscape of software development, whenever I came with a to-my-mind-credible estimate for a non trivial endeavor, it was systematically rejected and superseded by a soon-to-be-blown-away deadline.

Re: Story points are pointless, measure queues

#55

Post by icedchai »

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.

If you try this (and I have, just not with fruits), someone will complain they can't graph fruits. You'll tell them that's the point. They won't listen, so they'll map fruits to numbers, and now you have the same problem anyway.

My personal preference is to use time estimates with some uncertainty. A day or less. 2-3 days. A week at most.

Re: Story points are pointless, measure queues

#56

Post by JohnFen »

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…

This is my experience as well. Story points in and of themselves are worthless, but as an excuse to discuss the project as a team, they can have some value.

Re: Story points are pointless, measure queues

#57

Post by jmward01 »

The fundamental issue isn't addressed but it sure is hinted at. Scheduling is an NP problem. As queue size, or backlog, or (insert thing here that tracks work to be done) grows it takes n^p calculations to schedule it optimally. This is hit on when it mentions small teams hitting their estimates. They can do this because their task list is small enough to go through all the permutations and actually come up with an accurate estimate. The only way to keep an n^p problem under control is to divide and conquer it. The leafs of that process must not go beyond a fixed size and the task divisions can't be recombined prematurely. Everything else is just yet another management idea that that will fall apart when the task has too many pieces. Once agile or any other management methodology acknowledges the fundamental mathematics at the core of things I may actually take them more seriously.

Re: Story points are pointless, measure queues

#58

Post by T-zex »

What stops management from committing Feature A to be delivered after 250 tasks are completed? Yes the fact and the reasons that the Feature A expands to 500 will be documented, but who will care about it? This will still be a "delay" from the management point of view.

Re: Story points are pointless, measure queues

#59

Post by brayhite »

hnthrow289570 wrote: post #46
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…

The points are needed because it's convenient to do reports based off of it. If we used estimation language such as "easy, medium, hard, dummy-thicc" they'd still need to assign points to those labels so they can do math on reports and graphs to watch your performance The biggest sin of course is then trying to predict velocity, but the consequences of that usually just make people doing the reporting look silly for…

To your own point, the reports serve little value aside from a fabricated narrative that some companies like to build feel-goods around.

Discuss the complexities and needs. Break the work into small chunks. Define what progress means. Set expectations for making progress. Regularly and honestly review why you/the team are or aren’t meeting expectations. Rinse and repeat.

Perhaps this is over simplifying it, but these are the tried-and-true high notes in my experience. If at any point one of those steps isn’t feasible, then it’s a larger issue that implementation process likely isn’t going to solve, so the “to measure velocity or not” point seems moot.

Re: Story points are pointless, measure queues

#60

Post by hnthrow289570 »

cassianoleal wrote: post #52
hnthrow289570 wrote: post #46

Earlier quoted context omitted.

The points are needed because it's convenient to do reports based off of it. If we used estimation language such as "easy, medium, hard, dummy-thicc" they'd still need to assign points to those labels so they can do math on reports and graphs to watch your performance The biggest sin of course is then trying to predict velocity, but the consequences of that usually just make people doing the reporting look silly for…

> No bonuses for higher velocity is the real reason no one takes it seriously. Bonuses for higher velocity based on guessed story points would be an even bigger reason for not taking it seriously - or rather to overestimate everything in order to gain the impression of higher velocity and the bonus associated.

Non-developers might have to learn something about development so they can push back on inflated estimates, which honestly would be helpful to everyone.

If I quoted you $1,000 to unclog your kitchen sink trap, you'd call bullshit because you can probably find out how easy it is to do that. Likewise, if I quote you 13 points to add a generic error toast message because a POST went badly, you should call bullshit on that too.

Post reply on HN