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

191–200 of 300 posts

Re: Story points are pointless, measure queues

#191

Post by StackRanker3000 »

n4r9 wrote: post #190
StackRanker3000 wrote: post #189

Earlier quoted context omitted.

Yes, we should all live in reality and use our best judgement. If estimating based on story point velocity is literally useless, then no one should be doing it. However if it does help make planning more accurate, even by a little, then it might be worth the cost of doing so. It’s a conversation to be had between different functions, hopefully based on empirical evidence. I feel like a lot of engineers overlook that…

> People don’t ask for estimates just to annoy developers. No, I know, there's just a systemic difficulty with scheduling dev items that are difficult to estimate. My team is currently working on performance improvements for a certain service in order to get it to a level that our biggest client is happy with. Based on some profiling and some intuition, I built some Jira cards with rough ideas of what changes might m…

That’s all fair. It’s an inherently difficult problem. In a healthy organization, leadership is aware of this, has reasonable expectations and factors in the risk. Unfortunately not all organizations are mature in this way.

Re: Story points are pointless, measure queues

#192

Post by IanCal »

Too wrote: post #159
SoftTalker wrote: post #140

Earlier quoted context omitted.

I haven't done story points estimating in years, but at the time, an 8 was rarely acceptable, a 13 surely was not. Estimates that high were basically saying "this story is too big or too poorly defined to estimate accurately" and we'd try to break it down into several stories of 5 points or less. The vast majority of our stories were 2, 3, or 5 points.

Now you are doing exactly the same mistake the article starts out with. Comparing story points outside your own team, of which you have zero context about how much 8 point represents. How big your points are make no sense at all outside your own team. It is a relative measurement. 8 could mean 8 lines of code, 8 rest endpoints, 8 database columns or 8 interviews with customers. It certainly should not mean 8 days.

Not really.

The point there is the granularity. If 8 points to you is fixing a minor spelling mistake in your docs, what value is there in having anything smaller than 8?

If 1 is "build the entire backend" then how can you represent anything smaller?

Re: Story points are pointless, measure queues

#193

Post by bitwize »

Remember, for any project -- software or otherwise -- in any business, the business is going to need to know the answers to two key questions:

* When is it going to be done?

* How much is it going to cost?

You should therefore estimate in units of time because you will be held accountable for time. (And time is money.) This is straightforward if you break the work down into components of manageable size beforehand and prepare a bill of materials itemizing each component that the final product will require. Using the BOM approach means that completion progress for the system as a whole can be tracked in terms of which materials are complete and ready to go, not just a number or percentage of how complete someone thinks it is.

Now what if your team gives one set of estimates and the estimates are off? Well, what managers have found is that usually there's a pretty consistent ratio between the time a programmer estimates a certain task will take vs. the time it takes them to actually perform a task. Therefore, the correct way to go about time accounting is, for each task, the developer should give a time estimate before starting the task and record the time it actually took them to complete it when they are finished. The ratio between the two, as it stabilizes over time, will give project management increasingly good information about how long it will actually take a given developer to do a given task, based on their estimate, and enable them to calculate schedules accordingly.

Re: Story points are pointless, measure queues

#194

Post by IanCal »

bboygravity wrote: post #11
quantified wrote: post #2

Story points were only ever an approximate unit of time. To fit them into a clear unit of time such as a sprint is a clear indicator of this. To call them complexity or anything else is misleading- transcribing a dictionary by hand into a CSV file is super simple (1 pt) and takes a long time (how many points is 3 FTE-months in your calibration?). Eatimating effort-time vs completion time are quite different, serving…

I just don't get what the new terminology is for. Like how is this helping anybody? Manhours = story points Task = story Subtask = sprint Upcoming tasks = backlog Task turn around time = ?? Project goal(s) = epic(s) I'm probably not even doing this right, but what are we doing here anyway?! It gets real fun when the project involves software/firmware + mechanical engineering (think machines, robotics, etc), gotta lov…

