I agree discussion is important. The heart of any developer team is communication, and more specifically effective communication.
The problem with that estimate of "takes an hour and you thought it would take weeks" is it doesn't effectively communicate nor help plan what you will get done in a sprint to an extent. Obviously a person could say "i'll get this one story done in this two week sprint" where the story is adding a dropdown to a form. They end up getting it done in a day and have nearly two weeks of work left open. Of course they can pull things in to stay productive, but now it is unplanned territory.
Ultimately I think there are too many variables to effectively estimate. Sleep, home life, complexity of work, pto, who is working on it, who needs to talk to who, weather (too hot/too cold), noise, health, etc. All of these can have a significant effect on how long a task takes to finish and can change at any time. Some of them change day to day. To use an analogy of throwing a ball, does it help someone catch the ball if you tell them "the ball will be somewhere between me dropping it and throwing it as hard as I can"? I am of the opinion that it does not.
I think that a lot of misconception comes from, non-technical people will have absolutely no basis for how difficult something will be. Granted story points are intended to be used by the development team.
As for all those realities setting in, it is supposed to prompt discussions on what is at risk in the sprint.
As for taking one story into a sprint, we can reach for kanban style in that case.
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.
I agree discussion is important. The heart of any developer team is communication, and more specifically effective communication.
The problem with that estimate of "takes an hour and you thought it would take weeks" is it doesn't effectively communicate nor help plan what you will get done in a sprint to an extent. Obviously a person could say "i'll get this one story done in this two week sprint" where the story is adding a dropdown to a form. They end up getting it done in a day and have nearly two weeks of work left open. Of course they can pull things in to stay productive, but now it is unplanned territory.
Ultimately I think there are too many variables to effectively estimate. Sleep, home life, complexity of work, pto, who is working on it, who needs to talk to who, weather (too hot/too cold), noise, health, etc. All of these can have a significant effect on how long a task takes to finish and can change at any time. Some of them change day to day. To use an analogy of throwing a ball, does it help someone catch the ball if you tell them "the ball will be somewhere between me dropping it and throwing it as hard as I can"? I am of the opinion that it does not.
I think that a lot of misconception comes from, non-technical people will have absolutely no basis for how difficult something will be. Granted story points are intended to be used by the development team.
As for all those realities setting in, it is supposed to prompt discussions on what is at risk in the sprint.
As for taking one story into a sprint, we can reach for kanban style in that case.