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

131–140 of 300 posts

Re: Story points are pointless, measure queues

#131

Post by jksmith »

buescher wrote: post #33
bsder wrote: post #19

Earlier quoted context omitted.

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.

Reinertsen's books are very, very good. The most recent and most up-to-date is Principles of Product Development Flow, which that chart came from. The previous one, Managing the Design Factory, is pretty similar and I think it's a better read. Another great takeaway from it is to prioritize things by cost of delay, or even better, what he calls Weighted Shortest Job First, where you divide the cost of delay by the ex…

Yes, and WSJF gives you two units of data: priority and sequencing - because everybody's pet is priority 1. Much better than MoSCoW.

Re: Story points are pointless, measure queues

#132

Post by jksmith »

immibis wrote: post #20
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."

Eisenhower. Here's another from the great philosopher Mike Tyson: "Everybody has a plan until they get punched in the face."

Point being, have a continuously ready backlog consumed by short iterations with great telemetry - like SpaceX.

Re: Story points are pointless, measure queues

#133

Post by jksmith »

JohnAaronNelson wrote: post #118
wsc981 wrote: post #87

Just estimate time. In the end, whenever I worked with story points in various companies, even though developers, Project Managers or Scrum Masters would often state that Story Points are a measure of complexity, in the end, the Velocity for a given sprint was measured in Story Points as well. So, in the end a Story Point is equal to an amount of time in a sprint. This is also stated in the article: > Story points do…

The real question is “how to get shit done”? Scrum, agile, safe, etc.. are ways to get shit done that all target the measurement. Estimations are that measurement. The nugget from this article that seems to missed by many is the subtle but strong advocacy for XP style Mob/Pair programming.

Say no to SAFe. It's a middle-management orgy of mediocrity.

Re: Story points are pointless, measure queues

#137

Post by vitus »

bsder wrote: post #19
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.

The shape is about right for the variance of the M/M/1 queue (what is an M/M/1/∞ queue??), but it's a little disingenuous since variance is a higher-order moment. Standard deviation is probably more sensible to think about here, since that brings it back down to the same scale as the queue length.

> Thus the average number of customers in the system is ρ/(1 − ρ) and the variance of number of customers in the system is ρ/(1 − ρ)². This result holds for any work conserving service regime, such as processor sharing.

https://en.wikipedia.org/wiki/M/M/1_queue#Average_number_of_...

In the cited example, going from 75% utilization -> 95% utilization drags your standard deviation from a modest 3.5 items in the queue all the way up to 19.5 items. And, in both cases, that's not far off from your average queue length, either.

Re: Story points are pointless, measure queues

#138

Post by brightball »

aetherspawn wrote: post #79

I am reading this slowly and there’s some good stuff in here, but it’s really long and I don’t have 1-2hrs to sit down and read it properly. I liked the suggestion of having a dedicated architecture team to break things down into work items. Comment your favourite parts/highlights?

I struggled with the length but couldn’t find a good way to shorten it more unfortunately. That’s the main reason I included a TLDR.

Thanks for giving it your time though.

Re: Story points are pointless, measure queues

#139

Post by tbrownaw »

happytoexplain wrote: post #89
vannevar wrote: post #74

Earlier quoted context omitted.

>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 operational load outside of development work). If your measure of the utility of story points is how well they help you estimate time, then you're right, they're useless to you. If you…

>back-of-the-envelope way to estimate which bits of validated functionality you're going to be able to get into the codebase this sprint >help you estimate time How are these different?

The assumption is that it's already unreasonable to expect developers to estimate how many hours something will take, and then due to meetings and such it's effectively impossible for them to then those already bad numbers into calendar days. So instead, the proper answer is to bypass all that by having developers estimate in made-up units that can be added up and trivially converted into calendar days.

Re: Story points are pointless, measure queues

#140

Post by SoftTalker »

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 haven't done story points estimating in years, but at the time, an 8 was rarely acceptable, a 13 surely was not. Estimates that high were basically saying "this story is too big or too poorly defined to estimate accurately" and we'd try to break it down into several stories of 5 points or less.

The vast majority of our stories were 2, 3, or 5 points.

Post reply on HN