Story points are pointless, measure queues • Hacker News Board

Re: Story points are pointless, measure queues

#231

Post by hobs » Wed, Jul 17, 2024, 2:19 PM UTC

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…

That's like saying a system that generally yields bad results isn't to blame, its people.

For a vast majority of managers in "software companies" things like story points are about asserting control over what is created, getting commitments from various folks, and then increasing stress to have you "sprint" constantly "behind schedule" so they can inject additional requirements or pivot to the new thing they want to do.

Re: Story points are pointless, measure queues

#232

Post by brightball » Wed, Jul 17, 2024, 2:21 PM UTC

vladgiverts wrote: post #165

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…

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…

You sound like an excellent technical leader and that fixes a lot.

One of the main drivers for writing this down is to make it easy to pass along for people who aren't as aware of the problems that come from those anti-patterns, as well as to explain why they are so destructive. The hope is to raise some awareness for people in tougher situations.

Re: Story points are pointless, measure queues

#233

Post by buescher » Wed, Jul 17, 2024, 2:26 PM UTC

jksmith wrote: post #131

buescher wrote: post #33

Earlier quoted context omitted.

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.

I hadn't specifically seen MoSCoW before. Some people need to have everything spelled out for them, I guess.

Re: Story points are pointless, measure queues

#234

Post by ath3nd » Wed, Jul 17, 2024, 2:31 PM UTC

To me story points, planning poker, scrum, and a bunch of other "agile" artifacts are funny concepts.

Making 4-5 highly paid professionals sit around in a circle with a bunch of cards trying to estimate how long/complex/??? the task is, writing it down, and doing that every two weeks, to dubious results, is exactly what one can expect out of today's businesses.

My guess is management doesn't trust that engineers aren't just fiddling around, so they hire a bunch of management-like people to watch over the drones, and show them who's in control. And how else you can show you are in control if you don't introduce magical rituals and tracking useless metrics, and make grown people participate? That way, all these meeting rooms can be occupied and the owners can feel like something important's happening and that they are getting their money's worth.

Re: Story points are pointless, measure queues

#235

Post by stackskipton » Wed, Jul 17, 2024, 2:32 PM UTC

zelphirkalt wrote: post #218

8organicbits wrote: post #202

Earlier quoted context omitted.

A manager cannot protect teams after they leave. The new manager can change all the existing process when they take over, and you're back to square one.

I understand that. So the question arises: Is it more difficult for a new manager to ruin the work processes through inaction (not shielding the team) or by reworking established processes? My bet is on it being very easy through inaction.

Most of time, I find new manager was brought in to be a yes person because previous manager quit due to conflicts with their management that maybe you didn't see.

Re: Story points are pointless, measure queues

#236

Post by brightball » Wed, Jul 17, 2024, 2:32 PM UTC

burnished wrote: post #213

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…

Yeah, the discussion can be really illuminating. If the points weren't recorded or mentioned afterwards I think it would be a net positive in some cases.

That's one of the main points of the approach mapped out.

You still get the discussion value, you just end up documenting things better as a practice and make a more concerted effort to add clarity where needed.

Re: Story points are pointless, measure queues

#237

Post by brightball » Wed, Jul 17, 2024, 2:36 PM UTC

jksmith wrote: post #131

buescher wrote: post #33

Earlier quoted context omitted.

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.

That is very true. I'm going to write something up about WSJF in practice in the future, but it has some real benefits to fixing that issue.

Particularly when you get the decision makers in a room and get them all to agree on the estimated value of each item. Not only does it remove the numerous priority #1's, it also gets everybody aligned on what the real priority #1 is and why.

I've seen it done where people are surveyed separately and it only works well when the people involved are forced to have a conversation to put real numbers to their assumptions, coming out with agreement. The other side effect is that it solves the squeaky wheel problem.

Re: Story points are pointless, measure queues

#238

Post by brightball » Wed, Jul 17, 2024, 2:41 PM UTC

rerdavies wrote: post #84

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…

Software does not exist in a vacuum. You are probably right in thinking that story points should not matter to you, as a developer; but they do matter to external stakeholders. Forecasting and management of expectations is necessary because software often has external real-world dependencies: available funding for a first release, marketing materials, hardware that can't be released without software, trade shows, dev…

> The corresponding abuse of process to combat that metric would be to hyper-decompose stories.

You're right about that, but that's also one of the benefits to the approach. Inflating a point estimate is easy and there's no real audit trail for why the value is what it is.

On the other hand, if a team creates tasks like "Commit the code" or "save the file" it's pretty easy to identify as fluff.

Re: Story points are pointless, measure queues

#239

Post by ffsm8 » Wed, Jul 17, 2024, 2:42 PM UTC

brightball wrote: post #228

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

As far as my current employer is concerned, 3 story points equal 8 hours of work.

The previous one considered only complexity, so a simple change that needs adjustments all over the project would still be considered 1 story point, even if you needed multiple days to get it done.

The PO in the job before that kept asking "but how much time will you need for that" until he got an answer, ultimately making story points redundant.

Really, ymmv

Re: Story points are pointless, measure queues

#240

Post by brightball » Wed, Jul 17, 2024, 2:45 PM UTC

Zanfa wrote: post #167

JohnAaronNelson wrote: post #116

Earlier quoted context omitted.

There was a part of the article that discussed that you create tasks, not stories. You can group the tasks into stories or milestones or iterations or epics. In general, he’s saying you should always keep breaking down a task until it’s a 1, since 1s are easy to estimate. The key part that may be missed is the “mob programming” or “pair programming” aspect where all the engineers on a team sit together and work throu…

> The key part that may be missed is the “mob programming” or “pair programming” aspect where all the engineers on a team sit together and work through a story or milestones or epic to come up with a list one 1 point tasks. My issue with this has always been that once an issue is straightforward enough to estimate as a 1 point task, you could’ve implemented the task already during the estimation process. The unknown…

I have actually always had the same feeling about 1 pointers, but in this case you're talking about a collection of small tasks that make up a larger feature.

The larger feature probably couldn't have been implemented during the estimation process, but a single isolated small task could have.