User stories describe the actual customer requirements which are nothing but the functional requirements for developing a software product. How good you write a story is directly proportional to the efficient requirement gathering for building a product which ultimately reveals the quality of the product. In this article, we are going to discuss on how to write good agile user stories and what should and should not be included as a part of user story.
Agile user story is not like any traditional or fictional story but it is story that has valuable information about the business which a team can use to build a customized software product in a sprint. An agile user story has the conversational details between the requirement gathering team and the customer. However, a requirement document or SRS is very detailed and has lots of information in it for building a product.
The following is the breakdown structure for an agile user story.
- What customer needs? A brief description of that requirement.
- Record all the conversations that took place during sprint planning and backlog mentoring to congeal the details.
- All the acceptance tests that approve the agile story’s reasonable conclusion.
While writing the user story, you need to think from the user’s perspective or point of view as that user is the one who is going to use the software product. Therefore, the story and the bullet points in that story should fit the end user’s purpose.
The following are the tips to write good Agile user Stories:
User Stories should be independent:
The user stories should be written in such a way that there should not be any dependency between them. This approach will help in the development as they do not demand any specific order.
Concise Matter in User Stories:
It is not an essay writing competition, therefore refrain from adding unnecessary details and increase the flexibility in order to help the development team in their implementation. Also, the user stories should not be verbose. The best agile user story is concise and negotiable.
The agile user stories should have the valuable information that providesdetails about the business requirements of the customer. Therefore, the matter present in the user stories should be capable of adding values to its users.
The Agile user stories should not be ambiguous and verbose. They should be written very efficiently such that the development and the testing team can easily give their work effort estimate in order to complete this mini project.
Small Sized Stories:
As mentioned earlier, the user stories should not be verbose or essay type, they should be small enough so that they can accommodate easily in a sprint of agile methodology. Long agile user stories are often tough to capture for work estimate and project planning and should be broken down to smaller ones.
User stories after implemented by the development team should be well tested and verified that it serves the user’s expectations in the end product.
The following are the tips on format to write the agile user stories:
The <user type> want(s) to <feature>so that this can add <business value>.
E.g. As a member from the administrator group of securedbank.co, I want to add a 2-phase security protocol so that my system can completely block the illicit access to the hackers.
In the above small story, we identify the customer group of a particular organization and what actually that user wants to get implemented which will add value to their business (i.e. blocking illicit access to hackers).
Moreover, the user stories have the following noticeable points.
- Narrative: A user story should be very narrative in order to describe the user’s intention. It should look more like a summary.
- Conversations: A user story should lists down all the bullet points which cover all the crucial aspects of the client’s expectations.
- Acceptance Criteria: It defines all the conditions of client’s approval which are transcribed as scenarios in the user story.
Writer Of The Agile User Stories:
The product owner or the BA (Business Analyst) are the best persons to write agile user stories. It is not mandatory that only these project roles should be capturing the user stories, instead any team member can write the agile user stories as long as that team member is compliant enough to follow above tips and format of the agile User stories. The writer of the user stories should make sure that it adds the value to the business and BA can easily covert these user stories into product requirements that development and testing team can use correctly to do the work estimate and delivery the end product on time.
Mitigate The Common Mistakes While Writing User Stories:
The following are the common mistakes that should be mitigated while writing the agile user stories.
- Verbose user stories: At moment BA or product owner can be too formal and narrate the user stories in very detailed manner. This makes the development and testing team to provide the incorrect estimate as it gives the feeling of large sprint. Therefore, user stories should be to the point depicting what actually is needed by the customer.
- Technical tasks as User stories: User stories are only meant to summarize the customer requirement as a conversation that the project team can use to build the product in iterations. If technical tasks are written as user stories then it will be very difficult to build the products in iterations and it may delay the product acceptance task and hence its delivery.
- Skipping the acceptance criteria: Acceptance criteria is an important part of the agile user stories, if this part is skipped in user stories then it may result in actual overlooking of the customer requirements which may lead to testing in the wrong direction.
The product owner or the BA (Business Analyst) are the best persons to writes the precise agile user stories. Such user stories will always lead to the product development and testing in the right direction which will eventually result in customer satisfaction. We have discussed the tips, formats and the common mistakes to avoid while writing the agile user stories, after implementing these tactics; definitely you can contribute a lot to your project.