2 ms·

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 f

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.

brightball 2y ago
I’ll do that for a followup post. Watching the discussion here it seems like that would be beneficial. I struggled with where to put the emphasis on this write up but ended up deciding that I need to clearly make the case for Story Point flaws first as a warning reference for people experiencing these issues in their current environments. I would have separated queue management into its own post but thought writing about a problem without presenting the solution would result in a lot of “okay, so what should I do instead?” But that created a length complication where I had to keep it succinct because it was already a long post. Anyway, there will be a followup with more detail on queues. Probably the biggest complication for them is the lack of good reporting built around them in most existing systems.

brightball 2y ago

I’ll do that for a followup post. Watching the discussion here it seems like that would be beneficial. I struggled with where to put the emphasis on this write up but ended up deciding that I need to clearly make the case for Story Point flaws first as a warning reference for people experiencing these issues in their current environments. I would have separated queue management into its own post but thought writing about a problem without presenting the solution would result in a lot of “okay, so what should I do instead?” But that created a length complication where I had to keep it succinct because it was already a long post. Anyway, there will be a followup with more detail on queues. Probably the biggest complication for them is the lack of good reporting built around them in most existing systems.