Live data from Hacker News

Story points are pointless, measure queues

brightball.com

31–40 of 300 posts

Re: Story points are pointless, measure queues

#31
The article lost me at a certain point, somewhere around the "solving the conondrum".

It lost me, because we have two estimations - an overall size guess of an epic and an actual implementation estimation of an epic. Like the overall size guess is just 2-3 seniors looking at an issue and wondering if this takes days, weeks, months or years to implement.

The actual implementation discussion is however what the article is talking about. We get most or all of the team into a meeting and we talk through what needs to be done, and structure all of that into individual concrete tasks everyone can have an idea of implementing them. And then we estimate those tasks.

And this estimation in turn is communication to management. Like, we've realized that about 21 is what one of us can do in a usual monthly iteration outside of massive outages and such (we're an operational team). So if an epic turns out to require some 3 21's and 3 13's... that can easily take 6-12 months unless we put exceptional focus on it. With high focus... as a team of 4-5, that will still take 3-6 months to do.

On the other hand, something that falls into a bunch of 5's and 9's and such tends to be muddled and struggled through regardless of whatever crap happens in the team much more reliably. It needs smaller chunks of overall attention to get done.

And note that this communication is not deadlines. This is more of a bottom-up estimation of how much more or less uninterrupted engineering time it takes to do something. A 21 in our place by now means that other teams have to explicitly make room for the assigned person to have enough headspace to do that. Throw two interruptions at them and that task won't happen.

It's more bin-packing than adding, tbh.

Re: Story points are pointless, measure queues

#33
post #19

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 addition, I like the whole "Full Queues Amplify Variability" chart. It's intuitively obvious, but I never realized it was that bad. I'm going to have to run that down and see if it's actually backed by real data. Too many business books are complete flimflam.

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 expected length of the task. The only problem is that the same people that want to get oddly formal and inappropriately rigorous with things like story points will want to turn cost-of-delay into an accounting exercise - or object that it's impossible because they don't have the accounting system for it - which misses the point entirely.

Re: Story points are pointless, measure queues

#34

Earlier quoted context omitted.

Story points aren't useful outside the team. They're for the team to help it figure out roughly how much stuff it can do each sprint. They shouldn't leak out of the team.

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 task is roughly the same, so it's also a 3, then this one is similar but will take almost as much testing due to its difficulty, so we'll call it a 5, then this one is very simple, not even half as difficult as the first one, so it's a 1, etc), then try and keep that up for a few sprints, then figure out how many points fit into a sprint, you automatically factor in other factors (like "I have to log into Okta ten times a day", or "people keep getting pulled into meetings") through practical observation of what got done, and you get better at predicting what you'll be able to achieve in a sprint.

It's not perfect; it just removes the need for certain entire jobs devoted to accounting for time, which you can spend on another developer instead, while also being a reasonable measure of what you'll get done, and only takes about an hour every two weeks.

Re: Story points are pointless, measure queues

#35

Story points aren't time (as OP states). They're relative complexity, and uncertainty (hence the fibbonacci sequence building uncertainty in to larger numbers). And stories should be able to sized as big numbers. I've never been on a team comfortable with more than a 7, at least not since my first agile experience where we all took an agile/scrum training together for a few days. We'd frequently give things like 21 o…

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 pretending the complexity and uncertainty has been decreased.

Re: Story points are pointless, measure queues

#36

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 personally have never been able to translate story points into a reliable indicator

You haven't discovered the secret formula: make your estimate and then mindlessly triple it.

Re: Story points are pointless, measure queues

#37

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…

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"

Re: Story points are pointless, measure queues

#38
post #10

Story points aren't time (as OP states). They're relative complexity, and uncertainty (hence the fibbonacci sequence building uncertainty in to larger numbers). And stories should be able to sized as big numbers. I've never been on a team comfortable with more than a 7, at least not since my first agile experience where we all took an agile/scrum training together for a few days. We'd frequently give things like 21 o…

I agree - just countless times I have to beat that up into peoples head and even people who I would consider smart "points time". After the sprint you can kind of infer the time but it should not be guideline for next estimations unless these are tasks like "fix typos".

I continue to treat story points as a measure of time, despite being told repeatedly they're definitely not time. I will continue doing this until someone can explain to me, in a way I can understand, what they actually are that is not time.

Re: Story points are pointless, measure queues

#40
post #10

Earlier quoted context omitted.

I agree - just countless times I have to beat that up into peoples head and even people who I would consider smart "points time". After the sprint you can kind of infer the time but it should not be guideline for next estimations unless these are tasks like "fix typos".

I continue to treat story points as a measure of time, despite being told repeatedly they're definitely not time. I will continue doing this until someone can explain to me, in a way I can understand, what they actually are that is not time.

Difficulty level?

You can't promise you can beat a game on hard 2x as fast as you can on normal, or 3x as easy.

Post reply on HN