Five Common Mistakes in Writing User Stories

  • Share
  • Sharebar
  • Share

Most of the issues agile testers have is gathering requirements in agile software development and agile testing from issues found in User Stories. Expressing requirements in such a simple form causes a lot of trouble to agile teams.Of course the art of writing a good User Story is difficult for most new teams starting a new agile project or these, which have just transformed development methods to for agile software development methodology.  Mistakes made at that point lead to wrong Test Cases, wrong understanding of requirements, and wrong implementation which can be direct cause of rejecting the deliverables of the iteration. Today, I am going to share with you the top five common mistakes made when writing User Stories.

User Story on index card

User Story on index card

Introduction to User Stories

A User Story is a short description of customer’s need. User Stories are commonly used in agile software methodology and frameworks such as  Extreme Programming or Scrum as a way of gathering requirements. Whenever possible, a User Story should be written by a customer. If the customer can’t write the User Story, a business representative can write it on behalf of the customer or referring to a potential customer aliased as persona. A User Story should be kept short and fit on 3×5 index card. The text on that card covers the role of the user in the system, the need expressed by user, and the benefit from the described feature.

The main purpose of using this tool is to estimate the effort needed to implement a new feature in software accordingly to the Definition of DONE for the team.User Stories also enable conversation that leads to extracting business and technical requirements and eliminating hidden assumptions. Sometimes they User Stories are mistaken with Use Cases and Use Scenarios, but the biggest difference is that they are much shorter and do not describe the application interface, steps or flows in the application.

Implementation of User Story is confirmed by Acceptance Testing being derivatives  of Acceptance Criteria sometimes referred as Conditions of Satisfaction. To estimate at that point  we only use points, ideal days, or other units representing size rather than the actual time that is needed to implement the feature.

There is also simple template helping to make sure that all the elements are kept, “As who I want what so that why.”

Here is the longer and more descriptive version of that template:

As a <specific user/persona/role>I want <desired feature/issue that needs to be solved>, so that <benefit from implementing the feature>” + Acceptance Criteria

Each of these elements is important and has a role in expressing and understanding the captured requirement.

Five Common Mistakes in Writing User Stories

1. User Story for a User

Example: ‘As a user I want to be able to manage ads, so that I can remove expired and erroneous ads. ‘

At the first glance you don’t see any issues with that User Story, because all the required elements are present. Now tell me who is the user for which you are going to build that feature of ads management and what does he or she understand about ad management? Is that a portal administrator who wants to have possibly of database clean up and ad moderation? Or maybe it is an advertiser who wants to have list of all the ads he or she has submitted and have the option of removing ads when they are no longer needed or an error was found in the content? As you may have noticed, I mentioned only two different roles with different expectations from the system. In this case what is missing is the persona or role mentioned.

2. User Story for Product Owner

Example: ‘As a Product Owner I want the system to have possibility of deleting ads, so that users have possibility of deleting ads.’

All three elements are here, but there is something wrong. First of all, this User Story is a type of ‘you want a story, here you have one’. Obviously the person writing this User Story did that only for sake of doing it. You can have a Product Owner playing the role of a person using the system if you build software for teams using agile software development. That indicates issues with implementation of agile methodology in that organization. Second of all, you have exactly the same issue as in the previous example. There is no role or persona to give you clues about user expectations.

User Stories on

User Stories on

3. User Story for Developer

Example: ‘As a developer I want to replaced the folder widget, so that I have maintained folder widget.’

This is a typical example of an User Story for a Technical Backlog or technical requirement representation. Sometimes User Stories like this one are a part of a so-called technical debt. Technical debt consists of necessary maintenance tasks like software updates, re-factoring, changing frameworks, and so on. They are totally rightful to be implemented, but when they are represented like in the example above, they do not represent value for the customer and you will not get a buy-in from Product Owner. From the ‘agile point of view’, you need to deliver a business value at the end of every iteration and the team needs to be able to present it to the stakeholders on the Review Meeting.

How to write such a story correctly? Rewrite it from a user point of view with persona on role:

Example: ‘As a commercial user I want the system to allow me run multiple searches at the same time, so that I can do my job faster.’

Task to go with it can be: ‘Re-factor search handling mechanism to allow multiple threads for single user.’, ‘Update java version to 64-bit one.’ Acceptance criteria needs to define some measurable and testable definition of improvement like: ‘Single user can run five searches at the same time.’ and ‘Search returns results in less than four seconds.’

4. No Business Value or Benefit for Customer

Example: ‘As a commercial advertiser I want to have filtering option.’

We have the role, we have the need, but reason and business value are missing. Why does a commercial advertiser want to have filtering option? What does he or she want to achieve?

5. No Acceptance Criteria or Conditions of Satisfaction

Here you can use an example of one of the examples above. The problem in such practice is often underestimated. Not having Acceptance Criteria sometimes referred as Conditions of Satisfaction can cause the whole chain of mistakes starting with wrong definition of development tasks or wrong estimation. A User Story can fail the test or Test Cases will cover different criteria due to lack of understanding. Acceptance Criteria plays a role in the confirmation of requirement understanding and decide the acceptance of iteration deliverables. A Conditions of Satisfaction questions the User Story enable conversation between the Product Owner and the team. A good way of gathering Acceptance Criteria is asking questions such as:

  • ‘What if … ?’,
  • ‘Where …?’,
  • ‘When …?’,
  • ‘How …?’.

Use examples and simple drawings to remove assumptions. It can happen that the Story needs to be refined and re-planed, or quite often split into smaller User Stories.

Now it’s Your Turn

Share other issues you have found in your experience with using User Stories and a way of resolving them.


Similar Posts:


  1. [...] Developer or anyone else). Each user story corresponds to benefit to user. Read some valuable clues here. Share this:Like this:LikeBe the first to like this [...]

  2. John says:

    As the original way of writing a user story was something like “A user can post her resume to the website” how has it come to the way that you suggest? Are most people writing user stories wrong, including yourself? Or have people just expanded on it with their own templates?

    • Hi John, I know this form from “User Stories Applied” by Mike Cohn, so we can say it’s known from at least 2004. You are making here a few claims. Do you have something to back them up? Where is your “original way” from and what means writing user stories wrong. User Story should incude specific user, specific need and problem to solve. Your example is missing at least two of this components.

  3. John says:

    Hi Krystian, sorry if my comment seemed liked criticism, thats not my intention though, far from it, i’m actually trying to find out the correct way to write user stories and now im beginning to realise that although Mike Cohn suggests writing them a particular way that they dont necessarily have to be written exactly as he suggested back in 2004 in his book? Im currently learning about agile and intend to use user stories with scrum so im trying to get my head around all of this.

    My mistake has been that i thought user stories could only be written like “A user can post her resume to the website” and nothing more, but i realise now that my understanding was wrong.

    I am seeing slight variations on other sites and i got it into my head that theres a strict way to write them but it seems that people create their own way, like their own template for writing a user story, as long as it includes the user and problem that its solving parts too?

    • Hi John, it’s ok to have discussions ;) I didn’t take that as a criticism. There are slight variations, but as you said, as long as the principles are kept, it’s fine. I suggest using few variations and checking what works best for the Team.

Leave a Reply