Story points are pointless, measure queues • Hacker News Board

Re: Story points are pointless, measure queues

#171

Post by dilyevsky » Wed, Jul 17, 2024, 6:18 AM UTC

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?

They aren’t. I’ve seen this argument rehashed a thousand times - “we arent estimating time, just complexity so we can estimate how much we can do in a sprint. which is two weeks. wink wink”

Re: Story points are pointless, measure queues

#172

Post by dilyevsky » Wed, Jul 17, 2024, 6:21 AM UTC

tbrownaw wrote: post #139

happytoexplain wrote: post #89

Earlier quoted context omitted.

>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.

The assumption that anyone can estimate work they have never done with a reasonable degree of accuracy is just plain wrong. That is why management pretends they arent doing that either

Re: Story points are pointless, measure queues

#173

Post by avereveard » Wed, Jul 17, 2024, 6:22 AM UTC

Yeah sure everything eventually averages out with enough sampling, and maybe queue based forecast converge faster than velocity and point based forecast.

Why? Don't know, whole article reeks of gut feeling, which is strange as data should be available since the whole point of scrum masters is clerking things out.

The problem with a queue system is not in the averages tho, but in the exceptions: say sprint or project is late, which features give you the largest impact when moved around or canned? If the customer wants to reduce cost, how do you give visibility of feature effort? Or are we in the toxic agile version with fixed scope, cost and deadline? Because then just ditch the overhead and waterfall your way trough

OH and btw this system is not gaming resistant, people may pick the smaller task first to meet queue processing frequency, and then you'd get massive frequency drop at the end.

Re: Story points are pointless, measure queues

#174

Post by resonious » Wed, Jul 17, 2024, 6:35 AM UTC

The proposed queue system seems somewhat orthogonal to story points to me. You could easily do the queue thing with or without story points, or vice versa.

With the pure queue solution, you still need to make sure the tasks are all "small". The problem of defining "small" is the same problem that makes story points so unreliable and confusing. So I suspect the kicker here is just having a group of motivated and competent people.

Re: Story points are pointless, measure queues

#175

Post by hi_hi » Wed, Jul 17, 2024, 6:35 AM UTC

Too wrote: post #166

This article argues against story points but then concludes that the solution is breaking down work packages into atoms called tasks and measure the queue length. Those are two different dimensions. No matter how hard you try to break things down, a task queue will still have items in it with different sizes. There is nothing saying you can't refine work packages together in your team, while still using story points.…

The bit where it broke down for me was where they initially make the (great) point that agile falls down where small story points for simple tasks (which is accurate) are added to large story points for complex tasks (which is much less accurate), leading to a net inaccurate estimate. So the take away is to break down complex tasks.

Then they introduce queues, which are made up of small tasks.

I admit I stopped reading at this point. Is the useful thing the queue, or the fact everything is now broken down into small tasks?

Re: Story points are pointless, measure queues

#176

Post by usea » Wed, Jul 17, 2024, 6:45 AM UTC

drewcoo wrote: post #103

bboygravity wrote: post #11

Earlier quoted context omitted.

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

The idea was to not use direct measures of time to estimate because someone above you will start assuming those estimates are promises and then life gets unpleasant. Story points, much as I personally dislike them, were invented for developer defense.

I've never seen such systems emerge from the team as a tool for self-empowerment. They are always foisted upon the team by managers who are trying to, ultimately, turn estimates into promises.

Re: Story points are pointless, measure queues

#177

Post by skydhash » Wed, Jul 17, 2024, 6:52 AM UTC

roonyh wrote: post #160

Nathanba wrote: post #109

Earlier quoted context omitted.

if you are at a point where you employ such a factory throughput thinking for information workers then you're misusing information workers in my opinion. Focusing on a throughput metric is just as nonsensical as focusing on how many lines of code somebody creates, in fact, it's really astonishingly similar in how nonsensical it is. Bug reports, issues and features are not just lumps of coal that you need somebody wit…

ah, we are not using it as a measure of teams performance, like throughput though. Its just used to predict what the team can deliver in a sprint or a quarter etc and make business decisions based on that.

That is kinda the same thing. With story, it’s either we roughly know how to do it or we need to do some research. In te first case, estimates will be wrong because of edge cases and contextual differences.

Businesses decisions should be based on things like feature requests from customers, not the amount of “points“ a team can get done.

Re: Story points are pointless, measure queues

#178

Post by dilyevsky » Wed, Jul 17, 2024, 6:54 AM UTC

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…

All of these shenanigans are just dancing around the intractable problem which is - nobody ever figured out a way to produce reliable estimates.

Re: Story points are pointless, measure queues

#179

Post by skydhash » Wed, Jul 17, 2024, 6:59 AM UTC

bluefirebrand wrote: post #152

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…

> No one outside the scrum team should care about story points, and they certainly shouldn't be used to generate reports. Velocity is for the team's benefit, as a tool to help manage workload and schedule These two sentences are somewhat in conflict imo. Workload and schedule is tied into capacity planning and resourcing, which happens at a higher level than the scrum team. The people having those conversations need…

There are other numbers that kept getting ignored like bugs count, backlog size, time lost to tooling and meetings,… maybe those can help with planning and resourcing too.

It’s always measure the team’s productivity, not make the team productive.

Re: Story points are pointless, measure queues

#180

Post by shalmanese » Wed, Jul 17, 2024, 7:19 AM UTC

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…

They're also useful in retro for the simple fact that something was written down. If your story point estimate was way off for a particular task, you can pull up the original conversation, identify what assumptions were violated or what new info was surfaced that wasn't present at the original estimation and whether there's learnings/process changes to be made.

Of course, retro is usually the first thing to go in a deluded attempt to increase velocity and story points hang on as this vestigial tail, contributing to more cargo cult software engineering.

edit: One scenario that might play out:

The team all agreed that tasks A, B & C were worth 3, 5 & 1 points respectively but Steve and Mei thought task D was worth 5 points but Carol thought it should be 13 because it involved integration of an external API where her experience was that other API integrations in the past had exposed hidden complexity.

Task D ultimately was not completed because during the process of integration, it was discovered that the API did support a key feature that was needed and instead, an in house alternative needed to be built.

It was decided that going forward, the team would instead assign a 1 point task to building a toy app for any new API integrations that would then feed into the process of deciding the story points for features requiring that integration.