I coined the term UserStory, as far as I know, so I'll tell you what I had in mind.

My purpose is to maintain a balance of political power between business and development. Use cases as I have seen them used are complex and formal enough that business doesn't want to touch them. This leads to development asking all the questions and writing down all the answers and taking responsibility for the resulting corpus. Business is reduced to sitting on the other side of the table and pointing.

I want a very different dynamic. I want business to feel ownership of and take responsibility for the care and maintenance of "the requirements". I want business to feel comfortable making priority decisions about the requirements. I want business to feel free to add new requirements, and add new detail to existing requirements, as development progresses (see also ProgrammingIsSocialLearning).

This requires a form of expression that is more approachable than a formalized use case. It also helps if the communication medium is something approachable, like IndexCards. So I say, "Tell me the stories of what the system will do. Write down the name of the story and a paragraph or two."

My experience is that business, properly trained, takes to managing stories like the proverbial duck to the equally proverbial water. Business has to be trained not to just throw new stories into the CommitmentSchedule or WorkQueue without a DevelopmentEstimate and the necessary reshuffling. Development has to be trained to begin examining stories enough ahead of IterationPlanning so learning the next level of detail does not become a bottleneck or a risk.

So, to answer your first question [User Stories and Use Cases are the same thing?], yes and no. The idea of specifying the behavior of the system from an outside perspective, and using those specifications throughout the life of the system is the same. The execution is quite different

Kent Beck, http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison