5 ms·

While I loathe the useless abstraction layer that is story points and while I generally agree with all of the points in articles like these, they almost never t

While I loathe the useless abstraction layer that is story points and while I generally agree with all of the points in articles like these, they almost never talk about the other side of the coin, which is the need for predictability. Predictability is the oil that makes nearly every software business run efficiently and smoothly. It affects everything from software development to product roadmap to financial efficiency and profitability. Startups need to know if they have the ability to implement critical functionality before they're out of runway; big companies need to be able to coordinate product development, contracts, delivery dates, product launches across many disparate teams with interconnecting dependencies. Even deciding whether or not something is a roadmap priority requires some concept of how quickly you can implement it. So yes, productivity theater, as it exists in many project management processes today is unnecessary overhead and wasted time/money. But unless you are id software in the late 90s—flush with cash and sitting on a couple of products that only you can bring to market—you can't rely on "it'll be done when it's done" or "you'll know when it's ready when you see it" and expect to remain competitive for long. EDIT: Mobile typos.

pestaa 2y ago
Agile is not "it's done when it's done". Agile is "it makes sense every day of the week, we should talk often".
- intelVISA 2y ago
  Agile's one of the best things to happen to software in a way: it's good to know your competitors are stuck in ceremonies, arguing over story points.
  - loloquwowndueo 2y ago
    Looks like you’re talking about Scrum. Ceremonies and story points aren’t in any way mandated by the Agile manifesto.
    - yihtserns 2y ago
      There is no "ceremonies" nor "story points" in the Scrum Guide. Perhaps you are referring to "Fake Scrum".
      - loloquwowndueo 2y ago
        Daily scrum, sprint planning, retrospective and review are ceremonies, and they are totally mentioned in the guide. The guide also mentions the backlog refinement: “ This is an ongoing activity to add details, such as a description, order, and size.” It’s true that scrum doesn’t directly mention story points but tell me whether story points or t-shirt sizing aren’t the two most common ways to size a story.
        yihtserns 2y ago
        > Daily scrum, sprint planning, retrospective and review are ceremonies, and they are totally mentioned in the guide. Those are "Events", activities to support development work. Unless you mean programming, testing, discussions, code reviews, etc are ceremonies as well? > It’s true that scrum doesn’t directly mention story points but tell me whether story points or t-shirt sizing aren’t the two most common ways to size a story. Borrowing your own words: "...story points aren’t in any way mandated by the..." Scrum Guide.
  - JustBreath 2y ago
    One of my favorite responses to criticism was Dan Abramov telling people if Redux doesn't work for them, don't use it! Keep what works for you, leave what doesn't.
