1. In general I found that for rough estimate you can just multiply by 2 for a very experienced developer, by e (2.7...) for a developer with less domain expertise and by pi (~3) for an unexperienced developer.
2. If you need more precise estimates, then:
2a. do discuss every feature/story in depth, since it provides various opinions and help to find unexpected problems
2b. don't use points. Days are more reliable unit
2c. break down every feature to stories and every story to tasks. More granular items -> better estimates
That is it.
Couldn't agree more. I learned to multiply whatever I have in mind by 2.5 - this gives me estimates that are actually quite close to reality.
Story points is a different topic though. In one company I saw it working fine, but we tended to keep number of points per story low. If too many points were assigned, BAs were asked to rework the story and split it into smaller ones. In my current job we tend to associate story points with person-days (so for instance 5 story points is ~5 days of work) and I think it works well for us.
> we know how many points we can estimate in a sprint
Well, you learn your delivery capacity after first couple of sprints. After 3-4 sprints I usually expect my team to deliver roughly similar number of story points each sprint. If we don't it calls for an investigation. Sometimes there's a good reason (e.g. people on sick leaves or previously unforeseen problems) and we expect situation to stabilize over the next 1-2 sprints. Other times we need to take some actions.
Also you may try assigning particular stories to particular people during planning meetings. Ideally they themselves should commit to deliver a particular number of stories. It may happen that some shuffling and reassigning will occur during sprint, but that's ok. The purpose of this exercise is to help you estimating how many story points you can deliver, the assignments are not that important.
BTW it would be easier to answer if you could elaborate what problems exactly are you facing.
> usually results in a shrug
This is a problem. I'd suggest to repeat voting after having a conversation. And like I've said before - developers should try to commit themselves to deliver a chunk of work. It's hard to commit to random estimate that does not take your point of view into account.
You could also try replacing story points with t-shirt sizes. If you cannot agree whether the story is 2 or 4 points, maybe it would be easier to agree between M or L. I am not a big fan of this method but I've seen teams for whom it worked better than story points.
For 2 vs 4, I've heard it recommended to use Fibonacci numbers to help avoid the confusion. 1, 2, 3, 5, 8... The argument being that with small points, usually things are easier to compare. As you get larger points, it is more apparent if something is a 5 vs 8. So a 2 vs 3? Meh, round up and move on to the next story. 2 vs 5? Orly? Let's talk on why these are (un)like similarly sized stories.
However! Hemming and hawing over close point stories irks me, eps. when the story could have been half way done by the time the team negotiates the points. If points are slowing your team down or not aiding discussions about sizing, then your team should change how it operates; the process should be helping. We've changed ours method to 1, 2, or 3 (definitions what those mean to our team in another comment I left here). Pointing for us typically takes under 20 seconds. Everyone agrees? Good; done. Disagreements? Either round up or discuss it and move on.
The end goal is to help the team create as small of stories that are still delivering value to the org. If any of your agile/scrum ceremonies are not adding value, the retro is a good place to discuss how to improve (or remove) processes so that the team can effectively and visibly make progress.
I've worked on teams that were great at estimating. They used days. 1, 2, 3, 5, or 10 days. Smaller than a day - coalesce. Larger that 10 days - break it down.
The difference was with points there did not seem to be any real impetus to improve estimation. It was too make believe. Also, if you asked a team mate what a point was, they might say an hour, a day, whatever. Sometimes this would cause unnecessary drama.
With estimates in days, it was concrete, and concrete steps were taken as the team was forming to improve estimates. Also, minimum time of 1 day helped avoid the small stuff taking on too much importance.
And all that precise talk was about something that can't be precisly estimated
What they avoid is time pressure. I think a lot developers internally and externally feel pressured to reduce the time estimate.
Points allow you to be more honest.
For estimation of work we can pull in, it is about letting the org know when they might expect things. We pull in our average number of points minus a buffer, and then will pull extra things in as needed. But by committing to less, we are more likely to deliver what we said we would. That keeps the org happy.
For long term planning, I think points fall apart. The best I know to do is list out all the things that likely need to happen, break them up into stories/tasks, and make an educated guess and add padding for the unexpected and padding for optimism. And remember Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.