Feb 04, 2020 
9.3k
22
NovBlack Friday Deal : Up to 40% OFF! + 2 free self-paced courses + Free Ebook - SCHEDULE CALL
One of the most important factors and challenges which is there for any business analyst is to write good stories. And obviously, that’s one of the primary jobs of an analyst. It would be very exciting to see how little details and being critical can bring a huge change in the quality of the user story. Let’s see what’s store for you guys as part of this blog -
Thinking about user stories in an agile environment, we always think about some requirements that need to be coded, tested and successfully deployed. But is that only what user story means.
No, User Story is much above that. In software and product development lifecycle, the user story is the feature that a product needs to satisfy its users and add business value to the product. A key aspect in agile used by business analysts checks on the demands of actual end-users and put it in a story writing format.
The value any user story in general holds is how a piece of work will benefit the customers. Sometimes, customers need not be any external customers but any internal team who are dependent on your team. Whenever any analyst gets a requirement, he/she lists down all kinds of dependencies to make that feature successful. In such cases, there might be dependencies on the cross-functional team, where a user story is written for them with what work is expected to be done.
They are a natural description of a feature that helps to move the focus from just writing the requirements to having a discussion about them. With the dynamic approach in which industry is moving today, there are too many changes which pop in and the team needs to accommodate that. Thus, in this case, it is very difficult to track every change in an old school documentation format. Here user stories come as a savior, where each change can be a separate story and should be linked to the initial epic which has been opened.
User Stories help to answer some of the important questions even before they are asked by the development and testing team. And That's the reason this concept has been very successful even with various geographical locations of teams. Let’s see the insights any user story throws –
Hierarchy behind User Story -
Such a powerful process that expresses the exact expected appearance of a product must definitely be bound by some important elements around it.
Any User Story revolves around four elements –
Now the above elements would surely be giving you how a user story is different from a plane requirement. Any project can be developed with the list of requirements documented in excel or a word, but the user story gives a formulated approach. The way it is divided into the steps and the reason these steps justify make them satisfying for all stakeholders to take it and take necessary actions to achieve the demanded goal.
Any story captures these three details which add more worth to it –
They also include –
Read: Agile Methodology - Guide To Agile Method & Scrum
Check out some examples based on the template for user story –
As a booking customer, I would like to see all my bookings in My Booking Tab, so that I have all data in one place.
As a paid user, I would like to have the receipt of my payments, so that I am aware of my transactions.
Most generic template for a user story
The art of writing a good user story!!
For any organization and analyst working with them, there comes a question as to how to write a good user story. Adding details in a user story is not that easy it is to be done in structured format, but with time, domain knowledge and experience it becomes pretty smooth to handle it.
By now in this blog, you might have already got a fair idea about user stores, its template and the worthy elements it comprises.The below details would throw some light on how to make it more worthy.
The first method checks if the user story is mapped as per the INVEST model.
INDEPENDENT –
Now in any organization, it is not easy to make user stories independent always. There are multiple products and features, and they are dependent on each other. A good story should be independent, as it makes it simpler in the delegation of work.
NEGOTIABLE
Our industry survives on negotiations, and so does our user story should be. Even during its progress phase, anyone from the team should be able to add details to it, obviously by discussions with BA.
Read: How To Choose The Appropriate Business Analyst Certifications?
VALUABLE
We have been talking about this term from the start of this blog. A user story that does not do any worth to the organization should not be even thought through.
ESTIMABLE
Any user story should have the capacity to be estimated by the team. It depends on its complexity, the strength of the systems, the data it is going to impact, etc. This helps to work better on the development.
SMALL
Never try to push all the details to one single story. Try to break them as small as possible so that it is easy to implement. A complex and large story can be accomplished in phases by dividing the details into multiple user stories.
TESTABLE
Whenever we do something as part of the development lifecycle, it has its own benefits. So, any story which is written for the same should be testable and pass the quality check for the flawless behavior.
Another important factor to keep in mind is “Acceptance Criteria” which makes the story much more suitable as per the requirement. It gives the sense that if a certain list of conditions gets fulfilled as part of this requirement, then only this particular story is done. These criteria are written keeping users in mind and should be tested on their own.
A good user story always starts with epic, so that they have a valid association and they do not hang around separately. In such cases, it becomes challenging for business analysts to explain any such circumstances.
Don’t make the story-heavy with too much-written details. It is always advisable to add something that hits the visualization of the team as wireframes, mock-up screens, database design, any other discussion documents, process flow diagrams, etc.
Business Analyst Training & Certification
Read: What does a Business Analyst do? The Key Roles & Responsibilities
After talking so much on a user story, a question arises which place to write these stories. Well, the answer is straight that agile has given some powerful tools for its multiple implementations.
Two significant tools are JIRA and Rally.
JIRA is the tool given by Atlassian, for bug tracking and agile project management. And so it gives space to write down user stories as well with numerous configuration tabs. The Epic has the link to create the user story and hence it is always attached to it creating a mapping scenario.
It has the option of creat issue, where issue can be a requirement, new feature, bug, task or a story. Depending upon the type of issue, there are multiple fields which get opened as part of the configuration.
Example - While creating a story in JIRA, there should always be an EPIC for it. Click on create issues and select story/user story as the issue type. Then the user needs to enter a summary, selects its priority, select the assignee, the respective tester, the environment which would get impacted, components (mostly it gives a view of the project), description (here an analyst write the acceptance criteria and details in user story template), labels, attachment (if needed like wireframes, design document), and epic link. You can also click on Configure Fields in case any field needs to be added or removed.
Learn Business Analyst in the Easiest Way
Rally is quite comprehensive tools in the agile world. It is a more kind of iterative tracking tool that can dig deep into multiple user stories. This gives a flow to track teams’ progress and has a tremendous scaling property. Companies that only follow agile prefer rally, but because of some much dynamic aspect in software development, JIRA gets a better place in the market. But yes both the platforms offer the complete cycle of plan, develop, test, release, deploy and plan back.
A look on the fields in JIRA for creating any issue
Conclusion
When it’s about agile, it is all about being dynamic and to be open for any change. In the world of business analyst, a good user story shows the virtue of the analysis and requirements. And, yes agile totally support it because of its flow and configuration aspect. I hope you will be able to write wonderful and meaningful stories for your requirements. Have a great time and keep learning !!
FaceBook
Twitter
LinkedIn
Pinterest
Email
I believe in knowledge sharing and bringing change in people's lives. As a business analyst by profession, I love to explore everything about the way businesses should drive. I keep in touch with the latest business analysis updates.
Cyber Security
QA
Salesforce
Business Analyst
MS SQL Server
Data Science
DevOps
Hadoop
Python
Artificial Intelligence
Machine Learning
Tableau
Search Posts
Related Posts
Receive Latest Materials and Offers on Business Analyst Course
Interviews
Aug 06, 2024
628.6k
628.6k