Establish a Scale for your Estimation

The keys to a good estimation scale include defined magnitude and a pattern of relevancy that can be easily understood by all members of the team. Many techniques exist to establish this ranging from relatively mundane exponential number progressions to exotic dog breeds.
In my work, I have found Fibonacci numbers to be one of the most common systems. The expanding gaps between the numbers as the values increase accounts for the naturally increasing uncertainty associated with larger, more complicated stories. This can be hard to do with things like dog breeds or automobile types. Also, numerical systems make velocity calculations relatively straight forward. Saying that your team's established velocity is 'two German Shepherds, a Border Collie, and half a Shiatsu' would likely result in some strange looks (unless, of course, you assigned a numeric value to each dog breed which is typical).
A range of magnitude will need to be set according to the team's preferences. Either relatively small numbers (1, 2, 3, 5, 8, etc.) or large numbers (10, 20, 30, 50, 100, etc.) can be used. What is important is your team's ability to establish story relativity based on your system. Different projects will require different considerations.
There may also be some value in including zero. It is possible for a team to know with confidence that a story may not require any effort worth consideration such as the simple integration of already written and tested code that may only require an hour of a developer's time. If a one is used instead of zero, this will push the team's velocity above what it may actually be, especially if this occurs frequently.
In my work, I have found Fibonacci numbers to be one of the most common systems. The expanding gaps between the numbers as the values increase accounts for the naturally increasing uncertainty associated with larger, more complicated stories. This can be hard to do with things like dog breeds or automobile types. Also, numerical systems make velocity calculations relatively straight forward. Saying that your team's established velocity is 'two German Shepherds, a Border Collie, and half a Shiatsu' would likely result in some strange looks (unless, of course, you assigned a numeric value to each dog breed which is typical).
A range of magnitude will need to be set according to the team's preferences. Either relatively small numbers (1, 2, 3, 5, 8, etc.) or large numbers (10, 20, 30, 50, 100, etc.) can be used. What is important is your team's ability to establish story relativity based on your system. Different projects will require different considerations.
There may also be some value in including zero. It is possible for a team to know with confidence that a story may not require any effort worth consideration such as the simple integration of already written and tested code that may only require an hour of a developer's time. If a one is used instead of zero, this will push the team's velocity above what it may actually be, especially if this occurs frequently.
Give your Scale Meaning
The only meaning that an Agile estimation scale has is its relevancy. A two point story should require double the work of a one point story.
Two techniques are often used when it comes to setting the scale to your team's project. Either the simplest known story can be assigned a value of one and everything else is based off of that, or a medium difficulty story is assigned a value in the middle of your established range.
In my experience, the medium level technique is a lot easier to use. It's easier to say that a challenging 13 point story is roughly two five point stories than to say that it is 13 one point stories.
Two techniques are often used when it comes to setting the scale to your team's project. Either the simplest known story can be assigned a value of one and everything else is based off of that, or a medium difficulty story is assigned a value in the middle of your established range.
In my experience, the medium level technique is a lot easier to use. It's easier to say that a challenging 13 point story is roughly two five point stories than to say that it is 13 one point stories.
Assign Points to your Stories with Planning Poker

There are many, many ways to estimate story sizes and a review of all of them is beyond the scope of this article, but I would like to touch on one that is simple and popular.
Planning poker is best conducted with the entire team present. Each participant is given a set of cards numbered according to your team's system e.g., 0, 1, 2, 3, 5, 8, 13, 21 if using a Fibonacci system maxing out at 21. Stories are presented and discussed for a few minutes. On cue, each estimator displays their card with their estimate. Disparities and outliers are then discussed. It could be that a back end developer sees the story as requiring significantly more effort than a UI developer might.
After all of the issues are in the open, the team then takes another vote. This is continued until something like consensus is gained, usually after two to three rounds.
Planning poker is best conducted with the entire team present. Each participant is given a set of cards numbered according to your team's system e.g., 0, 1, 2, 3, 5, 8, 13, 21 if using a Fibonacci system maxing out at 21. Stories are presented and discussed for a few minutes. On cue, each estimator displays their card with their estimate. Disparities and outliers are then discussed. It could be that a back end developer sees the story as requiring significantly more effort than a UI developer might.
After all of the issues are in the open, the team then takes another vote. This is continued until something like consensus is gained, usually after two to three rounds.
Putting it all Together
There are a lot of ways of accomplishing Agile story estimation, and I have presented just one path through the process. If you are new to Agile development, these are amongst the most common techniques that are widely accepted. They should be enough to get things going until you have established your own system.