Business Analyst User Stories – Best Practices from a Seasoned Analyst

 

In the discovery phase of an Agile software/product development project, a business analyst creates user stories. To understand the significance of user stories, we have to analyse how an Agile project progresses.

In such projects, a business analyst does not usually have the luxury of time to create a full-fledged requirements document. However, it is crucial to gather maximum information from the users at the beginning of the project, to save on rework and associated efforts later on. This is where user stories come into the picture.

360-Degree View of Requirements for Maximum Coverage

One point of view doesn’t show the entire set of requirements for a Software/Product. So, we need to look at the requirements from all the angles. This is the key to ensure maximum requirements coverage!

As far as ‘User Stories” are concerned, we need to focus on the word “User”. We must first think about the “User” and write the story of how the user interacts with the software/product throughout its lifecycle. This is what condenses into the “User Story”.

Best Practices that a Business Analyst Follows When Writing User Stories

·       As a Business Analyst, we need to think about the product and the end user, to come up with a story of how the product is utilised by end users.  This is the suggested approach to write the perfect user story.

 

·       It is also crucial to include all stakeholders before we start writing the user story.

 

 

 

 

 

 

·       Try using some pictures or characters to clarify the user journey. What kind of problem are we going to solve with this product/project? The answer to this question is the ultimate goal of writing the user story.

 

·       Write the user story using very simple language that can be understood by anyone. I have experienced that few people write the user story using complex sentences and jargons. This can confuse other team members and prevent them from getting a clear picture of the concept. This can, subsequently, lead to multiple meetings/discussions which cause further delay in project timelines.  Hence, we should always avoid these kinds of hiccups.

 

·       Always start with EpicsàUser StoryàTasks. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

One Epic should have one or more user stories. One user story should have one or more tasks. 

·       Keep refining the user story so that it is short and informative. So, whenever a sprint is defined by the Product Owner (PO), it will be easy for the scrum team to take up. It will also help the sprint to be completed without any carry forward of stories.

My recommendation - Each user story should be finished in maximum 8 hours (1 man day).

 

·       Make sure that you write Acceptance Criteria. In my experience, most project teams do not write acceptance criteria, and this messes up the Description.

Acceptance Criteria are very important for any user story.  It helps to avoid unexpected outcomes at the end of a development phase. It also ensures that all stakeholders are in alignment with the product functionality.

We need to mention the criteria that need to be evaluated, like functionality, UI/UX, Negative/Positive scenarios, Brand guidelines, etc.

               Let’s not mix acceptance criteria and descriptions!

 

·       Make sure that you have the headings mentioned below when you use workbook:

Epic ID, Epic Name, Actors, User Story ID, User Story, Description, Pre-condition, Acceptance Criteria, Requirement ID, Tracker ID (Story), Bug ID (one or more).

These details will help us to prepare a Traceability Matrix which is important to showcase the overall idea about requirements and the current status of the Product/Project.

·       Since most of us work in Scrum Framework, changes are always expected.  As a business analyst, we should update the user story on a regular basis. This will help the Scrum team to deliver a high-quality usable product to customers. Always get in touch with your teams in case of any requirement clarification.

 

Take Away Points

ü  Understand the Business & Business Model

ü  Try comparing with the software/product available in the market (if any)

ü  Understand the customer needs and pain points

ü  Start discussing with stakeholders on requirements

ü  Discuss your best solutions/approaches to overcome the customer pain points

ü  Document all the requirements (Functional & Non-functional)

ü  Break those requirements into small User Stories

ü  Keep your user story very simple and understandable

ü  Story grooming – Ensure the user stories are clear to the team members

ü  Help your team members at each stage, whenever they need

ü  Participate in UAT (User Acceptance Testing)

ü  Follow the best practices to ensure a smooth project development cycle