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

71–80 of 300 posts

Re: Story points are pointless, measure queues

#71

Post by recursive »

ozim wrote: post #17
throw310822 wrote: post #14

Earlier quoted context omitted.

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.

That is one of the complications - one thinks developers should be smart as in abstract thinking so they should understand (just like all the other numbers humanity made up): "numbers we call story points are not having property to add them and they are not convertible to time". * Properties of Whole Numbers: Whole numbers are closed under addition and multiplication. Zero is the additive identity element of the whol…

Why use a measure that creates this footgun? Why should our task estimation require this much abstract thinking? Why not invent the measure so that it's not misleading? Numbers generally have well-understood properties. Using them in a way where the properties don't apply is asking to be misunderstood.

Re: Story points are pointless, measure queues

#72

Post by rerdavies »

Could somebody explain how queue theory fits into agile processes? Where are these unmanageable queues, that need to be emptied coming from?

Queue theory only becomes a problem when (1) stories are being added to the active story queue at a furious rate; and (2) nothing gets shipped until the active story queue is emptied. I don't think think either of those things are supposed to be true in an agile process, especially the last.

It sounds suspiciously like a symptom of gamification to me (if new stories are being added by the development team). Or a broken process where field defects (which are supposed to go to the top of the queue) are so numerous that they completely overwhelm active development, which is an entirely different issue, requiring an entirely different response from management.

If story points are so wrong that it no longer fits in a sprint, it seems reasonable to split the story. In my experience, I don't think I've seen it happen more than a handful of times. How often is an initial story point estimate so wrong that it has to be revised upward to the point that it no longer fits in a sprint? If it's wrong, but still fits in a sprint, just do it. It makes me wonder whether there's gamification going on around using story points to evaluate developer performance.

(Assuming that stories are converted to tasks at the start-of-sprint meeting).

Re: Story points are pointless, measure queues

#73

Post by bryanlarsen »

icedchai wrote: post #49
freitzkriesler2 wrote: post #29

Earlier quoted context omitted.

Those items after your eg are part of the problem why story points don't work for you. You really do need to control the amount of time your devs get distracted by other things. If they're solely focusing on that one project, you'll be fine. Its why i personally appreciate XP more than plain old scrum.

This, 100%. When engineers have focus, no context switching... things get done. When they're interrupted with useless Zoom meetings every 2 hours, productivity drops off the cliff. If you have 2 meetings 1 hour apart, that 1 hour is basically useless: by the time you're in the zone, you're interrupted again.

And then when we're given a nice long stretch of interruption-free time, we ruin it by hitting HN.

Re: Story points are pointless, measure queues

#74

Post by vannevar »

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 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're on a scrum team, they're a useful 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. 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.

Re: Story points are pointless, measure queues

#75

Post by rustbucket »

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

[dead]

Re: Story points are pointless, measure queues

#76

Post by sithlord »

In my world, on my team - everything is a 3. and if its not a 3 lets figure out why. IE, lets have a fairly sized piece of work we scope for most tickets. If its bigger than that, lets discuss it, see if its worht breaking down (if its larger) and if not lets just agreee thats a larger piece than 3. that way we can just keep an eye on relative size of issues.

Re: Story points are pointless, measure queues

#77

Post by convolvatron »

recursive wrote: post #37
robertlagrant wrote: post #34

Earlier quoted context omitted.

I understand what you're saying - of course in some sense they're convertable. But the point is to not think about time when estimating, because if you estimate time you don't factor in things like other tasks, or holiday, or anything else. Or if you do you have to spend ages trying to account perfectly for time. Instead, if you estimate complexity (e.g. I think this task is a 3, just as a starting point, then this t…

If the problem is "we're not accounting for holidays in our time estimates", I can't see how the solution could possibly be "time is obviously a flawed measure, so we'll use this other measure which has this hazy relationship with time, but we all agree that it's definitely not time , although we have trouble saying what it is "

personally, I find it much easier to say 'normally, I would get this to you by wednesday of next week, but we have that offsite and my wife's parents are visiting, so does friday work for you?'. than 'this is a 3', so, I guess this fits in this sprint?

changing units and names of things really seems like a deliberate attempt to rob the discussion of any actual meaning. just a comfortable empty formalism that masks the fact that we aren't trying to come to grips with the most difficult parts of our job

Re: Story points are pointless, measure queues

#78

Post by ecshafer »

sithlord wrote: post #76

In my world, on my team - everything is a 3. and if its not a 3 lets figure out why. IE, lets have a fairly sized piece of work we scope for most tickets. If its bigger than that, lets discuss it, see if its worht breaking down (if its larger) and if not lets just agreee thats a larger piece than 3. that way we can just keep an eye on relative size of issues.

My team doesnt really have story points. But we work kind of similar to you: is this too big? If it is, lets see if we can break it down to smaller tasks. I think it works much better than arguing over story points.

Re: Story points are pointless, measure queues

#79

Post by aetherspawn »

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?

Re: Story points are pointless, measure queues

#80

Post by wolpoli »

icedchai wrote: post #55
throw310822 wrote: post #14

Earlier quoted context omitted.

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.

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

Post reply on HN