Specifications Are Not User Stories
You've confused the specifications of an implementation with a user story. User stories are not about how something is accomplished; instead, a good user story focuses on providing sufficient context about the user's goal to guide the development team's implementation.
For example, you provide the following specifications:
- As a user I want to add transfer amount
- As a user I want to choose the type of a transfer
- As a user I want to see the total cost of a transfer
These are clearly implementation details of your system. The user is unlikely to be thinking in these terms.
User Stories Provide Goals and Context
While it's hard for someone not involved in the process to know for sure what your users may want to do or how they think—you did ask them, right?!—it's probably safe to say that the bullets above don't capture the actual user perspective. Consider the following alternative:
As a bank member at an automated teller machine,
I would like to transfer money from my savings to my checking account
so I can be sure there's enough money in that account to cover a check I'm writing today.
Who? Note how the first line provides a detailed portrait of the value consumer for this story. It's not just a "user," it's a user with clearly defined characteristics that provide context for the rest of the story. This provides essential context that may differentiate the story from a user who is using online banking, visiting a teller, or an armed bank robber, each of whom is unlikely to want to value the same elemets of the process.
What? The second line defines the goal, and provides further context. From the user's point of view, the feature isn't just "transfer money" after all; the user has a specific goal in mind. Perhaps it's doing wire transfers, ACH, intra-bank account transfers, teller bribes, or Nigerian 419 scam payments.
Why? Your current bullets don't describe why a user might want to transfer money. How a feature is implemented may vary based on context. By adding a why-statement to your story, you help to guide and constrain the implementation to best serve the user. In this case, the context may suggest that showing the account balances before and after the transfer should be part of the implementation because transferring the money isn't really the point. The user's real goal is to cover an outstanding check, and that purpose may or may not be served if you focus too narrowly on just the transfer function.
In short, a great user story describes the actions a user is taking towards a concrete goal, and the value that the user expects to receive from completing the activity. While it's certainly possible to write other types of user stories, if the bulk of your user stories don't provide a value statement for a value consumer then you're probably just writing technical specifications in a less succinct format. Don't do that!