The broader point with all this is every field comes up with jargon because it's a form of compression rather than repeating the same phrases again and again. The differences between what you've written there and how they've been used in the teams I've been in are the point here. Instead of saying "manhours but with a conversion factor that we figure out over time and an understanding of the variation" you say "story points".

Story points aren't hours. People are really bad at estimating with time, but they're much better if you just get them to compare things and say which one seems like it'll take longer.

Stories aren't tasks, either. A task is a single unit of work that you can do and complete. Stories are groups of things that solve a particular problem.

For example, adding a password reset is a story. But that might be distinct tasks that different people can take on, or should be coded and released independently. Maybe that requires setting up an email service or server, UI changes in the frontend, backend changes, is there design that needs doing for it, etc.

> Subtask = sprint

Sprint is a bit of a weird one sure but it's a short length of time. Different for different teams, typically 1-4 weeks.

> Upcoming tasks = backlog

Backlog isn't a very custom term here is it? Also it's not the upcoming tasks, it's things that probably should be done but not right now. New idea? New feature? Cool, backlog, doesn't interrupt the current set of work for the next couple of weeks.

Every field can do this with every other field. Doctors with their fancy words like anterior, why don't they just say "the bit at the front"?

I know there can be cringey project managers, yes. On the other hand, I've also seen highly skilled engineers scoff at these kinds of things then spend way too long building stuff that doesn't actually address what the user needs, misses out key parts because they never thought about who was actually tracking those ancillary pieces of work and making sure they're done, and fail to deliver.

Oh and finally if someone wants to come along and say "well we did it differently", if that worked for you then great! The classic point of agile was that you should try things and keep what works. None of these concepts are particularly complex imo.

Re: Story points are pointless, measure queues

#195

Post by LinXitoW »

EVa5I7bHFq9mnYK wrote: post #169
ozim wrote: post #41

Earlier quoted context omitted.

So they are bad product managers and customers. Time until delivery for good managers and customers is a range. Can you estimate getting 10kg of potatoes from grocery store that is 35m driving roundtrip away? Can you say it will be exactly 40mins because you can pick up and pay in 5 mins? I don't, I can say it will take between 40mins and 2h. There are always things like card terminal stops working or you get stuck i…

"Time until delivery for good managers and customers is a range." Sometimes it's not. In the gaming industry Christmas is a hard deadline.

No, it's still a range, the difference is simply that a good manager would plan such that Christmas is at the very far end of the range. Bad managers will plan with the optimistic end of the range, and then expect crunch time from exploited workers following their passion.

Re: Story points are pointless, measure queues

#197

Post by Sammi »

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…

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.

Re: Story points are pointless, measure queues

#198

Post by zelphirkalt »

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…

> 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 management be as capable and looking out to shield the teams from the destructive influence? Why not change the system, so that the middle management does not need to shield the engineers?

Re: Story points are pointless, measure queues

#199

Post by siva7 »

IanCal wrote: post #192
Too wrote: post #159

Earlier quoted context omitted.

Now you are doing exactly the same mistake the article starts out with. Comparing story points outside your own team, of which you have zero context about how much 8 point represents. How big your points are make no sense at all outside your own team. It is a relative measurement. 8 could mean 8 lines of code, 8 rest endpoints, 8 database columns or 8 interviews with customers. It certainly should not mean 8 days.

Not really. The point there is the granularity. If 8 points to you is fixing a minor spelling mistake in your docs, what value is there in having anything smaller than 8? If 1 is "build the entire backend" then how can you represent anything smaller?

You're just proving their point

Re: Story points are pointless, measure queues

#200

Post by poikroequ »

Story points don't help me do my job. They do a great job of wasting my time and making me less productive. It's not just story points, but the whole agile/scrum methodology feels terribly wasteful. The gross amount of time we waste setting estimates, refining stories, sprint planning. To what end? So management can make some meaningless charts? So that the "decision makers" can use these contrived numbers to figure out who gets cut in the next round of layoffs?
Post reply on HN