Story points are very useful to predict how much complexity can a team handle and for that you apply a rule of thumb, in my workplace it goes about this:
1 point - almost done, there is no unknown complexity or significant amount of grind to do.
2 points - A story with very little complexity.
3 points - A story with little complexity.
5 points - A story that has few uncertainity but still some investigation has to be done.
8 points - A story that has a lot of uncertainity.
13 points - Break that story because it has way too much complexity.
Now, the part about the discussions, that tells me two things: Your team needs to work way more about sharing domain knowledge and that you do not have someone in the role of Scrum master to say "enough pointless discussion, we go with X".
And the final part about story points is that it allows upper management to have some sort of quick feedback about the team performance and when something will be done because a team that cannot give feedback or realistic estimations is a useless one for management.
This is pretty similar to how my team(s) has/have bid, though we haven't written it out as such. And we almost always split a story that requires investigation before implementation into 2 stories. And if a story requires multiple people, that'll add 1.5x to 2x the points, depending on how involved they must be.
That said, I think if you didn't need to put stories "on sprint" based on a nebulous velocity number, it would be easier to just use words to describe a story's size or complexity: simple todo/reminder, trivial, small, medium, large, jumbo (aka SYNS: see you next sprint), all hands, or split
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.
dev.to/anortef/explaining-scrum-st...
Story points are very useful to predict how much complexity can a team handle and for that you apply a rule of thumb, in my workplace it goes about this:
1 point - almost done, there is no unknown complexity or significant amount of grind to do.
2 points - A story with very little complexity.
3 points - A story with little complexity.
5 points - A story that has few uncertainity but still some investigation has to be done.
8 points - A story that has a lot of uncertainity.
13 points - Break that story because it has way too much complexity.
Now, the part about the discussions, that tells me two things: Your team needs to work way more about sharing domain knowledge and that you do not have someone in the role of Scrum master to say "enough pointless discussion, we go with X".
And the final part about story points is that it allows upper management to have some sort of quick feedback about the team performance and when something will be done because a team that cannot give feedback or realistic estimations is a useless one for management.
This is pretty similar to how my team(s) has/have bid, though we haven't written it out as such. And we almost always split a story that requires investigation before implementation into 2 stories. And if a story requires multiple people, that'll add 1.5x to 2x the points, depending on how involved they must be.
That said, I think if you didn't need to put stories "on sprint" based on a nebulous velocity number, it would be easier to just use words to describe a story's size or complexity: simple todo/reminder, trivial, small, medium, large, jumbo (aka SYNS: see you next sprint), all hands, or split