Story points are pointless, measure queues

I wish the article spent longer with discussing the queuing view and less time on pointing out the flaws with story points, but I guess I'm biased because the flaws already are "obvious" to me.

I think there's an inherent tradeoff between the overhead and misery of breaking down a task into granular subtasks and the variance of task completion time. In practice what this would mean using a queue style form of tracking would be that you trust your team to break down work and do time-bounded investigation into unknowns. Then you look at your task completion rate. Now measuring this as an RV gives you not just the average task completion time, as we reduce to using Little's Law, but also variance of task completion time. If we find task completion time to have too much variance despite the input queue length of tasks not actually growing very much (i.e. the arrival rate is staying stable and low), then it's probably worth having the team break down tasks in a more granular fashion (or maybe it's a single person who keeps making giant tickets or something). On the other hand if the team keeps complaining about straight-jacket ticket discipline, it's probably worth letting folks be more loose with task creation. There's a human element here but there always is, since it's humans who are doing the work, and that's fine.

I've always argued that output per person on a team should be modeled as RVs, but I really like this queuing approach and it's something I may bring up on my team. Again in practice I'd probably just track task completion times on a weekly basis. This would be much simpler than story points and instead of the bickering that comes with trying to break a ticket up, it would give engineers more autonomy over task creation.

I really like the idea.

>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.

Counterpoint: it's extremely useful for the Trisolarans to know when their next stable period will be, but that doesn't make it reasonable to demand an estimate and factor it into a contract unless you're really really clear about the uncertainty in the estimate.

From when I was doing kanban there were, very intentionally, little to no forecasting done. We broke up a feature a bit and started chugging along. Every question from mgmt like "when will it be done?" was met with a "we are working on that right now, so asap" and that flew. However that was a stable product that was mature and had quite a few customers paying an annual license that were mostly happy, but of course appreciative for new features. Right now I'm working on a bigger product that fails to capture customers in a highly competitive sector and everything is about time and estimates. Middle mgmt is pretty stressed out and the latest bid is to estimate tshirt sizes. But really, it should be translated to time/increments.

> 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 make some improvements and added some rough estimates of how long it would take to trial each idea. Of course, what's actually happening is that we try one idea, it counter-intuitively makes performance worse, we dig into why that's the case and refine the idea, then try a different version of it. It's fundamentally impossible to give an estimate for when we will have run through all the ideas (plus new ones we think up along the way) and how much of an improvement it will make.

I just came out of a slightly painful standup where the dev manager repeatedly asked "Is this doable by mid-August?", and I repeatedly answered that it's not possible to give such an accurate estimate, that we would do what we can in that time and hope to give a better idea of what's possible by the end of this month. Of course it's not great for the dev manager to hear, because they have a client who needs to know how quickly they can scale up their use of the service. There's a conflict between what we can possibly know and what the client "needs" to know. I wish that I knew how to resolve it. It feels wrong to agree to deliver something with such a level of uncertainty, since it just leads to a ridiculous amount of pressure like this.