3 ms·

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 compl

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 different stakeholders. A story that takes 1 point of effort by anyone's pointing system could still take a week due to any number of factors (crucial collaborator gets sick, laptop crunched by a car, ransomware attack, whatever). The only really estimable aspect is how long the developer will spend on the work, not when it will be done. Air speed, not ground speed. That said, it's not clear how queue analysis helps when you haven't spent any time saying how long you might expect each task in the queue to be, or what the dependencies are between tasks within and across teams. Given engaged team members, I've gotten very good results on predicting the pace of progress for sprints, and it all never mattered because everything needed to be shipped. About 4-6 weeks before each X was to be completed we could say with confidence that X would be ready in 4-6 weeks. Not terribly useful.

bboygravity 2y ago
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 love their faces when you teach them the special magic advanced project words for special software people.
- drewcoo 2y ago
  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.
  - bboygravity 2y ago
    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.
  - usea 2y ago
    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.
- dennis_jeeves2 2y ago
  >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.
- IanCal 2y ago
  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.
ozim 2y ago
But you have !sprints! and if you have laptop crunched you either have other dev taking over - so something else doesn't get done - or story that dev with crunched laptop is not going to deliver. That's just life and I also understand how disconnected management can be - but a lot of time you cannot say "exactly" when something will be done, because that is just not possible.
dilyevsky 2y ago
All of these shenanigans are just dancing around the intractable problem which is - nobody ever figured out a way to produce reliable estimates.
- skydhash 2y ago
  That’s because you’re dealing with a pile of abstractions on top of the cpu, data storage and channels that connect them all. You’re perched on top of the babel tower trying to figure where to put the next stone without everything crumbling around you. And you don’t even know the shape of the stone. You only have a vague description of it. Just too many unknowns.
parasense 2y ago
Also, the whole thing about "velocity" is just weird. It's as if some marketing goon heard the word "Velocity" and decided to over load the term in a manner that does not mean Velocity in the mathematical sense. Like in Calculus... the velocity curve is the first derivative of the linear graph, and the accelleration curve is the 2nd derivative. And for that matter, who cares about velocity, we have always wanted accelleration which sorta yields velocity. The problem with velocity, it's a dumb idea, because if I drop a rock from a tall building, it builds velocity as it free-falls down, and so it goes -- you have differetn kinds of velocity, but you only really have one kind of accelleration. Another issue, as the blog points out, story points are a simple scallar number, and you cannot easily say how that sum is factored into risk, complexity, effort, etc... So why even have it? Clearly a story needs to be a kind of vector with these properties (risk, complexity, effort...) set to possitive or negative values, and then do the typical vector math to plot the dirrection and magniture of the story in the n-dimensional space... Then, one can actually calculate stupid ideas like velocity or accelleration to speak in the language of project/program managers. Ultimatly the managers need a way to quantize the units of work done by development staff to better plan, and that's understandable, yet really hard. I think putting the cart before the horse is usualyl a dumb idea, and things should go back to measuring performan after the work is done, instead of estimating performance before work begins. Nobody wants to commit to a performance contract for each and every task ad nausium, and thats what happens durring sprints.

bboygravity 2y ago

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 love their faces when you teach them the special magic advanced project words for special software people.

drewcoo 2y ago
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.
- bboygravity 2y ago
  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.
- usea 2y ago
  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.
dennis_jeeves2 2y ago
>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.
IanCal 2y ago
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.

ozim 2y ago

But you have !sprints! and if you have laptop crunched you either have other dev taking over - so something else doesn't get done - or story that dev with crunched laptop is not going to deliver. That's just life and I also understand how disconnected management can be - but a lot of time you cannot say "exactly" when something will be done, because that is just not possible.

dilyevsky 2y ago

All of these shenanigans are just dancing around the intractable problem which is - nobody ever figured out a way to produce reliable estimates.

skydhash 2y ago
That’s because you’re dealing with a pile of abstractions on top of the cpu, data storage and channels that connect them all. You’re perched on top of the babel tower trying to figure where to put the next stone without everything crumbling around you. And you don’t even know the shape of the stone. You only have a vague description of it. Just too many unknowns.

parasense 2y ago

Also, the whole thing about "velocity" is just weird. It's as if some marketing goon heard the word "Velocity" and decided to over load the term in a manner that does not mean Velocity in the mathematical sense. Like in Calculus... the velocity curve is the first derivative of the linear graph, and the accelleration curve is the 2nd derivative. And for that matter, who cares about velocity, we have always wanted accelleration which sorta yields velocity. The problem with velocity, it's a dumb idea, because if I drop a rock from a tall building, it builds velocity as it free-falls down, and so it goes -- you have differetn kinds of velocity, but you only really have one kind of accelleration. Another issue, as the blog points out, story points are a simple scallar number, and you cannot easily say how that sum is factored into risk, complexity, effort, etc... So why even have it? Clearly a story needs to be a kind of vector with these properties (risk, complexity, effort...) set to possitive or negative values, and then do the typical vector math to plot the dirrection and magniture of the story in the n-dimensional space... Then, one can actually calculate stupid ideas like velocity or accelleration to speak in the language of project/program managers. Ultimatly the managers need a way to quantize the units of work done by development staff to better plan, and that's understandable, yet really hard. I think putting the cart before the horse is usualyl a dumb idea, and things should go back to measuring performan after the work is done, instead of estimating performance before work begins. Nobody wants to commit to a performance contract for each and every task ad nausium, and thats what happens durring sprints.