Scrum Testing Best Practices | Write Scrum User Stories

In scrum testing, when using the scrum methodology, one of the most important elements is the user story. User stories are the requirement specifications in scrum. Usually, the product owner is responsible for writing and prioritizing the user stories and then explaining them to the team during sprint planning meetings. Sometimes a developer in the team may also help the product owner create user stories to add more technical detail. In many situations, there are no testers involved in the discussion of and creation of a user story. However, it is important for user stories to be written such that they are ‘testable’ in scrum because, without accurate and complete testing, the user story cannot be marked as ‘Done’ for the sprint. Scrum Testing User Story Best Practices Best practices in developing user stories, thus are driven toward ‘easily testable’. From a testing perspective, a good user story should include the following components: User: In most systems, there are different kinds of users with various user rights. For example, insurance software may contain the insurance company employee, insurance agent, customer and administrator. Therefore, it is necessary to include which user type is targeted for the user story. Functions: This the core part of the user story which describes the functionality that the user can perform. A good user story should contain a proper function description. Usually, it contains details of the function or set of functions. If the function is not described in enough detail, creating good test cases will be difficult. User Objective: Some product owners may ignore this part when they are writing user stories perhaps assuming it is already known. However, it is critical for test case development. By knowing the user’s objective of the user story or the business rule of the function, testers can deeply understand what to test and what the end user wants to accomplish leading to more suitable test cases. In short, a user story should contain above three main parts: User, Function and User Objective. Even though some user stories cannot entirely encompass these elements, it serves as a rough guideline. In addition, we think there are 3 main user story categories; new function, function enhancement, and defect. We’ve listed our best practices for each one in order to write an easily tested user story. New function: Every new function should be described as a user story. The recommended format is “As a , I can , so ”. For example, “As administrator, I can add a new user, so that new user can log in to the system”. Function Enhancement: The enhancement usually means making an existing function better. Therefore, this should be represented in the value element. For example, “As administrator, I can see 100 users in page instead of 50, so I can view user info more quickly”. When creating user stories for enhancements, try to use “instead of” to represent the improvement place and some adjective/adverb to show the additional value. Defect: When there is a defect that needs to be fixed it is also sometimes written as a user story. In this situation, it is necessary to add the time and the result of the defect to the user story. For example: “As administrator, when I am viewing the user information in the system, the browser is closed.” Besides the content, some additional best practices for writing user stories include: Title: If the user story is an epic (general and large story that needs to be broken up), use noun word to name the title. For example “Administration”. Otherwise, use a verb phase such as “Add new user”. Constraint: Make sure you list constraints for the user story, if any. For example, for the user story “Log in system”, there may be a constraint “The system should support at least 50 users to log in system at the same time.” These user story writing best practices can be used for more than scrum testing. In particular for agile testing we use similar practices.