In an agile software development environment, the user story is an important artifact. Atlassian’s definition of a user story says an “informal, general explanation of a software feature written from the perspective of the end user.”
Regardless of what tools you use (Jira, Trello, LeanKit etc) or the framework you follow (Scrum, Kanban, XP etc), user stories provide a high-level picture of the requirement from the end user's perspective.
This thought recently popped into my mind when someone asked me what template to follow when writing a user story. Perhaps you have encountered or asked this question before.
As a Business Analyst,
I want to use a template to write a user story,
So that, my team will understand the requirements.
Do formats and templates really matter?
The answer, in my opinion, is No! User stories do not have boiler templates. BA's skills aren't determined by how well they write user stories, but by how well they analyse and communicate the requirements to the team.
Learnings are:
- The emphasis should not be on writing a well-written user story or ticket or document, but on communicating the details well.
- Adapt your style to your team's needs. I have worked with teams that prefer a diagram linked to an epic or a confluence page to get started. I've worked with teams that prefer getting requirements written in a few sentences, and I've worked with teams that prefer adding the requirements in a table format. The BA should be able to figure out what works for your team.
- No matter what the format is, use simple language so that team members can understand it. Keep it simple and concise.
- Make sure the Who, What, and Why are answered and everyone is on the same page.
- Importantly, spend quality time discussing the requirements with the team during refinement, story mapping, and work plan sessions. Gather their questions, clarify their doubts, and check the areas that were overlooked.
- Use visual representations, if it helps to convey the requirements easily rather than a long essay of requirements.
- When slicing requirements, use the INVEST methodology. Consult with the team before slicing because technically work can be divided differently for the ease of development and testing.
- BA should be a storyteller who tells customer stories, not just a document writer.
- The process of writing user stories requires teamwork and practice. Team members should have conversations to ensure the work is accurate and targeted.
- Focus on contents such as scope, acceptance criteria etc. Share all the required details with the team to take informed decisions and come up with better solutions.
- The real world is different from frameworks and formats designed for ideal scenarios. Having a well-written/reviewed ticket but not getting what you expected isn't valuable. Hence, the focus should be on shared understanding and outcomes.
- There is a common myth that anyone can work on a well-written ticket if it is well-written. The way people understand details can be different. In spite of something that is obvious and straightforward, mention it to establish a common understanding.
The development team should not get caught in a situation where user stories fail to meet acceptance criteria due to a lack of clarity or understanding. In the same vein, it is not a piece of evidence against BA/PO to claim something is not spelled out in the ticket. Be agile and learn from your mistakes. Refine the way you work based on your learnings. Depending on the nature of the work or the requirements, the details can be complex or simple.
As stated at the beginning of this article, a user story is an important artifact that contributes to conservation, idea generation, tracking work progress, and a reference for release notes. But its format doesn’t need to be pristine.
In summary, the user stories are not high-end literary works to be sampled for minute grammatical and lexical errors. Don't put too much emphasis on following a foolproof format, but on conveying the requirements effectively with the team.
As a Business Analyst,
I want to craft artifcats that will help the team to understand the requirements,
So that, we can build and deliver value to the customer.
Author: Sumi Prasad, VISA - CPOA | PSPO I | ICP-APO
Sumi Prasad is an experienced business analyst at Visa Inc based in Auckland, New Zealand. She has strong product- oriented mindset and loves to think creatively. She is a fun loving person who is very enthusiastic about learning and advancing in business analysis space.
You can contact Sumi on LinkedIn: https://www.linkedin.com/in/sumi-prasad-30b75b13b