I'm a beginner and looking for a best way to create user stories for my project and I need an advice. It's about a money transfer project where I have to create a transfer flow: Configure Transfer, Add Receiver, Summary, and Finalize.

Are these just four user stories for this process, where all details should be specified in the details section in a JIRA user story, or should I split the first one? For example:

  • As a user I want to add a 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.

and so on, or it should be just:

  • As a user I want to configure my transfer.
  • As a user I want to add a receiver.

5 Answers 5


There are some basic guidelines to split stories into smaller stories. This mantra almost always works. However, it takes little time to get used to.

Follow I N V E S T

  • Independent - Stories should be independent of all other stories.
  • Negotiable - Story should be negotiable between development team and PO
  • Valuable - A story should contain a value for the customer. It also helps PO to prioritize based on value.
  • Estimable - A story has to be able to be estimated or sized so it can be properly prioritized
  • Small - Small stories always have better clarity
  • Testable - Every story needs to be testable in order to be “done.” In fact, I like to think of testable meaning acceptance criteria can be written immediately

I also love these story split patterns. However, understanding these patterns and selecting the right one for your story type could be little challenging initially.


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!


A rule of thumb I'm used to use is:

will my user be happy to receive the functionality X?

So, in your context, 'will your user be happy if he can (only) configure a transfer?' I'd say he won't. So maybe, in your context, the 'Story' is

As a user, I want to transfer money.

That's it. Simple. You might want to enrich it to help in your definition of done, like:

As a user, I want to transfer money, having a review before confirmation and having the possibility of using a favourites deliver list Any breakdown can be considered 'tasks' you have to do to deliver the user Story.

As more details you have in your story, as more accurate your product will be. On the first story 'I want to transfer money' it doesn't mention if users can double check before confirmation nor having a favourites list (two very common functionalities) so you can deliver the first without them and still discuss with your user that 'you delivered as per requirements' (don't do it, it'll just generate frustration). Better to understand user needs and reach to a point where the story is clear for both sides.


I don't know what methodology User Stories comes from. I'm familar with what are called Use Cases.

So for the Use Case you break each case into the steps that a user would make and what the system needs to do to support that.


User to transfer funds between accounts

  • System displays login screen
  • User logs in with user ID and PW
  • System displays "Main Menu" Dialog
  • User selects "Accounts > Transfer Funds" from the menu
  • System displays "Select From Account Dialog" with list of user accounts
  • User selects from account
  • System displays "Select to which Account Dialog" (From account displayed, but disabled for selection)
    and so on...

Part of this is that this captures the actors in this interaction. So it may be important to differentiate if the customer is using an ATM or his home computer. The displays would almost certainly be different. But in both of those cases communication is happening with some background system. So one type of cases has user, atm, and system, and the other type of case has user, home computer, and system. Also note that home computer uses ID & PW, while ATM uses ATM card and PIN.


Don't forget the 'so that' part of the user story. It is important that a user story includes a description of the value delivered to the end user. This helps non-technical people to understand the reason why a user story is being worked on.

The larger story you mentioned could be something like:

As a user I want to configure my transfer and add a receiver so that I can complete a transfer successfully

Now it is possible that this story will be quite large, possibly taking more than a sprint to deliver. In which case it could be described as an epic and then broken down in to smaller stories.

A good approach to writing stories is to follow the INVEST mnemonic. This includes ensuring that stories are small.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.