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.

The idea was to not use direct measures of time to estimate because someone above you will start assuming those estimates are promises and then life gets unpleasant.

Story points, much as I personally dislike them, were invented for developer defense.

I've never seen such systems emerge from the team as a tool for self-empowerment. They are always foisted upon the team by managers who are trying to, ultimately, turn estimates into promises.

There has always been a perfectly fine word for that which means exactly the same thing: man hours.

I remember learning in school (way before the hocus pocus fancy new words came out) that the development of an Intel CPU cost around 1000 man-years.

I don't understand how expressing this as "it took 1000 kilo-story points" or whatever would bring any advantage whatsoever.

>I just don't get what the new terminology is for. Like how is this helping anybody?

The corporate world likes to come up with new terminology for old stuff and brands it as some new profound discovery. The result being that the new young generation of employees believe that they are living in a new enlightened age (bestowed by their corporate overlords) compared to their older counterparts who were living in the intellectual un-enlightened, dark ages.