Comment by wilkystyle

Comment by wilkystyle 12 hours ago

22 replies

View on Hacker News

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 12 hours 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".

Reply View 5 replies
  • wilkystyle 12 hours 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-stres...

    [1] https://news.ycombinator.com/item?id=41545101

    Reply View 0 replies
  • intelVISA 12 hours 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.

    Reply View 3 replies
    • loloquwowndueo 11 hours ago

      Looks like you’re talking about Scrum. Ceremonies and story points aren’t in any way mandated by the Agile manifesto.

      Reply View 1 reply
      • yihtserns 10 hours ago

        There is no "ceremonies" nor "story points" in the Scrum Guide. Perhaps you are referring to "Fake Scrum".

        Reply View 0 replies
    • JustBreath 11 hours 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.

      Reply View 0 replies
snarf21 12 hours 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.

Reply View 0 replies
kylestlb 12 hours 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.

Reply View 14 replies
  • cortesoft 12 hours 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.

    Reply View 3 replies
    • AnimalMuppet 11 hours 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.

      Reply View 2 replies
      • cortesoft 11 hours 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.

        Reply View 1 reply
        • hinkley 10 hours ago

          Management always gets frustrated when this doesn't materialize. If the instrument meant to keep management off your back doesn't do so, people will get frustrated with it.

          Reply View 0 replies
  • saghm 10 hours ago

    In my experience, they're always just used as some abstraction over amounts of time, which doesn't seem particularly useful but also isn't objectionable. What's weird to me is how specific the patterns are sometimes; I've worked on more than one team that insists on only using Fibonacci numbers for story points, but also that anything as large as 8 should be broken up into separate tasks, which effectively means that they used the range 1-5 but forbid usage of 4. On one of those teams, during one planning meeting someone mused that they wished there were something they could use to represent "less than 1", and I suggested we try putting 0.5 story points into JIRA, which to everyone's surprised actually worked, so 0.5 became the only other allowed value.

    Reply View 0 replies
  • mewpmewp2 11 hours ago

    I think SP or similar need to exist for it to be possible to make decisions and prioritise, but issues arise when part of the company, e.g. leadership or managers don't understand that SP are more like guesses with risk and probability involved and they will be disappointed when the end result won't be as accurate.

    So naturally people will come to despise it because managers will want a number and to hold you to that number. A strict number can't be given, but intuitive guess which has certain probability of being in a certain range according to experience can be.

    Reply View 0 replies
  • rybosworld 11 hours ago

    Just to play devils advocate:

    If you have two engineers and one consistently completes 10 points a sprint and the other only completes 2 points a sprint, does that not tell you something about the output of those engineers?

    Reply View 7 replies
    • rebeccaskinner 11 hours ago

      At best it may indicate that there's something worth looking into, but it doesn't tell you much about the actual productivity of the engineers. One engineer may be producing low quality output that requires a lot of re-work later, or they might be gaming the system by over-estimating work, or picking up lower priority work that was accidentally over-estimated in order to improve their numbers. They may be a domain expert in a particular system while the other developer is getting up to speed. One developer may be spending significantly more time mentoring or helping their team work better. They might be writing design documents or spending more time with customers. They might have been around longer and are regularly getting pulled into supporting things they worked on years ago, or getting asked for help from other teams who need their expertise.

      Reply View 1 reply
      • hinkley 10 hours ago

        > At best it may indicate that there's something worth looking into

        Or as I usually put it: Statistics/charts are for asking questions, not answering them.

        Reply View 0 replies
    • mrgoldenbrown 11 hours ago

      Not without much more data. Is the 2 pt engineer the one senior who supports all the juniors and multiplies their effectiveness by getting them unstuck, or is the 2 pt engineer the one who always takes the hard (misestimated) stories, or maybe they are the CEO's nephew and they just suck. No way to know just from pts completed.

      Reply View 0 replies
    • saghm 11 hours ago

      Does it tell something that couldn't be equally (or better) represented by not pretending that story points are time estimates rather than something abstract?

      Reply View 0 replies
    • a12k 11 hours ago

      Not without more data.

      Reply View 0 replies
    • exe34 11 hours ago

      no, it tells you more about what sort of tasks they excel at and how story points are chosen. it's important not to extrapolate beyond what your measurement supports.

      Reply View 1 reply
      • hinkley 10 hours ago

        Mr 2 Points might be taking one for the team, doing a task that would cost Mrs 10 Points 3-5 points of productivity if they were saddled with it.

        Low point stories that take a lot of time are often coordination tasks, and for people who are good at heads down programming, that can be their kryptonite.

        It's also possible that Mr 2 Points is not getting fed stories that they could weave into the blocking points of their highest priority task effectively. He is spending a lot of time working on untracked tasks or sneakily working on stories halfway down the backlog. And they can't do it in the open because someone is engaging in Efficiency Theater: we are so far behind on some milestone that the optics of anyone working on anything except that milestone are terrible.

        Nevermind that the next milestone needs them and we will be having this Death March repeat again in three months because of it.

        Reply View 0 replies