In an agile project, the time to implement a story (a feature), is deliberately estimated in a weird unit called story points, rather than in number of hours / days.

The most important thing to remember is that story points do NOT equal units of time.  Initially you will naturally find yourself trying to convert story points to days, or estimating in days or hours, and then trying to convert that to story points.

RESIST this temptation!  There is a method behind the madness.

• Research has shown that people are better at estimating relative sizes (A – C is twice as far as A – B, Basket X is about 1/3 the weight of Basket Y) than coming up with absolute estimates (A to B is 15km, Basket X is 7.5kg)
• Days are a very subjective unit of measure.  Depending on other commitments, your ideal days are very different from mine.
• Estimating relative size is much quicker; and you need less information to get started (you don’t actually have to know how long anything will actually take, just the relative comparisons between different stories)

With a new project its impossible to know how quickly features will be produced.  There are just too many variables – learning of the domain & toolset, agreement within the team, stabilizing of work patterns.

What you do is complete a couple of iterations, and then measure how many story points you delivered on average.  This then becomes your velocity, which you can use to derive an estimated completion range based on the story points.

Note that with this technique your story points are still valid; as they are just measures of relative size/complexity.  The only time you really need to re-estimate story points is when you got the relative size of a story wrong – perhaps it turns out to be much easier to send emails than you thought, or much harder to draw graphs.