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

241–250 of 300 posts

Re: Story points are pointless, measure queues

#241

Post by brightball »

hi_hi wrote: post #175
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 readi…

> Is the useful thing the queue, or the fact everything is now broken down into small tasks?

Yes. :-)

There are numerous benefits to both that are explained in more detail.

The short version is that the small tasks will give you a more accurate rate of progress. The exercise to break things down that way will benefit the entire team's communication and understanding of the problem. Writing them down will keep a record in place for new developers who join where a point measure wouldn't provide any real context.

The queue gives you a clearer picture of job sizing that can be measured and naturally changes with scope changes. It gives you a leading indicator of additional complications so that you can pivot earlier in the process if needed.

Awareness of variability amplification from the queuing process also makes people conscious of flow control of work, as well as the extreme negative consequences that happen when that work is over-scheduled.

They work together to create multiple benefits.

Re: Story points are pointless, measure queues

#242

Post by brightball »

terr-dav wrote: post #43
wewtyflakes wrote: post #16

Earlier quoted context omitted.

Ultimately, we are bound by time, not complexity. Why does it matter how complex a task is? The product managers and customers wont care how hard we as engineers have to think or reason about a problem; to them, the only thing that matters is time until delivery.

I think time variability increases with the level of complexity. In this context I see the idea of task complexity being related to uncertainty in the time estimate. This makes it fit nicely with the Fibonacci sequence.

Yep, that's completely accurate.

At the same time, that's one of the reasons to prioritize removing as much uncertainty as possible.

Re: Story points are pointless, measure queues

#243

Post by captaincaveman »

aussieguy1234 wrote: post #142

Ive been in lots of teams using story points. What I've found is that what one point is worth is never consistent between teams. A 3 for one team could be a 1 for another. Or a 1 could be 0.5/0.25. In one team, 3 points might be equivalent to 3 days work. In another it might be 1 day.

Yeah, and thats fine, there is literally no need to have them consistent between teams.

Re: Story points are pointless, measure queues

#244

Post by brightball »

IanCal wrote: post #66
xboxnolifes wrote: post #35

Earlier quoted context omitted.

Yeah, it seems like it's fairly common for people/teams to follow the idea that any story that is 8 or more points should be broken down to tasks of 5 or less. This simply doesn't make sense to me. If the most simple task is 1 point, is your most complex task allowed really only 5 times as complex? Story points usually follow an exponential increase for a reason, enforcing staying in the mostly linear portion is just…

The idea is that if a task is that large can you really not break it down into smaller steps? Do we understand the problem well enough to implement or are we hand waving over likely areas of complexity? Maybe if you tried to break it down you'd realise that the 21 point card is actually more like 10+ 5 points tasks and you had just though "big" not "I know what needs to be done and can size this accurately". Doesn't…

> Do we understand the problem well enough to implement or are we hand waving over likely areas of complexity?

Nailed it. That is exactly the right question to ask.

Re: Story points are pointless, measure queues

#245

Post by tacitusarc »

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…

So this may not be fair, but you lost me quite a bit with the positive take on SAFe, which is the worst, most unproductive experience of any process I’ve had.

I also do not understand the queues and capacity issue. I have never been in an environment where we do not have so much work that we cannot meaningfully see past the end of the queue. I don’t necessarily view that as a bad thing.

Re: Story points are pointless, measure queues

#246

Post by cynicalpeace »

The point of all of this is to communicate to management how long a task is going to take.

I would suggest that a good manager doesn't need this communication.

A good manager will have already done the task, or something similar, to already know how quick it can be done.

If they haven't, they're probably inexperienced in the task. They were appointed because they were a "people person" but this fact has actually introduced more friction to the team (needing the story points yada yada) rather than just assigning a simple deadline from the get-go.

Once a deadline is introduced, Parkinson's Law kicks in and you get more or less efficient work depending on how aggressive the deadline is.

I'm advocating for experienced managers, not deadlines per se, since that is just 1 tool in the toolbox.

