Jim'sPages => StoryProcess => StoriesDefined
Most agile methods call the smallest unit of analysis and development a "story." A story is:
Stories are definitely smaller than (our) Use Cases. Most examples I found would be a single flow through a Use Case. Some are just individual requirements. A good practice is to write down anything the customer wants from the system as a story. If it's too big to implement in 2-4 weeks, break it into pieces. If several stories address the same flow, put them together. If they turn out to not make sense, throw them out.
Agile methods say each story should deliver business value. It may be hard to see business value in small stories. Ron Jeffries gave an example: A graphics system developer proposed a first story to draw a straight line. The customer said "I get no value from a single straight line." To clarify, the method coach said, "Business value means the story does some measurable thing that the you want done, not that you can use it and make a profit." To make sure the code actually delivers value by doing a useful thing, every story must have acceptance tests.
This helps size stories. If a story has no acceptance test, it is probably a fragment. If it has several very different acceptance tests, it is probably multiple stories.
If a story is a promise to have a conversation, a Use Case is the record of that conversation.
When we do stories first, we can write down anything and everything the customer wants, then group them into Use Cases. I rather like this approach, as it makes the Use Case a record of story decisions. Knowing that stories appear, disappear, merge and divide all through the project prepares us for the Use Case to be a more dynamic document, rather than trying to "finish" the Use Case and carve it in stone.