If you are extremely familiar with both techniques then this makes sense. If you are not familiar with both then suffice it to say that you can put a gazelle in a gazebo but not vice versa.
A user story is of the form As a <type of user>, I want <some goal> so that <some reason> (see here).
A use case for withdraw money has many more components to it, and a skeleton of such a use case can be found here. I develop this skeleton use case in a four part tutorial:
- Part 1: Use case as a dialog
- Part 2: What is an actor?
- Part 3: Adding interface details
- Part 4: Adding application context
Extreme Programming methodology. The assumption was that there will be a high degree of interaction between the developers, and the end customer and that QA will largely be done through test driven development. It is important to realize that Extreme Programming does not scale.
Once your development team gets large, i.e. you have 3+ agile teams and your code base gets large enough to warrant a formal testing environment, then you will outgrow user stories as your only method of capturing requirements.
You can still use user stories for new modules developed with an end customer to take advantage of the light weight and rapid nature of user stories, but at some point those user stories should transition to use cases.
Unfortunately, there are quite a few ways to build use cases and not all of them are effective. Alistair Cockburn's method (found here) is an excellent way to capture use cases for more sophisticated systems. There is no doubt that use cases are heavier weight than user stories, but consider this:
- Use cases can more easily be turned into test cases by QA
- With use cases you more easily prove that you have all the requirements
- Use cases annotated with screens and reports can be used to collaborate with remote off site customers
- Well written use cases can easily be broken up into a sprint back log
- Use cases will work if you are not using Agile development methods