I'm also advocating against the countless asinine ways to communicate to lousy managers. Throw the points in the trash and start hiring cracked programmers as your engineering team's standard bearer.

See the company grow and have happier employees.

Re: Story points are pointless, measure queues

#247

Post by brightball »

tacitusarc wrote: post #245
brightball wrote: post #228

Earlier quoted context omitted.

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…

So this may not be fair, but you lost me quite a bit with the positive take on SAFe, which is the worst, most unproductive experience of any process I’ve had. I also do not understand the queues and capacity issue. I have never been in an environment where we do not have so much work that we cannot meaningfully see past the end of the queue. I don’t necessarily view that as a bad thing.

I’ve read the horror stories on here and I understand. There’s what it is supposed to be, what is taught and how it ends up.

Rigidity is probably the biggest issue. It’s supposed to be adapted to an organization leveraging what works well, handing more control to developers and addressing some communication gaps.

When people try to implement it strictly and force the company into the example template it creates a lot of friction.

When I’ve previously explained on here what it should look like, it’s typically nowhere close to that in the horror stories. Developers should have significantly more control in a SAFe environment fwiw. I’ll explain it more if you like though.

I have to run out but I’ll come back to explain the queue stuff too.

Re: Story points are pointless, measure queues

#248

Post by 0xbadcafebee »

> what if we substitute something else for story points?

Then that new thing becomes the new measure, you change what you do to meet that measure, and things are screwed up again.

The author's final paragraphs describe implementing a complex process that an intelligent team has to use in a nuanced way. And somehow simultaneously declares that the original problem was story points, one single aspect of a complex process, and not the fact that there's a complex process that nobody understands or follows correctly.

You know how Toyota gets TPS to work so well? They do one thing, well, at a time, repeatedly.

Product development sucks because it's trying to do a million things once, constantly changes its mind, doesn't train its workers, and conflates designing, engineering, assembling, and operating, as one giant "thing". Then it wonders why it can't keep track of time.

Re: Story points are pointless, measure queues

#249

Post by DSMan195276 »

robertlagrant wrote: post #34
throw310822 wrote: post #22

Earlier quoted context omitted.

A sprint is a unit of time, how does measuring a "complexity"- whatever that is- helps in figuring out how much stuff you can put in *time*?

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…

Functionally you're just created extra steps and confusion by not calling it a time estimate, or at least something equivalent to time. Even with a real time estimate you shouldn't be planning by going "well you work 80 hours this sprint, so we plan 80 hours" - you should be doing the same consideration of looking at how many "hours" were completed in the last few sprints and plan based on that number. If we're in agreement that these numbers are for the team only then it shouldn't matter if they consistently under or over estimate the hours, nobody outside the team should know or care how many "hours" they complete in a sprint.

The confusion part is that by calling it "complexity" and saying it's not a time estimate you've muddied the waters on what it is, people will debate the definition and intentionally differentiate it from actual time. I've seen this before, the points-per-sprint never stabilizes because teams have cards where "that's a 1 point card because it's simple, but it will probably take a week". And then suddenly they're ignoring the points during planning to instead come up with an actual time estimates (which also don't work because they don't track those against multiple sprints).

Re: Story points are pointless, measure queues

#250

Post by yesbutnobutyes »

In my experience people mainly like to complain or exist within a state of conflict where they are against something.

Story points are relative value as defined by the team, for the purpose of forecasting and reporting. They really can be anything the team decides, as long as it's a reliable measure. Ultimately they exist to answer"How long will this take?", which is the most dependable question from people writing the cheques.

People asking that question don't care if it's Fibonacci or hours or t-shirt sizes or anything at all.

"Is x bigger (or smaller) than x", followed by "is this more important than this" should be brain-dead easy and logical for everyone involved.

In my 10+ years I've learned that it's ultimately just that people don't want to be told what to do and/or need tribalism (an "other") to feelat balance with their environment.

There's no escape from prioritization and sizing. Throw scrum in the garbage and you'll still be doing it by another name.

Post reply on HN