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

201–210 of 300 posts

Re: Story points are pointless, measure queues

#201

Post by gregors »

hnthrow289570 wrote: post #60
cassianoleal wrote: post #52

Earlier quoted context omitted.

> No bonuses for higher velocity is the real reason no one takes it seriously. Bonuses for higher velocity based on guessed story points would be an even bigger reason for not taking it seriously - or rather to overestimate everything in order to gain the impression of higher velocity and the bonus associated.

Non-developers might have to learn something about development so they can push back on inflated estimates, which honestly would be helpful to everyone. If I quoted you $1,000 to unclog your kitchen sink trap, you'd call bullshit because you can probably find out how easy it is to do that. Likewise, if I quote you 13 points to add a generic error toast message because a POST went badly, you should call bullshit on th…

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 without impacting existing architecture. And it seldom stays static - the name of the game is constant change and then add group dynamics to that.

A better example is to call a plumber and ask how much would it be to add a "rainbow spout to the horse-drawn wheelie-do" oh and there will be several other teams of plumbers there as well. I bet you get a few questions.

Re: Story points are pointless, measure queues

#202

Post by 8organicbits »

zelphirkalt wrote: post #198
vladgiverts wrote: post #165

Earlier quoted context omitted.

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…

> It helped that I was either a CTO or a senior enough exec in those cases with 3-8 agile teams. I essentially was the middle management and could put a stop to any destructive practices like evaluating teams against their velocity. I am sure teams quite appreciated you shielding them from overzealous management. But here is a thought: Doesn't this stand or fall with you being there or leaving? Will the next middle m…

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.

Re: Story points are pointless, measure queues

#203

Post by robertlagrant »

ozim wrote: post #44
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…

But you don't estimate holidays in ... you estimate how long it would take if someone picks on the task Monday morning and works on it full time. If someone picks up task on Monday then has 20 other meetings - estimation is still the same, he just continues after those 20 meetings and you just don't care when estimating. Only thing is if at the end of sprint dude is saying "I started X then I had 20 meetings so I did…

> But you don't estimate holidays in ... you estimate how long it would take if someone picks on the task Monday morning and works on it full time.

You estimate tasks that way, but you estimate capacity to do tasks on your actual track record, which will include holidays and other things.

Re: Story points are pointless, measure queues

#204

Post by heywire »

Is there anyone else out there still doing waterfall and estimating in hours and everything is just going fine, or am I just that lucky?

I work on a small professional services team customizing a couple of our products for our customers. A few times a month we get a request for an estimate to add a new feature or workflow. We do a high level customer requirements doc, discuss it as a team, the seniors from each area (design, development, qa) each provide an estimate in a range of hours. This all gets wrapped up into a final price to the customer. If they approve it, we dive into detailed design and have them sign off on the result. Then we go into development for weeks to months, qa, and then release. Our processes really haven’t changed in over 20 years. We’re constantly ranked as one of the most productive teams, and get high scores on our post-project surveys from our customers.

Re: Story points are pointless, measure queues

#205

Post by sumedh »

heywire wrote: post #204

Is there anyone else out there still doing waterfall and estimating in hours and everything is just going fine, or am I just that lucky? I work on a small professional services team customizing a couple of our products for our customers. A few times a month we get a request for an estimate to add a new feature or workflow. We do a high level customer requirements doc, discuss it as a team, the seniors from each area…

What does QA do when you guys are building the software?

Re: Story points are pointless, measure queues

#206

Post by sumtechguy »

Sammi wrote: post #197
vladgiverts wrote: post #165

Earlier quoted context omitted.

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…

So story points work when they are used as an internal tool for a team to understand themselves. And story points don't work when they are a tool used to communicate to the external world outside the team.

They are good for 'hey can I get this crap done in a sprint'. Once someone starts measuring it for 'how good a team is' that is when it falls apart.

One teams points almost always do not equal another teams points either.

Agile has a TON of anti-patterns that look good to do and are enticing to do. But in the end are self destructive. Usually making it about the process instead of 'I have X amount of work and Y number of people how much can I get done in Z time'.

For example velocity. I measure it so I do not overcommit. Trying to do 50 points when 20 is the norm and something will happen that we do not want. But now that you have a measurable number some manager will want to brag on it (that is their job to brag about you). In the end being put on some spreadsheet to be presented to some other manager. It becomes a score to measure you against other teams and an anti-pattern. As actually testing if something is being productive is hard. But numbers you can get all sorts of them out of agile, leading straight to anti-patterns.

Re: Story points are pointless, measure queues

#207

Post by azangru »

> Scrum tried to fix this in 2011 when “Commitment” was changed to “Forecast”

I've checked scrum guides released in 2010 and in 2011. The word "commitment" does not appear in the pre-2011 version. And, as far as I remember, the word "forecast" replaced the word "estimate" in the 2020 edition of the scrum guide compared to the 2017 edition.

Re: Story points are pointless, measure queues

#208

Post by tsimionescu »

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.

Time variability also increases with the time estimate for a task. If a task is "about two weeks", then it might be 1.5 weeks or it might be 4 weeks.

But if a task is about 1 day, it may take 4 hours or 4 days, but it will almost certainly not be 1 month.

Points are always just a proxy for time, and work the same way. Not matter what anyone claims, as long as you use points to plan time-abound sprints, points are directly a measure of time.

Re: Story points are pointless, measure queues

#209

Post by tsimionescu »

__MatrixMan__ wrote: post #88
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.

Points are about uncertainty, they're the difference between: - 3-4 weeks - 3-9 weeks Product managers can get their head around that.

No, points mash together size and uncertainty. A task that's "3-9 days" will have fewer points than a task that's "3-9 weeks". And a real that's "3 months give or take a week" will have more points than either.

Of course, there's actually no such thing as a "3 months give or take a week" estimate for a task. It's basically impossible in programming to have a task that takes that long with that low a level of uncertainty. So in reality, time estimates have the same properties as points: the higher a time estimate, the more uncertainty it represents.

Re: Story points are pointless, measure queues

#210

Post by tsimionescu »

vannevar wrote: post #82
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.

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 based on assignment (and then have problems if we switch the assignee for any reason), or we assign "generic points" and that ends up not meaning anything at all if the team is not very uniform (e.g. all seniors with similar skills and ownership of most of the same code, or all juniors).

Additonally, all methodologies tend to discourage correcting point values after the fact. That makes the process of deriving time estimates (velocity) even more error prone, because it conflates uncertainty with mistakes. That is, you can correctly estimate a task at 8 points and finish it in four weeks; or you can incorrectly estimate a task as 3 points and finish it in 4 weeks. That doesn't mean that the team has a velocity of about 1.35 points/week, it means it has a velocity of about 2 points/week, but made a mistake with one task.

Post reply on HN