Hi,

 we're currently implementing some the XP concepts when we can see the
 reason for using a concept. Mostly this is due to some problems we
 identify. I'm not a consultant, but integrated into a development
 team, perhaps that allows me to see things from a different
 perspective.

 I found that people dislike "guessing" effort in time, because they
 feel bad if estimated ideal time is small compared to actual time.
 This can lead to the following problems:
 - overcommitment (but this time I'll do it in 2 days! really!)
 - undercommitment (if I guess a lot too much, I feel better if I'm wrong)
 - artificial pressure (I guessed 2 days, so I need to do it in 2 days,
 let's not do refactoring now)
 - demotivation (being wrong makes me feel bad)
 - problems with communication to product management ("but you said
 you'll do it in 2 days, now it took already 5!" - "but I said it's
 ideal time!" - "than tell us the actual time it will take the next
 time!" - "but I can't do that" etc)

 Using points solved this. Perhaps explaining to the developers that
 they have to accept that ideal time has nothing to do with actual time
 and that they should not worry too much about correctness of single
 guesses and explaining to product management that there are different
 time estimations (some in ideal time and some in actual time) would
 have solved the issue, too, but simply using points is clearer, since
 you make the distinction explicit if you communicate about effort.

 If I tell to product management that this item has size 3 and they ask
 me how long it'll take, then I tell them that if they include it in
 the current iteration they'll have it at the time the current
 iteration finishes.

 All this is less communication effort for me and thus increases ROI
 because I can work on code instead of nitpicking on the concept of
 time  :-)

 Cheers,
 Manuel

Skiing in Garmisch :-).