I have 12 YOE and after all of these years still not convinced that story points is better than time estimation.
Posted by Dependent-Guitar-473@reddit | ExperiencedDevs | View on Reddit | 180 comments
Yeah, I know it measures the effort... but so does time... and everyone in the team can be so much more accurate about it.
DrFloyd5@reddit
You need each devs velocity.
A SP is a time free metric. Multiply it by the velocity (story points per day) for a specific dev to get time.
Not tracking velocity? Well then I can see why you want to equate SP to time. Because you are doing it wrong.
Even if you fake it 1 SP = 1 Day you still have to account for velocity if you want accuracy. Otherwise you are going towards team average. And at that point you might as well just keep using SP because neither method is accurate on a personal level.
And if you are trying to optimize the number of points by accounting for each individuals developers talent for any specific ticket, good luck. At that point you are running mini waterfalls.
notmsndotcom@reddit
So again, it is time. It’s just that every individual has a separate productivity coefficient. You could say the average engineers velocity is 12 points. Just because someone else’s velocity is 8 points it doesn’t make it any less of a time measurement because you know it’s going to take them longer per story point.
DrFloyd5@reddit
Yes, if you multiply it by a time factor you can convert SP to a duration.
The key word is “convert”.
Before the conversion it is not time. After the conversion it is not story points.
notmsndotcom@reddit
Uhhhh, but you're ignoring the fact you divide by the time factor on the front side.
You start with time. Divide by a time factor to get the points for an engineer. It's still a time estimate function.
DrFloyd5@reddit
What is the front side?
notmsndotcom@reddit
Story points aren’t some unique unit of measurement. In grooming or sprint planning, you story point cards. You either let the individual engineer who will be working on it do the estimation, or you estimate as a team (planning poker style) and try to point them based on an average skill level (ie assuming the person who takes this card is mid level and relatively up to speed it should be X points)
Regardless of which method you use to point, it all starts with a time estimate. You then convert time to points (possibly throw in a Fibonacci point system for funsies). If it starts with a time estimate, gets converted to points, but can be converted back easily…it’s still a time estimate you're just attempting to be standardize it.
From the Scrum book itself in the "Plan Reality, Not Fantasy" chapter:
"What kind of dog is it? Don't estimate in absolute terms like hours, it's been proven that humans are terrible at that. Size things relatively, by what breed of dog the problem is, or T-shirt size, or, more commonly, the fibonacci sequence.
Velocity x Time = Delivery. Once you know how fast you're going you'll know how soon you'll get there"
More relative time == bigger tshirt size or story point value. And if your points aren't based off of some aspect of time, your Velocity x Time = Delivery won't math
DrFloyd5@reddit
Well that’s the thing, if you start with time.
The agile guidelines recommend against using time. Right in your own comment.
Let me ask you this: a ticket is 8 SP, how long will it take? You can’t tell me because you need additional factors. If SP = Time you could make the conversion like inches to CM, with a constant.
I admit SP and time are close but they are different in that both a junior and a senior can agree on the complexity of a job together, where a junior usually has no chance at estimating time.
A junior and a senior can say well… we need to modify 20ish files, build a service, the date math is a bit tricky, and we have to coordinate with another team. So 13 points.
A senior has the gut feeling that it will take 3 weeks, maybe 8. A junior has no clue. And will usually say 5 days.
With experience you can get a feel for the points to time conversion for yourself or the team, but they are fundamentally different measurements.
Hypothetically, you can determine SP mechanically through code analysis and the problem description. An AI could do it. But you cannot determine the time without additional information.
YOU might be using your time estimate to back into SP because you have evidence and internalized your velocity, and well, you get a sense of these things. Your personal conversion won’t inform how long it will take Bob to do it without knowing additional data.
studio_bob@reddit
A PM friend of mind told me that the purpose of story points is obfuscation and dodging accountability. Everyone can understand what time means. Success/failure and expectations can all be clearly defined when conversations are conducted and planning done in units of time. It becomes trivial to pin someone down for not delivering on a promise or going over budget.
Story points keep things vague, loose, who the hell knows what they really mean? Reporting becomes much more subjective and thus easier to manipulate. Planning sessions are allowed to be likewise vague because the estimates and implied commitments are so meaningless that there is little sense in trying to justify them too deeply and even less fear of accountability. To be clear, certain kinds of managers love all of this! But I do think there are better ways to run a project.
JimDabell@reddit
That might be why they use them, but it’s not the purpose of story points.
Stories were originally estimated in “ideal days”, which was how long it would take if everything went well and you had uninterrupted focus the whole time. But stakeholders kept misunderstanding “ideal days” as real days, so they switched to calling them “story points” instead to avoid the confusion.
The idea that story points are an abstract notion of complexity divorced from time altogether is a myth. Read about it from the person who invented them.
studio_bob@reddit
I am talking about practical application, not their theoretical purpose. Frankly, workplaces are political environments and so management concepts like story points/AGILE/whatever almost inevitably become tools for mediating conflicts between competing factions, most often between different levels of management and labor. That may be far removed from the intent of their creators, but it's a common theme I've found in different workplaces.
And to be clear, my friend doesn't use story points. What I outlined were his stated reasons for avoiding them after years of trying to make them make sense and work for his teams.
lelibertaire@reddit
Yeah sounds like something a PM would say
Dependent-Guitar-473@reddit (OP)
why this reads like its some insider information :D
after reading 100+ comments.. i have 100+ opinions :D
Yweain@reddit
Well, estimating time is hard. Estimating complexity is simpler, mentally. After a while you get enough statistics to convert complexity to time, and it is usually more accurate than estimating time directly.
PoopsCodeAllTheTime@reddit
"estimating complexity is simpler" sounds like an oxymoron
Yweain@reddit
Why? It’s really easier for majority of people to guesstimate an abstract number. Coming up with specific number of days is way harder. The commitment feels more strict, and the number is way more tangible, so most are very hesitant .
PoopsCodeAllTheTime@reddit
It is very easy to agree on an abstract number as a group because it is meaningless and because it is a good way to silence anyone with actual arguments. The majority speaks louder, but last I checked my piece of code is not going to be written by the majority.
I don't see how this makes a commitment any more strict, unless you feel some kind of peer pressure, which isn't necessarily going to help you make better decisions for the software.
Dependent-Guitar-473@reddit (OP)
as a developer, i think in time... i know what I am supposed to do and how long it will take me to do it..
alsoa simple things might take a very long time (should I give it high story point?)
while something super difficult and complex, but I can figure it out in 1 hour will get 2 points?
Yweain@reddit
I think in time as well. But a lot of people have no idea how much time each task they are assigned to would take. Like VAST majority of people have no idea. But, somehow, they can give a number of overall complexity of the task(it’s usually assumed that story points are combination of pure complexity and effort. So three lines of code, but very complex, might get 5 and very simple but laborious task might also get 5).
So from a management perspective it’s usually better to just ask everyone to estimate in story points and convert to time later.
Crafty_Independence@reddit
This is completely opposed to the purpose of story points though. The moment management turns them into a way to calculate time, it's no longer a complexity estimate but a time estimate.
puremourning@reddit
You don’t say.
Constant-Listen834@reddit
But every engineer can do a story point and different speeds. On senior may take 1 day per point but a junior 3 days per point
PoopsCodeAllTheTime@reddit
You can never make these translations accurately. Each person must score their own tasks, otherwise it's pointless (incidental pun).
Constant-Listen834@reddit
But every individual scoring tasks differently makes planning impossible. The point of the points (I hate this) is that you can vaguely use them to predict how many weeks a team will take to deliver something
PoopsCodeAllTheTime@reddit
I understand your point in theory, but in practice this is never going to give you an accurate delivery date.
The cycle repeats itself every time:
PuzzleheadedPop567@reddit
It’s funny that you just restated the title of the thread. So…you’re talking about wall time estimation.
Jadien@reddit
Yes, there are:
Really depends on the person:task
diablo1128@reddit
They way I learned about story pointing, this just doesn't matter. If a team can get 20 points done every 2 weeks, it doesn't matter how those points are distributed. It's about how many points the team can accomplish in a given period.
It's not about everybody doing the same number of points, it's about trying to figure out how much work a team can get done. Then taking that data and extrapolating it out to come up with an overall estimate of when all the work in the backlog can get done.
pizzapiepeet@reddit
it's really a nice thing when managers do treat points this way, though.
at least in my experience, it keeps backlog refinement sessions focused more on unpacking requirements, approach, and breaking work down. Actual estimation takes 20 seconds per ticket: "This one more or less complicated than the last? Sounds easier? ok it's a 2 not a 3. Next..."
Gut feeling is that some ticket is pretty chunky but doable in a sprint? Could spend more time breaking it down to get a more granular time estimate. Or, just throw some extra points on it and move on.
It's nice to not really have to think about time or estimates too hard. Sure, subconsciously we've probably made a mapping, but during estimation we're just throwing gut feeling numbers out and nothing more. Over time the extrapolation maths work out well enough.
I suppose all these arguments could be made for time-based estimates too, though. The important thing seems to be whatever unit you're estimating in, consistency is more important than absolute accuracy at the most granular level.
Constant-Listen834@reddit
This is true and I agree with you 100%
I’m just saying it’s better to call them ‘points’ instead of ‘days’ because depending on which engineer picks it up, the days will change but the points will not.
But yea, it’s all a joke anyways. It’s stupid but PMs need something to justify their jobs I guess. I’ve never liked story points at all. Take me back to the good ol days
justaguy1020@reddit
The entire premise is that those little nuances average out over time as long as you point relatively consistently
labab99@reddit
If you tailor the estimate of a story to the person who will be working on it, then it is much easier to plan ahead to satisfy the needs of the scrumfall overlords.
baconator81@reddit
It’s because the hour differs between engineer skills. A person that knows a system well might only take 1 day but a person that doesn’t know it well can take 2 days. Unless you only ever give out estimates on the work you are going to do then yeah hour is fine. But if you are estimating work that might get assigned to someone to be determined, then hour makes no sense. And in fact the hour number would be biased by the person doing the estimation
Ashamed_Soil_7247@reddit
This is so absurd. As if story points were an objective estimate that transcends skill differences. Both are subjective measures
baconator81@reddit
It’s not perfect. But it’s a way to get ppl to think about how complicated a problem is instead of how fast I can solve it .
Ashamed_Soil_7247@reddit
I can't think of how fast I can solve a problem without thinking about how complex it is, though
ltdanimal@reddit
I'm not trying to harp on the OP but the fact that someone can have 12 years of experience and not get this shows why this work is so difficult. People often shit on story points but don't even gets the basics of why they work so much better.
Also putting time on items is just asking for someone in leadership to ask "Why is this 2 day task taking 5 days?". Even if its in good faith it just sets up the wrong expectations.
Crafty_Independence@reddit
This isn't just OP. The guy who developed story points says it was a mistake
baconator81@reddit
I believe you are referring to this blog.
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
In the end, he acknowledges that it's something that can be easily misused, but at the same time. ideal hours isn't much better as well. It's one of those we need something, what's the lesser of two evils?
Crafty_Independence@reddit
Kanban with time boxing is better than both, being simpler and more accurate
Dependent-Guitar-473@reddit (OP)
There's a reason I am not switching to manager and became an Engineering manager... You i know I belong to the code, not management & KPIs.
but still I had to see every developer struggle with story points ... not saying they are not important, but developers simply don't think in complexity, and it's not standardized
But above junior level, time is almost the same for all developers
kayakdawg@reddit
wouldn't points be biased in the same way? couldn't hours be calibrated in the same way as points to account for differences in abilities?
Crafty_Independence@reddit
They absolutely are even though they shouldn't be
ianpaschal@reddit
Not really. The idea is that the complexity is an inherent property of the ticket, whereas the time to complete it is a function of the complexity and the skill/experience of the developer working on it.
At least, in theory. I prefer time estimates as well, and in a lot of small teams the person who will pick it up is known from the get-go, so if front-ender Steve says its gonna take him 2 days, there's not really any point in knowing it would take back-ender Rob 5 days to figure out.
jashro@reddit
Fucking Back-ender Rob.
Goodie__@reddit
Not necessarily. If you assume a straight line between "points" and "time taken", assuming that all time taken is the same, then yes, points make no sense.
But if you remove that assumption, and know that a 4 point story given to a junior might be 2 days, but given to a senior is half a day, points make far more sense. It's still 4 points, it just happens to relate to an hour for a senior, or half day to a dev. On average it might be 3 for the team.
It also encourages silo-ing of developers, in my experience. Because you're estimating by time, and usually the person most familiar with that part of the system offers up the estimation because they know it best, no one else gets a shoe in to that part. There's no explanation. There's no talking. Just "Yeah, the API guy says it'll take 2 days".
When using points and having to come to a consensus, you have to explain and defend your score, you discuss it.
grizzlybair2@reddit
They are ... I do like 25 points in a sprint when it's stuff I know. Then when it's mainly stories i don't know how to do or paperwork, I get like 3-5 points done.
jessiescar@reddit
But that could also be a problem. I've been in teams where I was the only enginner that give 5 points to some task (because I was new) and the rest of the team ended up giving it a 3. We estimated it at 3, but the task ended up with me anyway.
ikeif@reddit
I've always pushed that "if someone has higher, the team has to justify why it should be lower, and if it's pointed for the team — you point to ANYONE doing the work, not just "people who are familiar with it."
So yeah, someone new joins, the points raise, but they lower over time (but occasionally there are always tasks where it's clear a certain individual will own the task, so they point it for themself and that's agreed as a group.)
baconator81@reddit
That’s fine . They know you are new that’s why it will take longer for you. The important thing is if there is a task that’s actually 5, they expect it to take even longer for you (assuming you are not familiar with that task)
alephaleph@reddit
I have a dream that every engineer will be judged not by the sum of their points but by the content of their delivered features.
gingimli@reddit
But that would require the product manager to think instead of just adding up numbers.
NicholasMKE@reddit
As an agency consultant I can get away with this for our teams (often we’re just crossing todo items off of an SOW so it’s easy to know what value we’re delivering), but then whenever I try to explain that to in-house teams in turns out a lot of orgs don’t know how to understand the business value of what they’re building 🙃
malln1nja@reddit
What if my main contribution is reviewing design docs and PRs and try to prevent people from shooting themselves on the foot?
Dependent-Guitar-473@reddit (OP)
we will call you a low velocity developer
nightzowl@reddit
Why are responding sarcastically to a genuine question.
Dependent-Guitar-473@reddit (OP)
It's a joke, man :D
because if he didn't finish many story points... his velocity will be low :D even if he is spending his time helping everyone :D
take it easy bro
nightzowl@reddit
That “velocity will be low” thing you mentioned is not true in the context of what that commenter was responding to
Dependent-Guitar-473@reddit (OP)
The commenter himself is fine with it... i appreciate your concern but leave it be
malln1nja@reddit
As long as it gets me a severance next time around, I'm fine with it . Problem is so far I have not been picked 3 times.
Dependent-Guitar-473@reddit (OP)
omg :D was the serverence that good ?
jrdeveloper1@reddit
Manager: so… we’ll call it a 3 point ?
Own-Chemist2228@reddit
...which is 3 days... right?
Dependent-Guitar-473@reddit (OP)
lines changed in git :D
AmishMountaineer@reddit
A meriSLOCracy?
ikeif@reddit
I love to see commits that have more lines removed than added.
Dependent-Guitar-473@reddit (OP)
Me too, that's why I said lines changed, not added ... i got you bro :D
Raukai@reddit
The FBI would like to know your location
barndawe@reddit
Yes, I have a dream today!
whodadada@reddit
“How long will it take?” .,. “15 story points” 😎🤣
EdelinePenrose@reddit
hack: 1 sp = 1 day
smutje187@reddit
Just use days? Never understood engineers who let themselves get told by project managers that time estimations are of any value.
EdelinePenrose@reddit
i think we’re saying the same thing. if you’re forced to use story points then just set them equivalent to days. no?
smutje187@reddit
No, SP aren’t comparable/translatable to days - and anyone who thinks should just use days instead of pretend-SP
EdelinePenrose@reddit
alright, have fun fighting people.
smutje187@reddit
Why fight? Tell them to just use time if they want to estimate time and don’t let yourself get bullied around by delivery people.
EdelinePenrose@reddit
oh, dear, don’t project now.
remedy75@reddit
Story points are meant to be measures of complexity, effort, and uncertainty… not time.
EdelinePenrose@reddit
cool. see my previous comment lol
SolarNachoes@reddit
We use them to estimate projects for clients. They pay an hourly rate.
ImSoCul@reddit
do better? You can actually do more as a PM than 2+4+2+1
Work with your team to come up with lower and upper bounds for tickets/projects. Bake in confidence intervals, potential risks to timelines, figure out where project can be accelerated by good planning. Then use this to compile an estimate.
I try to explain to PM what the nuance and risk areas of project are. If PM is a lazy shit, then I just give them a random number I pulled out my ass, it's not my problem.
0xFatWhiteMan@reddit
Who are you ranting at?
ImSoCul@reddit
PMs in general. in this case you
0xFatWhiteMan@reddit
Good luck in life with that attitude.
ImSoCul@reddit
what attitude? lol
Literally calling out an opportunity for improvement and you're like "no 2+4 is all I do".
Confirms my bias
0xFatWhiteMan@reddit
Dude, I'm not a pm.
SolarNachoes@reddit
Clients are paying millions spread over multiple projects. They need estimates to manage budgets, resources, schedules, dependencies, timelines, deliveries, etc.
ImSoCul@reddit
Where did I say we don't need estimates? I said you can do more as a PM to understand scope of problem than forwarding the number 4. In theory you should understand the task well enough (without needing to understand the actual engineering) to make the estimate yourself but I'd concede that's too high of a bar to be practical.
darkstar3333@reddit
Yeah we stopped doing that.
2 fold assuming fixed price.
1) Price for Value, not Cost 2) Compare relative work
Or do T&M which in software, is just fixed price with some scope wiggle.
Wooden-Contract-2760@reddit
We individually estimate tasks upfront, have an async team approval and then try to deliver in that time. We generally overestimate with 20-50% as we expect the unexpected.
Overall, a project with 1K hours still may end up being 1.4K if the intention is to come out burden-free and we also resolve some leftover debt that was not identified before and implement some nice-to-haves.
Why should we bring any other measurement into this game when this already catches us red handed every time we conclude a deadline months in advance?
Note that all customers expect to invoice in hiurs as well, so a proper calvulation of costs can also only be calculated in hours.
adgjl12@reddit
I know there’s a lot of different ways about it but I’ve generally done:
1 sp = literally 1 liner change such as configs
2 sp = ~1 day worth of work
3 sp = couple days worth of work but not over a week
5 sp = prob a week at least
8 sp = entire 2 week sprint at least
foldedlikeaasiansir@reddit
You should not be pointing stories above 5, if it’s above that break it down into smaller stories
adgjl12@reddit
I agree. Current company we haven’t had an 8 point story while I was here but in the past at another company I had it once or twice.
caprica71@reddit
Just never say that in front of an agile coach. Save it for after the agile coaches have left the building
Kindly_Climate4567@reddit
Always has been.
spconway@reddit
Always will be
valkon_gr@reddit
It sucks. I ignore the story points, just agree with the team, and work on the task for however many days it takes.
FutureSchool6510@reddit
Both are mostly worthless
LimeBlossom_TTV@reddit
Hopping onto this comment.
It's a perversion of agile. Complexity and value (monetary or otherwise) are the metrics we should be concerned with. Low complexity, high value targets should be done before high complexity, low value ones.
y2k4crisis@reddit
I think we often operate with a level of false precision. When we say 2 days, we mean p50 of 2 days at least 1, no more than 5.
testydonkey@reddit
We estimate by 'feelings'
zombie_girraffe@reddit
They're both shitty ways to measure, and time based estimates are rarely as accurate as you think they'll be. The purpose of using points is to prevent people from thinking that they're giving precise accurate estimates and adapting to the reality that we're not that great at estimating because anything we could give real accurate estimates about should be automated.
ExperiencedDevs-ModTeam@reddit
Rule 9: No Low Effort Posts, Excessive Venting, or Bragging.
Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.
Eligriv@reddit
For me, the real value of story points is that they show the real velocity of the team. But for that you have to estimate a certain way.
Let's say there's a task, but it's a greenfield project, everything is still clean, and it takes you 2 days. And a couple years later, because nobody has ever heard of unit tests, the code is a mess, the same kind of task takes you 5 days.
If you time-estimate individually, nobody will see anything to it, even you. But if you estimate by this random scale of complexity, you realize they are the same, but you take twice the time. You still work all the hours of the week, but your velocity has halved.
That's way story points only work if you're comparing stories and absolutely not if you estimate each stories in isolation. And the best and fastest way to estimate is by having a reference scale for constant comparisons.
Another interesting thing about story points, and the reason behind the fibonnaci scale, is that the larger the story, the less accurate you'll be at estimating. Every kind of maths based on adding the story points becomes a bad idea if you have large stories. Usually, the larger stories are discounted, and if you would split them into 1sp sized you'd have twice as much.
With time based estimation, facing a large vague story, you, as the engineer, are expected to be the one tackling the complexity, getting into the solution enough that you can be accurate. And then people are going to haggle with you to get the estimate down, not by reducing complexity, but by pressuring you to work faster.
With story points and the agreed notion that >8 has to be splitted, everyone, not only you, has to get into it, and reducing scope is a valid option because the time aspect is elsewhere.
morbidmerve@reddit
The obsession with story points is the single biggest reason why software engineers are now undervalued as hell. Now that people are realizing that just fiddling with it until it works is faster than talking about tickets and estimations, all of a sudden everyone is expected to get things done.
Erutor@reddit
Because as you become more experienced, your output value goes up. You can see this with points, but not with hours. Also, humans objectively suck at time estimates.
anatomy_of_an_eraser@reddit
This is the best response in this thread. You want your senior developers to take on more complex tasks and measure their success in how well they cope with it.
By estimating time senior most developers tend to take the most mundane tasks since they will get those done faster than any junior dev
Dependent-Guitar-473@reddit (OP)
i have always found myself super accurate with my time estimates, less so with story points...
Maybe that's why I feel less comfortable with it.
lxe@reddit
You mean 12 XXL Tshirts OE.
Crafty_Independence@reddit
21 YOE, and still PMs give me the deer-in-the-headlights look when I explain that made-up numbers aren't more helpful than timeboxes
smutje187@reddit
Time depends on the person, complexity is always the same. Also, it’s estimates, there’s no need to be accurate at all.
Dependent-Guitar-473@reddit (OP)
But complexity for a senior is not the same as for a junior.
Also I excel in things so I down estimate the story points, but the things I am bad at,, I estimate higher.
my colleague might do it the other way around
eltee27@reddit
As a tech lead if I have a 5 story point ticket I can give it to developer A and know he'll roughly be done in 3 days based on his experience. If I give it to developer B it will take him 5 days. This is useful for capacity planning.
If I have a 2 day ticket, then how can I explain to management that ven though it's a 2 day ticket it will actually take 5 days. Their response will just be then make it a 5 day ticket.
Dependent-Guitar-473@reddit (OP)
But as management, you expect (50 points sprint per sprint, for example) and suddenly your team delivered 35 instead...
That's a big change, since one developer does the story points in 2x the time..
How valuable is ur planning then?
anatomy_of_an_eraser@reddit
This is why rolling average of 3-6 sprints should be the baseline expectation….
tripsafe@reddit
Ok so you’re making the translation to days at a certain point during planning. Just skip the points and put down the days when it’s assigned to someone
Dramatic_Mulberry142@reddit
I think you mix figure out how things should be done and how to do the thing. Complexity should be how to do the thing, right? So, it should be the same for junior and senior. Sorry for my bad grammar.
6a70@reddit
your explanation suggests that you are not estimating based on the right criteria. Estimates will be more consistent and less dependent on individual skill/knowledge if you base them on 3 things:
- how complex is the type of work (e.g. replacing a string versus formulating totally new business logic)
- how much of that type of work has to get done?
- what are the risks / uncertainties to completing it
Oatz3@reddit
You're doing it wrong then. Complexity is the same no matter who works on it.
smutje187@reddit
No, complexity is always the same - a junior takes longer to achieve the same but they have to change the same parts of the code as the senior.
SquiffSquiff@reddit
'Story points' are a prison economy. Literally everyone has an exchange rate for time
Longjumping-Idea1877@reddit
The conversion wouldn't just be 1 story-point = 1 day, but 1 story-point = 1 day that is without meetings and free of interruptions, allowing us to work deeply.
Also, if we tell clients it'll be done in X days, and then it isn't because the job isn't literally just coding for 8 hours a day, they'll be mad about it.
lamchakchan@reddit
Just saw this after coming out of a capacity planning meeting. This thread is just so satisfying to read.
Dependent-Guitar-473@reddit (OP)
i didn't expect the post to blow up like this...
i am showing this to the delivery manager tomorrow :D
spconway@reddit
As long as it’s not higher than 8 points…
BoBoBearDev@reddit
Crazy enough, I have seen a team saying 8 pt is regular value for 2 weeks sprint. Their scale is whacked.
fragglet@reddit
Not really, story points have an arbitrary value and don't have any meaning outside the team where they're used. It could be 10000 points if that's what the team uses.
BoBoBearDev@reddit
Great for using 10000 pts because when you present how fast your team is, to random direct who doesn't have intimate knowledge of your scale, it looks like your team is as fast as Flash.
Dependent-Guitar-473@reddit (OP)
mmmm lets jump on a quick call and discuss why its so complex
renderDopamine@reddit
Check in with Joe Schmoe to get a better idea of the requirements. He’s on vacation this week so let’s set this item to “blocked” for now
dethnight@reddit
We just stopped estimating altogether. If it seems way too large to get done we try and break it up, but other than that we just come up with goals that we want to do for the week and make sure everyone has plenty to do.
marssaxman@reddit
I haven't had to estimate anything in years, and - as the saying goes - nothing of value was lost.
BelonginsLost@reddit
I can’t imagine how estimating completion time would work. Logging time is difficult enough, but to actually give an accurate estimate of an upcoming ticket is just impossible. Time brackets would work though, which is what story points are…
Timely_Note_1904@reddit
Story points are nonsense and I am very happy to now be in a team where we use kanban not scrum, and don't have to estimate the time each individual ticket will take. The tech lead will estimate how long each epic should take, the tickets are created and the devs pick up a new ticket whenever they complete their current one. No selecting which tickets to bring into each sprint. It works great for us.
BoBoBearDev@reddit
Yup, the fact that they told you to split 8pt story for a two week sprint, it is already time based. Because they already decided the expected velocity is 5pt.
That's be real here, if we follow the rule to split 8pt into a 3pt and 5pt and the expected team velocity is only 3pt. That 5pt doesn't fit into a sprint. So, what's the point of 8pt rule again?
microferret@reddit
I just like story points because if you are really insistent that they don’t correlate to time you can get people to not get up your arse about when every little thing will be done. It was useful when I was consulting and worked with clients who effectively had unlimited money but tried to micromanage our team. For smaller clients I think just using time was better because there is an actual time constraint on the project.
EvilDrBabyWandos@reddit
I have NEVER seen it done in practice, but the way I was taught was this:
The team points the stories based on complexity and during sprint planning, each member of the team bids their available hours to complete that story.
So a 5 pt story might get bid on by a senior to do in 4 hours, but he/she may exhaust their hours on tickets that anyone could likely complete, albeit with larger hourly estimates, and have no one available to do a higher pointed story that only that dev would reasonably be able to complete.
But I haven't ever seen that actually takes place. It's always been the group essentially averaging the team's skill to estimate how long it would take.
StoneAgainstTheSea@reddit
it all boils down to time, but when you link things to time, higher ups consider those as written-in-stone deadlines.
the best system I've seen work is designed to drive the question "should this work be broken down further?" The goal is to get your tasks defined in such a way that you can complete them in 3ish days or shorter.
then everything is either 1, 2, or 3 points:
1: we understand exactly what to do
2: we have some investigation to do but we have a solid grasp
3: this thing is unable to be broken down, we don't have a solid grasp on it, but we think we can get it done in a reasonable time (few days).
Anything else (5+) means "break it down more." Rarely does a 5 survive to make it into the sprint.
Most everything becomes 2 points. And the slop between 1s and 3s gives padding to the sprint estimate.
Dependent-Guitar-473@reddit (OP)
that's a great way to think about it
Own-Chemist2228@reddit
The theory behind the model is that the only measure of accuracy is that the team completed the sprint on time, or they did not. It's not supposed to be any more precise. The model only attempts to a binary outcome of the team performance each sprint.
A core principle of the model is accepting that it's impossible to estimate with any more granularity. A sprint is as granular as it gets. Any attempt to measure productivity with more precision has too much noise. That is supposedly the grand insight of the scrum model: Being realistic about what can realistically be measured in software project management.
But it's so unnatural to accept this limitation of the model. Product folks and managers don't want to hear about limitations, so just about every organization tries to do things the model doesn't support, like measuring individual productivity, or productivity across teams, or comparing teams...
And it isn't aligned with strong cultural and psychological traditions about humans do their jobs, which is about working so many hours across a certain number of days... so we naturally just want to force the scrum model into the traditional hourly "work" paradigm.
In the end, just about everyone does it "wrong" according the Scrum "textbook." It happens so often that there's little anecdotal or empirical proof that doing is "right" is actually any better.
But what most teams do is close enough, and doing things like using time estimation vs story points don't break the model any more than everything else that's bending the rules, so it mostly works anyway.
tl;dr: OP is not right or wrong because it all sorta wrong anyway... and close enough still works.
Dependent-Guitar-473@reddit (OP)
thank you for such a great response...
anotherleftistbot@reddit
I hate story points -- we try to break everything down to roughly \~1 day per story.
Anything much larger than a day or two and usually there is a lack of definition or detail that is needed to implement, so we get two birds stoned at the same time.
ltdanimal@reddit
I don't know why the downvotes. This is how Kanban works well.
anotherleftistbot@reddit
Yup -- we do kanban, no estimates, no sprints. We refine weekly (or more/less as needed) and make sure that everything at the top of the pipeline is in small enough chunks that they are actually understood.
We just work on the highest priority work that we can and break it down into small chunks of value and commit that value every day or so.
My teams are pretty happy, don't care much about online points. Employee engagement is very high, good people don't leave.
Infamous_Impact2898@reddit
I’ve noticed that comments questioning the effectiveness of story pointing often get downvoted, which is unfortunate. From my perspective, story points often serve more to give management a sense of control than to support developers in doing meaningful work. Over time, this can lead to burnout and frustration. It’s important that we’re able to have open, honest discussions about whether these practices are truly serving the team.
gk_instakilogram@reddit
I gave up on story pointing and started pointing everything the same size long before it was popular idea that story points are pointless. I believe that It is just one of the byproducts of the industry bloat...
Infamous_Impact2898@reddit
I agree. I would rather use that time documenting or solutioning.
-fallenCup-@reddit
There is no such thing as "accurate estimation." It's like trying to discern the position and momentum of a subatomic particle.
Tacos314@reddit
Most teams and people don't put any effort into story points, and the points are for a team not individual.
The most important thing is that the story points need to be relative to other stories which a lot of teams miss.
If the team says story A is 2 points and story C 3 points then story B must be more work than story A and less than C. Now next sprint you need to do the same, Story F is 5 points which means it is harder than store C.
A lot of teams just say a random number of how many points they think it is but so not put it into the context of the other stores so it's lately inaccurate.
Over time the team will have an average number of story points they can do and because the points are relative to previous stories they don't change, over time the team may end up getting higher and higher average as they get to know the domain and tech.
Smooth_Syllabub8868@reddit
Most people here really do their best to show that they have years of experience and have barely learned anything
Dependent-Guitar-473@reddit (OP)
Thanks man <3
notmsndotcom@reddit
It is a time estimation and anyone who says otherwise is lying to themselves.
scout1520@reddit
No, it's time multiplied by ego!
Infamous_Ruin6848@reddit
Uhm. Both?
MonotoneTanner@reddit
Tbh you aren’t going to get a convincing (or unbiased) answer here
Try r/agile or r/scrum or even r/projectmanagement
Dependent-Guitar-473@reddit (OP)
honestly i am checking if i am the only developer feeling the same way... not trying to go further into the KPI itself..
MonotoneTanner@reddit
Well if you’re looking for convincing I figure it better hearing the perspective of the people asking for it rather than the devs estimating
ltdanimal@reddit
daredeviloper@reddit
1 story point = 1 day for me
besseddrest@reddit
if a "3" buys me 3-5 days of work and anything more needs to be broken down then sign me up baby
Oatz3@reddit
Story points are supposed to be a measure of complexity and common across your team.
Time estimates are for when work is actually assigned, i.e. a junior dev might take a week for something a senior could do in a day.
ImSoCul@reddit
that's really not how it works in most teams though. Most teams have devs with an area of ownership and they scope tasks accordingly.
Also junior dev gets more done than I do, I get distracted by half dozen meetings and context switches per day
Southern_Orange3744@reddit
While true , a lot of engineers try to use it as an excuse not to give estimates anyways .
Totally fine with both , but some of us have dates to hit
carnivoreobjectivist@reddit
It’s all bs to me. Story points, sprints, all of it.
Just tell us what needs to be done and we will do it.
failsafe-author@reddit
I’ve worked at a company where story points were used properly and not just “estimates with extra steps”. They worked really well in that environment. They gave us a good sense of velocity, and we did actual time estimates for each sprint.
Sadly, it seems to be a difficulty concept to get everyone on board with and implement well.
ButchDeanCA@reddit
This agile thing is not to make our lives easier, it’s for management folks to have stats on ICs. It’s all a complete load of bs, so I don’t care if it’s “story points” or “time estimation”, I really don’t.
QuitTypical3210@reddit
It’s done when it’s done
itst@reddit
Info: accuracy is the difference between say three hours and six hours, or 2 days and 2,2 days?
SpriteyRedux@reddit
Estimates are ultimately pointless, part of the job is figuring out the best way to solve a problem which can take an indeterminate amount of time. A better solution will be delivered if I spend more time on it. The best I can really do is that sometimes there are "little tickets" that take anywhere from a few minutes to a couple hours, and then there are "big tickets" that are better measured in days
GuaranteedGuardian_Y@reddit
Besides breaking rule 9 of the subreddit, I wonder where you have worked 12 years and you somehow didn't know that story points are still KPI and converted into working hours and are ultimately plugged into spending/ROI stats?
liminite@reddit
Story points as a kpi is insane. Wtf are you actually building???
Dependent-Guitar-473@reddit (OP)
My question is more why not the opposite... why not time converted into story points?
GoodTimesOnlines@reddit
Isn’t it redundant at that point though? They are both basically measuring the same thing at a high level. The choice of which one becomes kinda arbitrary
Dependent-Guitar-473@reddit (OP)
But don't you feel how people throw random number when the ticket is quite large (above 8 points)
while they can provide a much more realistic time frame to finish it)
GuaranteedGuardian_Y@reddit
Honestly I don't see any difference. There is no way the team isn't aware of the implied hours when they're estimating story points, tshirt sizes, dog poos and what not.
hitanthrope@reddit
If you read about the origins of story points in "extreme programming" (an early set of agile ideas devised by a bunch of very smart guys but none of whom were good at branding in ways appealing to corporates), there is a lot of sense to what they were saying and what they were trying to do. There are things to learn there.
In basically all practical incarnations I have seen, it's useless.
Agile forecasting methods have always been promoted with this inbuilt safety net of an overriding idea of delivering a constant stream of quality software that is improving at the fast possible pace. Story pointing was supposed to be a mechanism to try to give a better than random prediction of when something might be available in production. It depended on a backlog that was already pretty statically prioritised which meant no peering too far into the future.
This doesn't fly in most places and there are reasons why it might not, but predicting software delivery in sizeable distance in the future really does seem to have remained an unsolved problem. Maybe the LLMs know...
wrex1816@reddit
You know you can just pick whatever works for your project right? Like it won't kill you if you pick vanilla ice cream and I pick chocolate. Why do people seek so much freaking validation on the internet that OP literally cannot do the thing which he prefers unless the internet collectively all decides to do the same.
Infamous_Impact2898@reddit
Honestly, the whole thing feels like a scam. I know what I need to work on, and I don’t need someone hovering over me to tell me when to get things done.
Smooth_Syllabub8868@reddit
Yeah that mindset works very well in a company with thousands of people 👍 just fuck off and let random person work he surely understands what must be done lmfao
loptr@reddit
I've found it useful in teams with mixed skill levels/when people lack experience to estimate (semi)confidently. But it's mostly to get a discussion going in case there's big discrepancies in the scores, and it's easier to get consistency with points instead of individual's time estimate.
But I fully agree with you, and I rarely decouple time and points. Nowadays I tend to see the time estimation as a later step where you take other planned work into account as well. (I.e. once we get to the time estimate it's actual working time, other tasks included, not just an estimate for that single issue in isolation.)
But imo it's inevitable to think about the time in parallel
Eric848448@reddit
Whaaaa?? No!!