Andre-
Lee & Emmanuel gave some great responses, so I'll limit myself to the
programmer focus.
I like the term, "yesterday's weather is the greatest indicator of
today's". This can be used to help management or the team understand
that if they have produced 20 points (or 200 hours) of stuff for the
last 3 sprints, then it is unwise to keep planning 30 points. Wishing
you can go faster won't make it happen.
Lee touched on the velocity point and that is a big part of what story
points are about. By abstracting to a complexity unit of measurement,
human error is reduced. Also, this abstracted unit of measure isn't
as hard to recalibrate as the team matures or adds people (meaning the
product backlog won't need full re-estimation workshops). There is a
lot less arguing over the actual number when it is smaller (product
owners don't care as much about the difference between 19 and 20 story
points, but will care about the difference between 140 and 160 hours
since that "is more than 2 man days!").
So... to help your programmers down this path, ask them if they want
to be held accountable for every hour and every estimate they make?
Or do they want a higher level language that they can negotiate with
the customer and management with? That might be your selling point
for story points.
Another tidbit... think about your story point scale. You don't want
people arguing over 6 vs. 7 story points. Lee's reference of Mike
Cohn will provide insight to that also. (Many people use the 0, 1,
2, 3, 5, 8, 13, 20, 50, 100, ?, infiniti scale)
Good luck!
(Note: I think this is a great forum to ask agile process questions in
since we are all trying to practice agile by supporting it with V1.)