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

211–220 of 300 posts

Re: Story points are pointless, measure queues

#211

Post by tsimionescu »

steelframe wrote: post #158
recursive wrote: post #38

Earlier quoted context omitted.

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.

The identity of story points depends on what information you have. If you don't know your team's velocity then story points are only relative complexity. Once you have your team's velocity you can use that information to convert to time.

What is relative complexity? How can you compare the complexity of with , other than by how long they might take?

Re: Story points are pointless, measure queues

#212

Post by brightball »

Karrot_Kream wrote: post #182
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.…

I wish the article spent longer with discussing the queuing view and less time on pointing out the flaws with story points, but I guess I'm biased because the flaws already are "obvious" to me. I think there's an inherent tradeoff between the overhead and misery of breaking down a task into granular subtasks and the variance of task completion time. In practice what this would mean using a queue style form of trackin…

I’ll do that for a followup post. Watching the discussion here it seems like that would be beneficial. I struggled with where to put the emphasis on this write up but ended up deciding that I need to clearly make the case for Story Point flaws first as a warning reference for people experiencing these issues in their current environments.

I would have separated queue management into its own post but thought writing about a problem without presenting the solution would result in a lot of “okay, so what should I do instead?” But that created a length complication where I had to keep it succinct because it was already a long post.

Anyway, there will be a followup with more detail on queues. Probably the biggest complication for them is the lack of good reporting built around them in most existing systems.

Re: Story points are pointless, measure queues

#213

Post by burnished »

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.

Re: Story points are pointless, measure queues

#214

Post by burnished »

recursive wrote: post #38
ozim wrote: 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.

Having points not be a measure of time is a means of estimating how much work you think the team as a whole will accomplish while diminishing the risk that a given estimate (delivered in time range) will mutate into a 'promise'.

Its also a good way of communicating what you think the blend of known unknowns and unknown unknowns is.

Re: Story points are pointless, measure queues

#215

Post by samus »

bluefirebrand wrote: post #152
vannevar wrote: post #74

Earlier quoted context omitted.

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

> 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 These two sentences are somewhat in conflict imo. Workload and schedule is tied into capacity planning and resourcing, which happens at a higher level than the scrum team. The people having those conversations need…

Apart from the impact on team motivation and the incentive to inflate estimates, another problem with that approach is that the story points might not correspond cleanly with how much time was actually spent on the task. Story points are anyways an example of multidimensional data squeezed into one dimensions and in the process losing valuable information.

Are there teams out there that correct the story points based on actual amount of work and complexity?

Re: Story points are pointless, measure queues

#216

Post by brightball »

andrewflnr wrote: post #164
brightball wrote: post #138

Earlier quoted context omitted.

I struggled with the length but couldn’t find a good way to shorten it more unfortunately. That’s the main reason I included a TLDR. Thanks for giving it your time though.

You could trim down the parts dunking on story points a lot. It starts to feel redundant and most of it is dubiously relevant. If we care about the topic at all, we probably already have an idea of what story points are and what's wrong with them, and are mostly interested in your proposal to replace them. You only need to refresh our memory about the existing system, and maybe link to other critiques.

Fair critique. I was mostly trying make a thorough case first.

I’ll definitely have a followup focused more on queues.

Re: Story points are pointless, measure queues

#217

Post by hnthrow289570 »

ashton314 wrote: post #95
hnthrow289570 wrote: post #46

Earlier quoted context omitted.

The points are needed because it's convenient to do reports based off of it. If we used estimation language such as "easy, medium, hard, dummy-thicc" they'd still need to assign points to those labels so they can do math on reports and graphs to watch your performance The biggest sin of course is then trying to predict velocity, but the consequences of that usually just make people doing the reporting look silly for…

> points are needed because it's convenient to do reports based off of it So, you’re saying it’s convenient for management , yes? Making things convenient for management at the expense of the front-line workers inverts the priorities of a company. The managers ought to be working harder to make things as efficient and convenient for the workers to build the right thing. Putting management first is the stupidest thing…

>So, you’re saying it’s convenient for management, yes? Making things convenient for management at the expense of the front-line workers inverts the priorities of a company.

You'd end up having a points system whether you like it or not. If it wasn't story points, it'd be days/weeks/months estimates.

Almost nowhere you will find "it's done when it's done, don't bother me until it's done" as an option for a developer.

If you want an even more utopian arrangement, management would know how to look at git and use the software once in a while to see how things are progressing.

Re: Story points are pointless, measure queues

#218

Post by zelphirkalt »

8organicbits wrote: post #202
zelphirkalt wrote: post #198

Earlier quoted context omitted.

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

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.

Re: Story points are pointless, measure queues

#219

Post by heywire »

sumedh wrote: post #205
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?

They’re working on other projects. Whether it is testing a general release for a customer, testing bug fixes, or testing a recently completed customization project.

Re: Story points are pointless, measure queues

#220

Post by jon-wood »

gregors wrote: post #201
hnthrow289570 wrote: post #60

Earlier quoted context omitted.

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…

Oh come on. There are certainly a bunch of things which nobody on a team has done before in any given project, an error toast is not one of them. Almost every project is using previously built software for them, and the way they fit together is reasonably well known.
Post reply on HN