The thing is that story points are a tool for helping to make exactly the sorts of determinations that you propose. They get abused to high-heaven, but tell me a single project management thing that doesn't.
The main thing about agile is that you're supposed to do the retrospective and in the retrospective you're supposed to evaluate your process and come up with a plan for how to improve it. Which means that we need to understand why we do the things that we do so we can reason on first principles.
So first of, I feel like no one actually covers why the hell story points recommend Fibonacci Sequence to begin with. Understanding this has some implications. The premise is that human beings are pretty bad at estimating fixed points, but pretty good at estimating relations. And - because it is everywhere in nature - there is something about human physiology that makes us particularly good at estimating relations on the golden ratio of 1.618. Which is the ratio that Fibonacci happens to have between its numbers.
Yes, this means that Jira's description of the concept is full of shit - who would have guessed? It also means that starting at 1 is dumb because that is the part of Fibonacci Sequence that doesn't follow that ratio. Have a small task be an 8 or a 13 and you're at least sticking with the intent of the technique and can evaluate its effectiveness on fair grounds.
Also note that looking at first principles, velocity makes no sense if you don't have a good sprint cadence. If that is the case and sprints are all over the place and no one has a good feel for what unit of work a sprint is, then sure, story points are only going to be useful in terms of being a framework by which you can talk about complexity. That in itself can be useful, but isn't always, it's absolutely something to be considered in your retrospectives. Also, for many projects I run more Kanban style - it's not terribly useful there at all.
The bit about comparing teams - it's a fair point, but I don't know how often that realistically happens. Velocity is meant to be used within the project planning process as administered by the team. No one who has oversight over multiple teams needs to see it. I have no clue why they would want to. But even if they did - let's say they wanted to have a dashboard of whether teams are slowing down or not. Understanding the underlying theory lets us propose an alternative. Don't show the higher ups your velocity, show them what they actually want to see - show them the sprint-over-sprint percentage of change. Now they're comparing apples to apples and problem solved.
As for fixing deadline, etc. That's all well and good. It's a fine way to view structure definition of done. But so long as you work in sprints, you still are going to need a way to know what work you should schedule in your sprint planning. This still means making estimates, viewing dependencies, and priorities, and organizing things properly. Story points are a technique for one part of that. Throwing them out and replacing them with nothing might not harm you but certainly doesn't leave you any better off.
Also, don't just start friggin work. People should plan their projects. "Oh we're so bad at estimating and nothing ever gets done on time". Well how much time did you spend out planning your project? Drawing out dependencies? Did you revisit your assumptions often and address issues? Hardly anyone ever does that part.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The thing is that story points are a tool for helping to make exactly the sorts of determinations that you propose. They get abused to high-heaven, but tell me a single project management thing that doesn't.
The main thing about agile is that you're supposed to do the retrospective and in the retrospective you're supposed to evaluate your process and come up with a plan for how to improve it. Which means that we need to understand why we do the things that we do so we can reason on first principles.
So first of, I feel like no one actually covers why the hell story points recommend Fibonacci Sequence to begin with. Understanding this has some implications. The premise is that human beings are pretty bad at estimating fixed points, but pretty good at estimating relations. And - because it is everywhere in nature - there is something about human physiology that makes us particularly good at estimating relations on the golden ratio of 1.618. Which is the ratio that Fibonacci happens to have between its numbers.
Yes, this means that Jira's description of the concept is full of shit - who would have guessed? It also means that starting at 1 is dumb because that is the part of Fibonacci Sequence that doesn't follow that ratio. Have a small task be an 8 or a 13 and you're at least sticking with the intent of the technique and can evaluate its effectiveness on fair grounds.
Also note that looking at first principles, velocity makes no sense if you don't have a good sprint cadence. If that is the case and sprints are all over the place and no one has a good feel for what unit of work a sprint is, then sure, story points are only going to be useful in terms of being a framework by which you can talk about complexity. That in itself can be useful, but isn't always, it's absolutely something to be considered in your retrospectives. Also, for many projects I run more Kanban style - it's not terribly useful there at all.
The bit about comparing teams - it's a fair point, but I don't know how often that realistically happens. Velocity is meant to be used within the project planning process as administered by the team. No one who has oversight over multiple teams needs to see it. I have no clue why they would want to. But even if they did - let's say they wanted to have a dashboard of whether teams are slowing down or not. Understanding the underlying theory lets us propose an alternative. Don't show the higher ups your velocity, show them what they actually want to see - show them the sprint-over-sprint percentage of change. Now they're comparing apples to apples and problem solved.
As for fixing deadline, etc. That's all well and good. It's a fine way to view structure definition of done. But so long as you work in sprints, you still are going to need a way to know what work you should schedule in your sprint planning. This still means making estimates, viewing dependencies, and priorities, and organizing things properly. Story points are a technique for one part of that. Throwing them out and replacing them with nothing might not harm you but certainly doesn't leave you any better off.
Also, don't just start friggin work. People should plan their projects. "Oh we're so bad at estimating and nothing ever gets done on time". Well how much time did you spend out planning your project? Drawing out dependencies? Did you revisit your assumptions often and address issues? Hardly anyone ever does that part.