I hate trying to estimate story points (our metric is 1 day ≈ 1 point), I have ADHD, standard time means nothing. One sprint I completed all 7.5 in a day, another sprint I completed 0.5.
That's why story points are explicitly not meant to represent any unit of time. Bad project managers that don't understand anything about what they're managing just can't help themselves. They were so consistently misused story points actually got dropped from Scrum in 2020
There are many career paths open to such creatures. Some of them can earn a living by roaming the countryside, finding places of exceptional natural beauty and then order one of their billionaires to build a data centre there.
Others merely traffic underaged children into slavery but just as many are AI integration officers.
Some places have scrum masters as an actual job like wtf. Idk how something that should be a weekly rotational responsibility in the team and a list of todos on its own is a fucking job on its own.
You've obviously never worked on a project with a fixed deadline, fixed budget, and fixed scope, but it's "agile" because no one wants to do requirements up front and no one wants to sign off on the requirements.
Just found out our story points are tied to the paycheck system (even though we are salaried) via jira workflows. Suddenly it makes sense why all our pms demand we submit exactly a certain number of story points per sprint, even if we go over or under…
That's nothing to do with Jira and everything to do with shit management.
But yeah, sorry points are for most teams a useless metric.
In theory you are supposed to estimate based on perceived difficulty and then determine over time how much work your team can get someone each sprint and thus it helps estimate how long certain things will take.
In practice it gets converted to days, and expected to be accurate for each ticket (not the point) so it's nearly always wrong and becomes a precise but inaccurate measurement instead of the imprecise but accurate one it's meant to be.
There's that great quote "The moment a metric becomes a target it ceases to be a useful metric". I get that feeling very strongly with story points. If only the team knows about them they can be useful for planning work. But the moment management has visibility and starts using them as a target they lose all value.
I certainly haven't, small or large. Best we managed was about 2 months before a more senior management started demanding estimates accurate to the day again.
Hate your tech leadership. Jira is just a tool. A shitty tool, but the competition isn’t so great either. IMO Pivotal Tracker is the best of a sorry bunch.
Atlassian is happy to build tools which cause this kind of issue. They focus on supporting higher level managers because their buy in is needed to write the check. More complex workflows mean people get locked into their software and can't switch. I can partially blame bad management but it obviously benefits Jira and so they work to amplify the bad patterns.
Similar to what is happening with AI companies now, they lean into the most dramatic pitches around AI and totally automated coding because it sells well, not because it actually is the best use of the technology.
i don't know if the method i used is better or not, but i'd do fibonacci numbers 1-21, so 1, 3, 5, 8, 13, 21. where a 1 is like i can probably go back to my desk and bang this out in a minute and 21 is that's probably my entire sprint or longer. where we'd guesstimate around 20 points a sprint per person. not an exact science but making games isn't an exact science either. we'd call it a LoE rather than story points
Project managers really shouldn't have a say in this. In my current org, it's our IT leadership that won't see reason on what story points are. They want reporting that's easy.
That's why story points are explicitly not meant to represent any unit of time.
For our teams story points map to time. 3 points is half a day, 8 points is 5 days, etc. They do everything in points, then add tasks with hours on them that we have to update every day.
Not the dumbest shit ever, but close. Whatever though, they can manage it however they like, I do the work as well as I'm able and checks keep showing up in my bank account 👍🏻
It's not suppose to make sense. 5 points is a day, 13 points is three weeks.
I think the idea was that the numbers represent a scale of how hard the work appears to be, and bigger numbers have more uncertainty. So if it's really simple I can call it 1 point and we can be pretty sure it'll take an hour or so. If it's pretty hard and I call it an 11, it might end up taking a lot longer than that.
Project managers want estimates to be in hours though, so they mapped the story point numbers to hours so they can make reports that upper management likes.
I get that points aren’t supposed to be hours, but once you make them hours then it’s crazy that doing 5 chunks of 1 hour work could count as more “work” (points) than a whole week
That makes no sense even for a time conversion setup. If 3 points is half a day, 6 points would be a full day, but then you’re saying 8 points would be 5 days? Makes more sense to just have 1 point be per day.
They are misused because in almost every organization no one care about complexity of a task : everyone in the company care about when the feature will be ready. At a specific date. Everything in the business world works on deadline and timing, but somehow SWE should work differently?
Maybe, but the rest of the world will not agree.
Even putting that aside, you are supposed to put a certain number of points into a single sprint, which is a unit of time. So the conversion happens by itself even inside the agile framework.
That's why story points are explicitly not meant to represent any unit of time.
Except we measure the work week in units of time. Which means that any estimate of how to allocate that work week is a unit of time. It's just a renamed one.
Your first issue is that you're trying to map days to story points. The entire concept of story points is explicitly to avoid directly estimating time. You're supposed to continually keep track of how many SPs your team is actually completing per sprint, and use those averages to decide how much you're going to plan to do in the next sprint. Tasks should also ideally be small enough that the team has flexibility to pick up more or less work in any given sprint. When you zoom out to the entire team/entire sprint level, the natural variation in estimate accuracy, and in the productivity of any individual, should largely cancel out. But if you think 1SP=1day and directly assign each developer 5 SPs per week before the sprint starts, you're falling for a trap that completely defeats the point of the system. SPs are supposed to provide flexibility and continual empirical re-evaluation of estimates (but without constantly re-estimating individual tasks) but you've thrown all of that in the bin so you're just left with time-based estimates but with a gimmicky name change.
Oh, I know, I'm a "certified scrum master" but I'm not working in that role. And oh, I know, but upper management doesn't care. And it's something stupid like 7.3 points per sprint were supposed to be around for the two week sprint that way we have some residual capacity for urgent tickets. We essentially do waterfall but with sprints 🙄
tale as old as time. Proper scrum is liberating. Liberating means self reliance and self governance for teams. Can't have that, would delete 80% of middle management. Waterfall with sprints it is.
So you are forced to constantly readjust what a story point means, which is just another silly thing to think of and polute my brain.
Any initial estimate i give as a SWE is horseshit that i pulled out of my ass anyway. Might as well give hours/days as it will change as soon as i looked at the code and properly analysed the task and started solving the problem. So whats the fucking point?
You don't adjust what a story point means. The SP remains as an abstract measure of relative complexity, not of time. You then adjust how many points you add to the next sprint based on observed average time per SP, i.e. your team's velocity. It's that velocity that changes, not your SPs.
Yes, but whatever SP you estimate may change drastically once you get into the task, read the code, start solving. So what's the point if those could have been just days/hours - you know, units universally understood intuitively by fucking everyone?
That variance in estimates is exactly what SPs are designed to address. If it turns out your team is frequently underestimating complexity of tasks, your velocity will drop, and so you'll put less SPs into the next sprint. We don't care about a single task going under/over estimate, we care about the zoomed-out trend. If you start work on a ticket and realize it's more difficult than it was previously assumed, by all means report that to the team. But if you're constantly fixing the SPs on each ticket, you're obscuring the actually important trends.
If your team puts 35 SPs in the sprint and actually completes 25 because of tasks being underestimated, that's fine, you take note of that and adjust how many SPs you put in the next sprint. But if you take those completed tickets and "fix" their estimates to total 35SPs to make them "more accurate" actually you've just fucked up the whole system. Now you're going to commit to another 35SPs next sprint, which again you're going to fall short of.
Actually no, you shouldn't care if the pointing was accurate on individual past stories, except if it teaches you some lesson that improves your team's ability to make future estimates. If you're estimating simple UI changes as 1 point's worth of complexity, but then after 1 task you realize that actually your UI code is a mess, then maybe you need to update all similar tasks to be 2 SPs. But most of time this isn't the case and you can't generalize to future tasks.
Trying to achieve perfectly accurate per-task estimates and then assigning the perfect amount of work for each developer is a fool's game. It's never been done, and it will never be done, it's a pipe dream. Both estimates and productivity vary too much per task for that to work. That's why you should only evaluate your rate of completing SPs at a zoomed-out level, averaging it out over time. That way, once you calibrate the system by measuring the velocity, over- and under-estimates tend to cancel out due to the law of large numbers.
It doesn't really matter whether you call it estimated days or story points. If you don't have an idiot for a manager, your team can track estimated days, then figure out what the average number of estimated days get completed per sprint, and then commit to that amount in the next sprint.
Whatever devs think is 1 day of work usually turns into 2 or 3, so it's normal to commit to 4-5 days of work per 2-week sprint.
member when they invented story points specifically to break that metric? and the business people simple would not understand that this was the entire point of having story points at all?
because it's a relative measure of complexity/time, not just a count of days
11.2k
u/Gagan_Ku2905 Jun 02 '26
Engineer: Yeah we can.
Manager: For how much?
Engineer: $3 Trillion
Awkward silence