Scope - points should not be used for "management" so some dude up high feels important or comparing teams. Points are for developers to say to management "this is amount of stuff we can deliver in next 2 weeks - maybe - if you add more it ain't gonna be done, STOP adding things or remove something if you feel something else is more important". The "maybe" part is that it only works based on the same team that has at least 4-5 sprints working together. "We did 120 (+- 20/30pts) points so we can say let's try to do 120 this sprint again". Yes in the end you can make translation to time, but only after you did something. An example 'adding a popup with 5 properties' - well we did last sprint 2 stories where popups with 10 properties were 5 pointers, well I suppose it is going to be a 5 pointer - sounds like we are not making all up ;) there is a lot made up. To sum up: it makes sense only for things to be done in next 2 weeks, cannot estimate something that will be done in 6months, it makes sense if team is the same for at least 4-5 sprints, scrum should be used to tell business not to come up with new ideas every day to devs but they should make up their minds and plan for 2 weeks any JIRA ticket that has to wait 6 months should be in their personal notes and not in JIRA spamming backlog.

You just have to feel it man 🌼

The alternative would be to estimate work based solely on hours which leads to a lot of fighting to justify hours based on complexity because people associate hours closely to dollar costs.....other alternative is to no estimate at all and that leads you to indefinite work on a story that likely expands in scope and drags on across multiple sprints....at some point you need to have a cutoff to decide whether to ship the feature.....also, estimating effort, regardless how its done is like signing an agreement across product, business, dev, testing, etc on what the scope will be defined as and help you determine whether small changes in requirements should be considered another story or within the estimated scope of existing story

These are not "JIRA story points" though, these are just "story points", as they are independent of the issue tracking tool used, but are rather introduced by the specific agile process used, e.g. Scrum.

Points are relative and a team learns how many points each type of task will take. Eventually, a team knows it can acheive ~N points in a sprint. You may object: "if a team of 5 can achieve 50 points in 2 weeks then a point is 1 developer's day". Reasons we don't use time: - estimates are better in agregate - estimates in time tend to miss things like: time to deploy and test, time to help another dev, and time to review others work - points let us see measure improvements: if you speed up how you test and deploy then the whole team can do more

I’ve managed and had being managed in A LOT of projects. It works if days are flexible in my experience. 8 a sprint (max 2 weeks), 5 is 5-7 working days, 3 would be 3 to 5 days, 2: 1 or 2 days. 1 is within the day (hours). But this also brings the problem that generally works expands to occupy all available time. But you’re also required to raise your hand if the complexity changed. It’s a very industrial way to build software, it’s slow but works. Also: use planning poker, without this estimation are even more useless

Product owner said everyone had to do 8 pts a sprint. The thing i most hated was the "team" would score it a 5, but thats the owner/sme/expert doing it. Then that left over story in sprint planning gets assigned to the last person thats open but knows ZERO about it... like ok I'll learn javascript overnight and then how telephony works and then read your minds. Each person gives their story point in pointing poker... if i gave it a 13 it should be a 13 when i pick it up, not a 5. We werent allowed to change the points on a story. So not only do i not get 8 pts for the week, but then my record shows I couldnt complete a 5.

110% accurate. However, there is some value provided. When discussing work items, the topic of effort always comes up....in this case no matter what you say (small, medium, large....easy, medium, difficult....or 1, 2, 3, 5 8)....its always going to sound very subjective so you have to provide some context for people to understand....the context will come when comparing the effort to recent stories of similar story points or recent combinations of stories that add up to estimated story points on the story youre discussing......its not about being arbitrary, its about being relative and the only way to find a lot of value is to be consistent...if you have a team that works together for a long time they can easily estimate effort and be consistent by basing it off efforts of similar stories in the past. For example, I typically estimate stories that are config-only changes as a 1...maybe a small UI/client side change a 2....a small fix or feature impacting multiple code tiers a 3-5....and something with a few dependencies or high level of regression testing an 8....generally 1 person can get done 5-10pts of work within a 2 week sprint

All estimation is crap, just count tickets. #NoEstimates. Also story points are completely unrelated to Jira lol, jira has an estimates field there’s no “story points” field.

As a developer, I despise project managers and JIRA. It wastes time and creates more problems than it solves.

It's mgmt vodoo so they have their asses covered by paper trail. Every project I've been on (>20yrs exp) if you just slapped 5 SP on every task the result would be exactly the same as with us poring over this shit for hour-long meetings & pretending we can predict everything

Also I don’t understand what you mean by it needs to be the same everywhere, that’s just objectively false. Velocity is meant to be an internal number that lets the development team know how they’re going and identity when they are performing poorly, it’s not meant to be used to compare teams.

Story points are time estimates no matter how desperately people want to believe otherwise

The level of effort a task will take can never be objectively measured. Time is also not an appropriate measure. Does a task take faster for one developer because they are more experienced or because they don't think through the task and just slap it together? If it cannot be measured then how do you know you are improving? "Relative complexity" seems to be the best we've come up with. I'm ok with that and have moved on.

To be honest, as much as I like the general communication and breaking tasks down into bite-sized components and that side of things, I absolutely loathe the other half of agile, with story points and all these weirdly used normal words in wrong places, like scrum, sprint, kanban, story, and all that complete and utter garbage, and I have never met anyone who thought they were good. I wish they would call things projects, tasks, cycles, time estimates and so on.