The correct way to size an agile user story is by assigning each story a "story point" value. The values assigned are usually taken from the Fibonacci sequence or: 1, 2, 3, 5, 8, 13. Story point values are similar to the concept of "T-Shirt" sizing as follows:
The larger values as you go up are a reflection of the uncertainty of the actual amount of effort required to develop the user story.
When estimating user stories (or as some people like to refer to them, business requirements), it is actually easier, and more accurate, to estimate the size of a user story relative to other stories, than it is to state that a particular user story will take X number hours to complete. This is because the amount of work a person can complete in an hour varies greatly between people, skill sets, and experience with the technology used. This gets even more complex in a team environment because team dynamics also affects the overall team performance.
The most useful thing about estimating with story points is that they can then be used to subsequently calculate the number of story points completed in a development iteration. In agile terminology this is called the project velocity. Actual velocity of any development project varies with the size and experience of a team. Computing velocity helps the team to improve their estimates over the life span of a project.
As a rule-of-thumb when first estimating project velocity I like to figure about 2 points per day per team member, for each team member that spends 100% of their time on the project.
If you are looking for a project managment tool to help with all apects of Agile software development, I would recommend Rally from Rally Software. Rally is particularly good at dealing with estimation and project velocity.
For more information on how to develop effective user stories I would recommend the book: