Story Points: Explicit, Honest, Predictable. Already in Use.

[-]

chasetheusername@reddit

The main problem with story points is that they become a metric, which is used to measure things like velocity, and team performance.

Then you have massive differences in a team when it comes to implementing specific features, for some people it'd take a day, for others the whole sprint, so what do "story points" actually tell us? Nothing, at best a basic measure of complexity, which is like "easy, mid & hard", but the discussions if it's a 2, 3 or 5, can take longer than instructing an LLM to fix it, and to actually fix it.

I believe Story Points are completely useless when estimating features/bugfixes without having fully understood all required consequences, and understanding those consequences is actually the time consuming part.

Also, with the support of LLM assisted coding, sometimes a 5 pointer can be resolved in a hour with an LLM, while a "simple'ish" seeming 3 pointer will take half a sprint.

[-]

theScottyJam@reddit

You lost your car keys. I ask you to give me an estimate of how long it will take to find them.

Well, it could be a minute. It could be an hour. Maybe you had grabbed a handful of trash and accidentally caught the keys in that handful, and after a long time of searching, you eventually have to rummage through your trash to find it (definitely not speaking from experience or anything).

We could do an analysis of how often it has taken you to find lost keys in the past, but you've never lost them at a playground before, this will be a new challenge with different unknowns.

Some things we do are pretty easy to predict. I know how long it will take to add a new CRUD-like REST endpoint. Some things are much harder. I have zero idea how long it will take to integrate with X third party library.

This article suggests that for tasks with lots of unknowns, just give it more story points. That's probably the best you can do, but it's not really any better than artificially padding a time based estimate.

With some tasks, we nights as well be predicting the stock market. No amount of analysis of previous behavior is going to help us predict that - we might think we see certain trends, but we're always going to be surprised.

In the end, managers still want a time estimate and we still have to give them something. And perhaps story points can help increase accuracy to a degree, but we're still trying to pretend that we can predict items with unknowns that span orders of magnitudes of time simply by using heuristics of past unknowns, which don't necessarily help.

Sorry, bit of a doom post, since I'm just bringing up problems without any solutions to go with it. Guess I just want it to be clear that even story points can't solve the biggest problems here.

[-]

strugglingcomic@reddit

I know this is a bit of a tangent, but I also feel like, either side of this points vs hours debate invariably ends up strawmanning something, usually to everybody's detriment.

Let's take your example of lost keys. I 100% agree that it's effectively impossible to predict with any reasonable degree of precision or accuracy.

But consider the following (scoping) questions:

How long would it take you to check the most common places you've previously found your keys? Surely a 10 minute walk around your house will cover the most likely suspects.
How much likelihood do you think your 10 minute search would cover? Maybe 80% of the time, you'll find it in one of the likely spots, and 20% it'll be in some unlikely spot?
Assuming you need to go down the unlikely route, then what is the last time you know you had your keys? How long would it take to retrace your steps from then?

Notice I am not trying to answer the original question with a discrete single answer. I am trying to generate bounded complexity timeboxes (another common agile tool, that I guess I don't know why people don't bring up more often). My goal is to give my hypothetical boss answers not of the form "it will take me X hours to find the keys", but rather of the form "after 10 minutes I will be able to either find the keys, or say with 80% certainty it's not in the common places and we'll need to do more uncommon, time consuming work; if I need to retrace my steps, I would start from last known spot Y and spend Z minutes looking there".

Bosses are unreasonable if they only accept single discrete answers with no flexibility. But engineers are also unreasonable if they throw up their hands at the impossibility of estimations, and don't try to break down the complexity with actual units of progressive iteration. After all, we are engineers, not physicists or mathematicians -- we don't need to deal in truths, we just need to generate empirical progress.

[-]

theScottyJam@reddit

I love that approach. And perhaps it doesn't need to be that precise - at least when it comes time to communicating it up the line.

I've been lucky enough that at my company, I can say things like "I think this would take me a day, but there's various aspects I'm uncertain about, and it could take up to a week.", and they're happy with that.

[-]

theScottyJam@reddit

This article suggests that we should

Minimize assigning tasks in advance.

Which makes sense if we want the story point estimates to be separated from individual biasses. But maybe we don't want that? Maybe it could be more accurate for everyone to have specific tasks assigned to them in advance and they all predict their own abilities with that task?

Thing with story points is that we assume that an individuals speed with a particular story only coorilates to their skill level and nothing else. But, it can also corelate to how comfortable they are with that section of the codebase, for example. And there's nothing currently in place to account for that - the fact that Bob, who's usually has a high velocity would go really slow on X ticket because they're just not as good at that one.

Now, there's of course other problems with assigning all tickets in advance that could cause more problems then they solve. But, just pointing out that it could make for more accurate estimates.

[-]

areklanga@reddit (OP)

TL;DR: Every time a software estimate is inflated to absorb uncertainty and daily overhead, it stops measuring actual time and turns into a messy abstraction. Once your "hours" and "days" become a proxy for effort rather than the clock, you are already using Story Points implicitly. Dropping the self-deception and openly embracing this abstraction brings structure to your planning and helps reliably predict delivery without the guessing game.

My personal note: this is not AI-generated article, please don't delete it and don't consider as one more article with retelling of some existing ideas. Initially the insipration for the article was an argument with my manager about using Hours vs Story Points. I really spent a lot of time trying to structurize and compile my experience into readable format. At least give it a try.

[-]

theScottyJam@reddit

Thanks for the note that it isn't AI made. It makes me more willing to dive deeper into the article.

[-]

jeenajeena@reddit

You might be delighted to discover that who invented agility have always meant to make time estimations, and that story points were just an incident https://ronjeffries.com/articles/019-01ff/story-points/Index.html

[-]

areklanga@reddit (OP)

Thanks a lot for sharing! I didn't meet this article before and just finished reading it. It partially controverses ideas from my article but I do like how it sounds from the point of a developer. At the same time managers often have budgets, timelines, and require statistics, metrics, specific numbers. And my article is about how to build those nunmbers and make possible to constructively operate with them.
I will reread this link several times more to better grasp the concepts because to be honest at least at first glance they feel quite attractive..