I would like to share some of my thoughts about story point estimation.
I am working as a product owner with two scrum teams. One team is estimating the product backlog in story points, the other is using days. When we do sprint planning (two week sprints), the teams split the user stories into tasks and estimates them in hours.
Comparing both teams I experience that the story point estimation of the backlog is much easier for the team. It took some while to get used to it but now estimation is very straight forward with good enough accuracy for release planning. It’s easier because we estimate how “big” a user story is, not how long it will take to implement it.
On a product owner course with Mike Cohn he had a very good way to describe the difference between days and story points:
Think about two different persons, one a very sporty guy and the other a normal guy. Now you ask these two persons how long it will take them to run to the building you can see not so far away. The sporty guy answers 5 minutes, the other answers 10 minutes. It will be very hard for them to agree on an estimation. If you ask them instead how far away the building is, you probably get two answers that are quite close together e.g. 1000m and 1200m. They both will be able to agree.
This is exact the same situation for developers if you ask them how long a user story will take to be implemented. The team will come up with different estimates based on their different experience levels. If you instead start estimating how “big” a user story is it will be much easier for the whole team to estimate. There will be much less discussion and the whole process will be much faster. After some estimate sessions everyone in the team will get a good felling for what “big” means.