- wilkystyle 2y ago
  Not sure if this is intended to expand on my comment or to be a rebuttal to it, but to be clear: I am in full agreement with you. My comment strictly refers to many of the articles[0] and comments[1] that push back on the modern incarnation of scrum/agile/whatever. Productivity theater in project management is net harmful to innovation and actual product development velocity, but my point is that we can't go to the other extreme and have no planning or any kind of measurement. [0] https://rethinkingsoftware.substack.com/p/why-scrum-is-stressing-you-out https://rethinkingsoftware.substack.com/p/why-scrum-is-stres... [1] https://news.ycombinator.com/item?id=41545101 https://news.ycombinator.com/item?id=41545101
  - pestaa 2y ago
    In this case, an expansion. :) Agile was ruined because of this need to be predictable and adaptable to plans. And business folks often overlook that it is predictable and adaptable -- just not in the way project managers were educated in the old days (or even to this day, I don't know) expect.
snarf21 2y ago
I despise SP too. I have come to the conclusion that all estimates should only ever given in terms of magnitude. "Some small number of hours/days/weeks/months/quarters/years". If product or leadership want more precision, break tasks into smaller self-contained tasks.
kylestlb 2y ago
It's weird to me that people have emotional feelings about Story Points as a concept. It's just another way to measure how hard something might be. I think what people should really be annoyed with is when these measurements are used as some sort of productivity metric, or if the team spends too much time debating a particular measurement value and not enough time actually working on it.
- cortesoft 2y ago
  My annoyance with story points is how it always seems to end up returning to “how many hours of work will it take”, even though the whole point of using story points is to get away from trying to predict how many hours of work something is.
  - AnimalMuppet 2y ago
    You don't predict that. You measure it. That is, we estimate a certain set of tasks. For this two-week sprint, we're going to try to do a subset, and that subset adds up to 20 story points. After two weeks, how much did we actually get done? 7 story points. Next sprint we did better, we got 11 done. After a few months, we settle down to an average of 10 story points per two week sprint. Now we know how many hours something is (estimated to be) based on the story points. Note well: This velocity is a function of the team. If the team composition changes, previously measurements of velocities are no longer valid.
    - cortesoft 2y ago
      In all my years of software development, story points never became an accurate predictor of time, even with consistent teams and process. The types of tasks we would be working on varied too much and were too novel to become predictable. If we were working on one app and just adding features and fixing bugs, maybe it would converge to a consistent average. However, I have always worked on teams that have myriad projects, moving in and out of development, with constant support and interrupt driven work taking up a huge variable amount of time.

pestaa 2y ago

Agile is not "it's done when it's done". Agile is "it makes sense every day of the week, we should talk often".

intelVISA 2y ago
Agile's one of the best things to happen to software in a way: it's good to know your competitors are stuck in ceremonies, arguing over story points.
- loloquwowndueo 2y ago
  Looks like you’re talking about Scrum. Ceremonies and story points aren’t in any way mandated by the Agile manifesto.
  - yihtserns 2y ago
    There is no "ceremonies" nor "story points" in the Scrum Guide. Perhaps you are referring to "Fake Scrum".
    - loloquwowndueo 2y ago
      Daily scrum, sprint planning, retrospective and review are ceremonies, and they are totally mentioned in the guide. The guide also mentions the backlog refinement: “ This is an ongoing activity to add details, such as a description, order, and size.” It’s true that scrum doesn’t directly mention story points but tell me whether story points or t-shirt sizing aren’t the two most common ways to size a story.
      - yihtserns 2y ago
        > Daily scrum, sprint planning, retrospective and review are ceremonies, and they are totally mentioned in the guide. Those are "Events", activities to support development work. Unless you mean programming, testing, discussions, code reviews, etc are ceremonies as well? > It’s true that scrum doesn’t directly mention story points but tell me whether story points or t-shirt sizing aren’t the two most common ways to size a story. Borrowing your own words: "...story points aren’t in any way mandated by the..." Scrum Guide.
- JustBreath 2y ago
  One of my favorite responses to criticism was Dan Abramov telling people if Redux doesn't work for them, don't use it! Keep what works for you, leave what doesn't.
wilkystyle 2y ago
Not sure if this is intended to expand on my comment or to be a rebuttal to it, but to be clear: I am in full agreement with you. My comment strictly refers to many of the articles[0] and comments[1] that push back on the modern incarnation of scrum/agile/whatever. Productivity theater in project management is net harmful to innovation and actual product development velocity, but my point is that we can't go to the other extreme and have no planning or any kind of measurement. [0] https://rethinkingsoftware.substack.com/p/why-scrum-is-stressing-you-out https://rethinkingsoftware.substack.com/p/why-scrum-is-stres... [1] https://news.ycombinator.com/item?id=41545101 https://news.ycombinator.com/item?id=41545101
- pestaa 2y ago
  In this case, an expansion. :) Agile was ruined because of this need to be predictable and adaptable to plans. And business folks often overlook that it is predictable and adaptable -- just not in the way project managers were educated in the old days (or even to this day, I don't know) expect.

snarf21 2y ago

I despise SP too. I have come to the conclusion that all estimates should only ever given in terms of magnitude. "Some small number of hours/days/weeks/months/quarters/years". If product or leadership want more precision, break tasks into smaller self-contained tasks.

kylestlb 2y ago

It's weird to me that people have emotional feelings about Story Points as a concept. It's just another way to measure how hard something might be. I think what people should really be annoyed with is when these measurements are used as some sort of productivity metric, or if the team spends too much time debating a particular measurement value and not enough time actually working on it.

cortesoft 2y ago
My annoyance with story points is how it always seems to end up returning to “how many hours of work will it take”, even though the whole point of using story points is to get away from trying to predict how many hours of work something is.
- AnimalMuppet 2y ago
  You don't predict that. You measure it. That is, we estimate a certain set of tasks. For this two-week sprint, we're going to try to do a subset, and that subset adds up to 20 story points. After two weeks, how much did we actually get done? 7 story points. Next sprint we did better, we got 11 done. After a few months, we settle down to an average of 10 story points per two week sprint. Now we know how many hours something is (estimated to be) based on the story points. Note well: This velocity is a function of the team. If the team composition changes, previously measurements of velocities are no longer valid.
  - cortesoft 2y ago
    In all my years of software development, story points never became an accurate predictor of time, even with consistent teams and process. The types of tasks we would be working on varied too much and were too novel to become predictable. If we were working on one app and just adding features and fixing bugs, maybe it would converge to a consistent average. However, I have always worked on teams that have myriad projects, moving in and out of development, with constant support and interrupt driven work taking up a huge variable amount of time.