Estimates are among the most controversial topics in Agile world; Are they evil? Why shall we even bother to do that? What’s the point of it? etc.
Especially the developers question it so much because they are the ones who should create those numbers. To be perfectly honest, scrum world has been trying very hard to make estimates fashionable again by introducing cool poker cards and by shaping it like a game rather than a serious commitment.
Here is the problem; at some point the product owner or the business side forgets the real purpose of those estimates, attempts to treat them as a promise and even creates solid project plans based on those numbers. Hold on, it wasn’t meant to be like that! Somebody needs to warn these bad boys and girls that it is clearly a breach of trust, if not an agile crime. Developers were promised, before almost every estimation meeting, that the story points they will estimate is only useful for the team and nobody else. They were even told to guesstimate the complexity and not focus on how many days it would take them to complete that story.
Most often than not, some time midway through the project, product owner gets pressurised by the business to give them a deadline. Not knowing what else to use as a metric, the product owner sums up all story points yet to be delivered and looks at the past velocity of team to decide on a deadline. Once the product owner communicates this date back to the team, and justifies the decision by presenting that data, the team mostly nods knowing that they are not best suited for these discussions. But at the same time, they feel betrayed quite a lot of times and secretly promise not to do any estimation anymore. Obviously, they can only resist until the next estimation meeting since they are eventually told this is how the things should work!
I don’t think the estimates are completely wrong or useless for that matter. As long as you stick to the basic principles; story points could be a nice way of guesstimating how complex that story is compared to another baseline story. In other words, if the baseline story is as complex as 1 jelly bean (or martian coin), how complex the other story would be? I would even insist on each team creating their own unique currency system instead of “story points”, so that the business owners should never be encouraged to compare one team’s velocity or delivery capability with another team based on those arbitrary numbers. After all, you cannot really compare jelly beans to martian coins, can you?
During such estimation meetings, the team also have a chance to unify their understanding and possibly identify the unknowns so that the business analyst or the product owner will have enough time to find out those answers before the team starts implementing it. Also, if the story is too big (i.e. more than 5 jelly beans), it will be the ideal time to divide them into smaller chunks.