Conversely how do you know how large a story is if you don't know how long it will take? Is it really a large story if it only takes an hour? What are the quantifiers of a story's size?
Just things to think about. I personally don't think any form of estimating, whether size or time, is productive to the developer and the end goal of producing value to the customer/business.
The size is about discussion. It could be a large story if it takes an hour and you thought it would take weeks. It could be that you didn't know how long it would take. It could be that the expectation was a junior dev would be working on it.
Everyone on the team is then supposed to hear why dev one and dev 2 are in disagreement. At the end of the day it gives an idea of what you'll complete in a sprint.
The challenge has always been that these story estimates are supported to be an estimate, quick, and revisited. Are you adding some estimates to stories in the next sprint, throw in some numbers and update when sprint planning. But management gets their expectations that these are deadlines instead.
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.
Conversely how do you know how large a story is if you don't know how long it will take? Is it really a large story if it only takes an hour? What are the quantifiers of a story's size?
Just things to think about. I personally don't think any form of estimating, whether size or time, is productive to the developer and the end goal of producing value to the customer/business.
The size is about discussion. It could be a large story if it takes an hour and you thought it would take weeks. It could be that you didn't know how long it would take. It could be that the expectation was a junior dev would be working on it.
Everyone on the team is then supposed to hear why dev one and dev 2 are in disagreement. At the end of the day it gives an idea of what you'll complete in a sprint.
The challenge has always been that these story estimates are supported to be an estimate, quick, and revisited. Are you adding some estimates to stories in the next sprint, throw in some numbers and update when sprint planning. But management gets their expectations that these are deadlines instead.
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.