I am currently working as a product owner in an investment banking firm and we follow agile software development. As per my understanding and research, the user story should follow the below checklists

  • Acceptance criteria

  • follow 'INVEST' rule

  • mention about user permissions

  • Handle concurrency and conflict checks

  • Proper UI design

  • Impact in other functional areas

I am not sure if this fulfills the qualities of a good user story. My intention is to understand and prepare a best checklist to write quality user stories. Please suggest and highlight the points to be included in user story with examples.

3 Answers 3


A guiding value of agile is individuals and interactions over process and tools. What this means is that agile favours conversation and interaction between team members.

This is one of the reasons that the user story came about. It is not intended to be a detailed requirement. Instead it is an invitation to a conversation.

It is quite acceptable for a user story to be a simple sentence and it is not necessary to have details such as user permissions, design and impact areas.

You are probably thinking that a user story without details is not going to contain enough information for the development team to do the work properly. This is correct and that is where the conversation comes in.

Think of a user story as going through a life cycle:

  1. First it is a simple sentence, just sufficient for people to understand what the requirement is about and so do prioritisation.
  2. As the user story moves towards the top of the product backlog the team may do some backlog refinement on it. For example, the Product Owner might talk about the story with the team to ensure they are clear what they are after.
  3. When the user story reaches the top of the product backlog it may be that the team wants a bit more detail added. They do this so that it is easier for them to estimate. For example, they might ask the Product Owner to work with them to add some acceptance criteria or other details.

You ask the question "What makes a good user story?". I would answer that it depends on where in the life cycle the story is. Initially a good user story will just be a clear, descriptive sentence. By the time you get to sprint planning a user story should have evolved to include any details that are necessary for the team to estimate it and then start work.


The things you list can all be useful in creating good user stories, but none are strictly required. I do think you're approaching the problem from the wrong angle.

To really create effective user stories, you need to focus on the fact that a user story is, first and foremost, an exercise in empathy with a user. In XP (where the practice originated), the user story would actually be written by a real user and it is meant as a way to convey a need they had.

As an example, I know of a credit card company whose users were frustrated in the card selection screen that simply seeing the last 4 digits of the card wasn't enough to know which card was which. So this results in a user story something like this:

As a cardholder with multiple cards, I would like to be able to easily tell which one is which so that I don't waste time clicking on the wrong card.

This is a pretty good user story even without any of the checklists because it effectively expresses the needed and allows the team to empathize with the customer. From here, the team inquired how people usually told the difference between their cards and found that they used the different visual appearance of the cards, so they showed what the card visibly looked like on the screen to solve the challenge.

I don't mean to suggest that the those items you list aren't useful. On many user stories you may find in backlog refinement with the team that some or all of those items are useful tools. However, the only real litmus test I would apply to all user stories is:

Does this story help the development team effectively understand the need of the user and allow them to start creating a solution for that need?

  • Dan, thanks for your answer. I am not sure if this is a valid scenario. Let me try to explain with the help of this user story. As a passenger, I want to link the credit card to my profile so that I can pay for a ride faster, easier and without cash. In this case, the user can link credit card his profile from two areas. 1. My profile page 2. Personal settings If i missed to mention about the personal settings in the user story, what will be expectation from Development team. Should i create a separate user story as a change request to capture credit card details from personal settings? Commented Jul 19, 2019 at 10:25
  • An important thing here is to keep in mind that the PO is part of the Scrum team. This is a collaborative effort. You could certainly include an acceptance criteria that reads "User can link credit card in profile page and personal settings." but it isn't necessary. Again, user stories are for creating empathy. Yes, including the note is quicker, but if the team wouldn't ask that questions without the note, there is a different empathy problem in the team and leaving it out might be a valuable learning experience.
    – Daniel
    Commented Jul 19, 2019 at 10:30

User stories are short descriptions of something your customer will do either on your website or phone app. I think you are on track with using INVEST to develop criteria, but it looks like you're missing acceptance criteria.

So your scorecard is INVEST - does the story meet all criteria? Next - how do we know when the story has been successfully completed, this is where your acceptance criteria comes into play.

Using the example above: "As a cardholder with multiple cards, I would like to be able to easily tell which one is which so that I don't waste time clicking on the wrong card."

Acceptance criteria: * customers can select specific cards identified by last 4 digits of card * customers will see a list of cards in their profile identified by last 4 digits of card

I think identifying what makes the story successful first will help develop the actual story.

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.