Developers are already using Agile points in their head
When I started to really use Agile methodologies two years ago, one thing I struggled to understand, like many developers, is the concept of Agile points. When estimating work in Scrum for example, you don’t use time as a metric, but points. Points are supposed to be some kind of mix between complexity, uncertainty, effort and time.
I will make your life easier as an agile developer: yes, points are strongly related to time, but our “developer” vision of time. You are already thinking in term of points in your head. When a developer says it will take him/her 2 days to complete a task, he/she obviously cannot know for sure. Nobody does. It is actually proven how bad we all are at estimating our work. When a developer says “2 days”, what he/she is actually saying is:
Given my experience and knowledge of the matter, and the fact that things often tend to go wrong, but sometimes we have a nice surprise, but in the end it also depends on my ability to find a solution quickly or go around the problem, I believe that I can code, test and fix this feature in about 2 days, give or take a few hours. And if I am not the one to do it in the team, I believe that should be about the same, or will be compensated by something else.
Then apply some kind of ratio depending on the team and you get a number of points, for example 11 points. In Scrum, the scale is based on the Fibonacci series, because the higher the number, the bigger the uncertainty. So it’s either 8 or 13 points. You then discuss with other developers, fears of some against confidence of others, and you end up with a number. Yay!
In the end, it all comes down to one thing: developers are asked to do things they never did and tell in advance how long it is gonna get them to do it. The important thing is to rate stories by comparison, so that your points stay coherent.
