Limitations of user stories

User story is one of the ways to communicate software requirements from user to the developers. User story is used for requirement gathering in agile software development project such as extreme programming. In general user story is a short goal oriented story on how a user will perform certain tasks with the system. Commonly, a user story contains the context of certain task, condition which triggers this user story, and script which illustrate how user do the tasks on step by step basis. User story should be flexible and free from any decision making such as user interface design choice. This user story will act as an agreement between the user and developers on the software being developed.

User story is a simple way to express the behavior or characteristics that user needs. It hides all of the complexity and focus on how a certain task can be performed. User story looks fit into agile software development practices. That is why it is used to specify requirements in extreme programming. However, user story is not a perfect tool. It has some limitations. This blog will discuss what the limitations are and show any solution to minimize the constraints.

One of the main limitations of user story is that it opens for many interpretations. User story is simple and contains scripts which focused on a functional goal. It does not state the detail of the user interaction with the system. Our customer may have different understanding with the team. As a result, it is hard to use user story to act as an agreement between the user and developers. That is why it is suggested that the customer or end user is part of the team, so that we can communicate and clear any doubts through face to face communication.

For example, if we have user story on a manager who want to send out a survey to his staff. The first story or first action in the script will be the manager would select the option to survey staff. One developer might implement this user story with a button to choose the survey staff, and other developers might use drop down list. As we can see that user story is straightforward, plain and free from any design (decision making). It will focus on capturing user requirements and try to be free from any user interface design, so that it can be implemented in many ways. We can solve this problem by discussing the design with other developers and sketching user interface design before we implement a user story.

The simplicity of a user story also causes another limitation. It lost the performance requirement detail. Often, user story which becomes the basis of user acceptance test will only test the business logic of our application. It will not test the performance or our database layer such as database response time. To overcome this limitation, developers or testers need to pay attention to other documents such as product attributes and system constraints when building the test case. Therefore, developers and users have to develop these documents carefully as it will accompany the user stories.

Leave a Reply

Your email address will not be published. Required fields are marked *