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

261–270 of 300 posts

Re: Story points are pointless, measure queues

#261

Post by csbbbb »

> Now, if you're paying attention and reading this with a critical eye something in your brain just told you "Wait, this is just waterfall! We can't know everything up front!"

The article presents the "story points" problem to be caused by an ignorant or presumptive misunderstanding of how the system works by outside parties.

I think articles like this are an interesting and necessary part of the overall project-managent discourse. However, they tend to infer that the problem of ignorance can be resolved by the management framework directly, to which I disagree.

Ignorance, regardless of project-management, has to be addressed by clear communication and boundaries.

Re: Story points are pointless, measure queues

#262

Post by sirwhinesalot »

I've never understood the point of the points (pun intended) you can try to convince yourself they're measuring "complexity" or whatever but what they're measuring is time, so why not cut out the middleman?.

I'm not saying to estimate tasks accurately to the hour. Just rough ballparks: "I think I can do these 3 on friday". "Give me a week, it's gonna take a pile of tests to make sure we get it right". "Hmm I probably need the whole sprint for that, we don't have a clear view of the impact, it sounds like a small change but it uppends our current architecture".

These are the real discussions, the numbers are a silly abstraction on top of this and are unnecessary.

It should also be 100% expected that the estimates will be wrong. New bugs will show up, regressions will be introduced, requirements will change last minute. It should also be expected that some tasks that were supposed to get done won't be and other tasks that weren't in the planning could be snuck in. You are "Agile" are you not?

If you're not than just go back to waterfall and stop dragging the Agile Manifesto through the mud, thanks.

The entire point of the exercise is the discussion, it gives you some idea of what is likely to go well and be finished and what is a risk factor. If you're measuring "velocity" god help you.

Re: Story points are pointless, measure queues

#263

Post by skydhash »

dilyevsky wrote: post #178
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.

That’s because you’re dealing with a pile of abstractions on top of the cpu, data storage and channels that connect them all. You’re perched on top of the babel tower trying to figure where to put the next stone without everything crumbling around you. And you don’t even know the shape of the stone. You only have a vague description of it.

Just too many unknowns.

Re: Story points are pointless, measure queues

#264

Post by gregors »

convolvatron wrote: post #221
gregors wrote: post #201

Earlier quoted context omitted.

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…

I'm a big fan of evidence base scheduling by Joel Spolsky [0].

Story points hold very little value in estimation, the discussion that occurs however, is extremely useful.

[0] https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

Re: Story points are pointless, measure queues

#265

Post by vannevar »

tsimionescu wrote: post #210
vannevar wrote: post #82

Earlier quoted context omitted.

Just because they're not time, doesn't mean you don't want to add them. Imagine you have an empty basket, and you're not sure how much fruit you can toss in it. So the first time, you just start tossing stuff in until it's full. The exact number of lemons, coconuts, etc will vary. But after a few rounds, you'll get a feel for how much of each you can get into the basket. That's story points. You feel your way into a…

My experience is that story points get a bad rep because they don't mean anything unless you use them as an explicit proxy for time. There's no way to say in reality "this task is small" unless you have some idea of how long it takes. Additonally, this concept of velocity makes no sense because a task that's big for me might be small for someone else in the team, so then we either pre-assign tasks and set points base…

>My experience is that story points get a bad rep because they don't mean anything unless you use them as an explicit proxy for time.

So when you shop for clothes, Small/Medium/Large are useless? You require precise measurements for every item, and they have to be exactly the same size across manufacturers, or else sizes have no utility for you? The reality is that a Large can be large on you in different ways, even if it's a t-shirt. And software complexity has a lot more dimensions than a t-shirt. The utility of story points is that they allow a team to create a rough idea of their capacity over a sprint, so that they don't consistently under- (or more commonly) over-commit.

If you try to use story points purely as a uniform proxy for time, of course they're going to be useless, because you can always just use time instead.

Re: Story points are pointless, measure queues

#266

Post by vannevar »

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?

One is a fuzzy and subjective measure of how much software a team can develop in a sprint, the other is a precise measurement in a single dimension. I could sit there and try to calculate how many expertise-adjusted person-hours each team member represents, then estimate our capacity that way, but why fool ourselves with that kind of false precision? Just eyeball it the first sprint and then observe how much we get done. Explicitly tying story points to time just invites abuse of the velocity by managers who don't understand how scrum works.

Re: Story points are pointless, measure queues

#267

Post by vannevar »

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…

But at that point you should be at a higher level of abstraction, looking at the number of sprints that will probably be needed to clear the backlog (hopefully understanding that the backlog itself should always be regarded as incomplete). The discussion then should be something like, "Hey, we're four sprints in, the backlog already has about seven more worth of stories, and we only have four more sprints until our target deployment date. Do we cut features, move the date, or add more team members?"

In the pathological case where management is constantly monitoring the team velocity and converting that to individual productivity, you'll get managers who (often to cover their own recklessness in setting an unrealistic date, or procrastinating on starting the project) will decree that the team is going too slow. I know that happens a lot, but it's not the fault of scrum, it's just poor management. Scrum can't make a bad manager good, but avoiding scrum won't make them good either.

Re: Story points are pointless, measure queues

#268

Post by mcluck »

vannevar wrote: post #266
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?

One is a fuzzy and subjective measure of how much software a team can develop in a sprint, the other is a precise measurement in a single dimension. I could sit there and try to calculate how many expertise-adjusted person-hours each team member represents, then estimate our capacity that way, but why fool ourselves with that kind of false precision? Just eyeball it the first sprint and then observe how much we get d…

I frequently hear about this abuse of estimates and even ran in to it myself when I was a more junior engineer. In my opinion, part of maturing as an engineer is learning to call your shots and properly communicate when you aren't sure how accurate you are. It's one thing to say "I promise this will be done tomorrow". It's another thing to say "we're not positive but within the month seems likely"

Re: Story points are pointless, measure queues

#269

Post by beryilma »

Regardless of what anybody says to the contrary, story points are and have always been used as an obfuscated measure of time. When we can never estimate plan timelines correctly in the first place, why would anybody think that we should be able to measure story points with any accuracy? It is just another stupid PM gimmick to create useless management metrics.

Re: Story points are pointless, measure queues

#270

Post by steelframe »

tsimionescu wrote: post #211
steelframe wrote: post #158

Earlier quoted context omitted.

The identity of story points depends on what information you have. If you don't know your team's velocity then story points are only relative complexity. Once you have your team's velocity you can use that information to convert to time.

What is relative complexity? How can you compare the complexity of with , other than by how long they might take?

Then it would be how long they might take relative to each other. To give a specific time you would have to know the stage of development for the product, the health and ease-of-use of the CI/CD pipeline, the current interviewing burden of the team, the rate at which production incidents are occurring, the number and length of meetings that the team members are in, etc., etc., etc. More junior developers generally won't do a great job of that. But more junior developers can usually estimate the time it would take them to do the task if they had absolutely nothing else to do and if their build/test/deploy pipeline were optimal. So with story points that's all they need to really worry about. In that way story points are a tool to help the team make better estimates in the face of varying degrees of expertise in individual contributors estimating time-to-complete.

By judging complexity and measuring velocity you get an estimate of time that intrinsically takes all of the variables into account. It's a powerful tool when used right.

Post reply on HN