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

221–230 of 300 posts

Re: Story points are pointless, measure queues

#221

Post by convolvatron »

gregors wrote: post #201
hnthrow289570 wrote: post #60

Earlier quoted context omitted.

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 th…

The problem with your kitchen sink example is that you'd think that they've unclogged 7k kitchen sinks so that they can you give you a great estimate. If we've built the same software before ....we wouldn't have to build anything we'd just use the previously built software. Software isn't built like a kitchen but by exploring an infinite list of design choices and then choosing one way and implementing it ..hopefully…

this is nonsensical. first of all more programming these days is hardly invegigative, it is literally plumbing. attach this service this queue. translate this request to this api. compile this code under a new version. put this thing in a container.

secondly, and I've done alot of this, its entirely possible to build useful estimates around greenfield projects like 'define a new language', even though there are lots of variables in play. one useful technique is to work backwards. 'if we dont have a working draft spec in 2 weeks then we can really start the parser, so we're gonna say that, and if we cant hit it, we know we're in trouble'

if your ability to assign semantics and use your experience to plan out the work stops at 'horse drawn weheelie-do', i wonder if this is the right profression for you.

if as a culture we just throw up our hands 'whelp, its all unknowable, we'll just do the best we can and thats you can ask for', then we cant really criticize our customers for being frustrated with us and not 'appreciating our brilliance and how hard this is'.

and the truth is, we can and have done better than that.

Re: Story points are pointless, measure queues

#222

Post by arcbyte »

I don't understand people like this author. I guess I do. It's all marketing flamebait to get attention.

He knows exactly what story points are, he goes through them exhaustive, but strangely deriding them the whole time.

Then he concludes by purporting to invent the very practice you ALWAYS were supposed to have been doing to make story points work. You have to find a set of repeatable work to compare new stories to for reference. That's the whole game. That's his tasks "idea". That has always been part of every implementation and lesson on story points ive been exposed to.

It's a completely nonsensical article.

Story points have always been about queues and implementing Little's Law. Always.

Yes, it sucks to be on teams that just argue about points and don't work to refer to standard architectures for building blocks. That doesn't mean story points are broken, it's pointing out something else in your organization is broken.

A lot of real criticism in this comment, but props to the author for writing at least. It's more than I do as a part time internet complainer.

Re: Story points are pointless, measure queues

#223

Post by monkeynotes »

I don't really understand why the author needed to use all those words to suggest t-shirt sizes instead of story points.

All the stuff about breaking down tasks, watching a backlog queue to monitor cadence, and have regular meetings is already happening with, or without story points.

People overthink this stuff all the time. Every team should figure out what works best for them, even down to project by project. Getting shit done isn't hard to monitor. You have a bucket of well defined tasks, have sprint meetings, look for blockers and assumptions, watch work flowing through. It's not really that difficult. Whether you use story points or some other estimation tool is really just an exercise of calibration, it's not gospel. The estimation process is the important thing, discuss as a team, agree on complexity, make sure the task is bite sized etc.

Re: Story points are pointless, measure queues

#224

Post by jon-wood »

SoftTalker wrote: post #119
wolpoli wrote: post #80

Earlier quoted context omitted.

> My personal preference is to use time estimates with some uncertainty. A day or less. 2-3 days. A week at most. In the project management world, there is an assumption that tasks that are overestimated and underestimated would even themselves out so that the total estimate would equal the actual time needed. Sad to say that accuracy of estimates don't follow normal distribution in software development.

I had one manager who used time in orders of magnitude. He’d ask, “is it a day, a week, a month, or a year?”

I've done exactly this in the past, and then when someone asks how long the project as a whole is going to take it's easy enough to give a range. If someone says a task is going to take hours that's a range of 1-6 hours, if they say it's months that's 1-12 months. If you want more certainty in your estimate then you're going to have to give us some time to break things down.

Re: Story points are pointless, measure queues

#225

Post by NoMoreNicksLeft »

lll-o-lll wrote: post #106
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…

Having worked where a megacorp attempted to normalise points and incentivise velocity, there is a fatal flaw. The people doing the work estimate the size of the work! Increased “velocity” will happen automatically. Actual work throughput will remain the same. Prediction becomes impossible. The most damning problem with “points” is that you can’t even do basic math with them. Does 4 points take twice as long as 2? No,…

My team needs to get 17 points done daily, but no-shows-no-calls keep kneecapping efforts. When they do show up, they complain incessantly about how management makes everything a 0.5 no matter the list of features in the story, and why can't they get more than 29 hours a week so they can have insurance. But it's attitudes like that which keep them from getting raises on their yearly performance reviews. It's a good thing scrum was invented so we could finally measure the consistent low performance of you computer science nerds.

Re: Story points are pointless, measure queues

#226

Post by [deleted] »

khalladay wrote: post #64
shrimp_emoji wrote: post #36

Earlier quoted context omitted.

> I personally have never been able to translate story points into a reliable indicator You haven't discovered the secret formula: make your estimate and then mindlessly triple it.

multiplying estimates by PI has proven to be a scarily accurate rule of thumb over the course of my career.

[deleted]

Re: Story points are pointless, measure queues

#227

Post by egeozcan »

andirk wrote: post #96
egeozcan wrote: post #18

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.

Much like one huge difference between string "42" and the number 42 is that the latter can have math done to it. If you want to avoid the arithmetic, label tasks with words like "simple", "small", "quick", or my favorite "Won't fix".

> Much like one huge difference between string "42" and the number 42 is that the latter can have math done to it

I actually agree with your comment but this part made me laugh out loud because JavaScript :) ("42" - 1 === 41 but "42" + 1 === "421")

Re: Story points are pointless, measure queues

#228

Post by brightball »

arcbyte wrote: post #222

I don't understand people like this author. I guess I do. It's all marketing flamebait to get attention. He knows exactly what story points are, he goes through them exhaustive, but strangely deriding them the whole time. Then he concludes by purporting to invent the very practice you ALWAYS were supposed to have been doing to make story points work. You have to find a set of repeatable work to compare new stories to…

I can see that perspective I suppose, but it's certainly not marketing flame bait.

Whatever story ports were always supposed to be, they aren't. Numerous people's real world experiences go sideways, because of the way that they are designed. You're setup for failure and confusion.

I never claimed to invent anything. I'm highlighting Donald Reinertsen's work that more people should be following.

The purpose of the article is to remind people of why everything is broken so that they can identify it and fix it, including examples.

Re: Story points are pointless, measure queues

#229

Post by brightball »

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…

That's a very healthy approach to it and deserves applause. Kudos.

The goal of mobbing around task breakdowns is to drive the communication and building that shared understanding. Just with an output of writing most of it down in a way that makes it easy to track progress and approximate the size at the same time.

Re: Story points are pointless, measure queues

#230

Post by brightball »

urban_winter wrote: post #168
vladgiverts wrote: post #165

Earlier quoted context omitted.

I used story points for years with my teams and they worked "as advertised", which is they helped the teams understand the effort, complexity and risk for each story involved. When there was disagreement, it helped them dig deeper to understand why and usually reveal somebody's incorrect assumptions. It helped make sure teams didn't overcommit to the amount of stories they stuffed into a sprint and avoid either burni…

Absolutely my experience too. Story points have been an effective tool for me with multiple teams in several different companies over the past two decades. They aren't, by themselves, the complete answer to any problem - they need to be applied within the context of a healthy team and engineering culture. And some senior management persistently misunderstand them and want to do insane things like compare velocities b…

Healthy engineering culture is a cure for many, many issues.
Post reply on HN