User Stories – Agile
What is User Story ?
A user story is a tiny development unit that achieves a product aim. User stories are written from the user’s perspective,
Example:
“As [a user persona], I want [to perform this action] so that [I can accomplish this goal].”
Instead of features or criteria, product teams break development work into user stories.The team knows why, what, and what value they’re creating after reading a user story.
By Atlassian,
User stories are development tasks often expressed as “persona + need + purpose.”
Consider, for instance, that in order to earn benefits, I must carry out certain tasks that call on me to take particular actions.
What does the statement above actually mean?
As an [end user], I want to [exercise for two hours] at the gym every day in order [to be fit].
The goal here is to get physically fit over time, however doing so requires the user to spend a few hours at the gym.
The end user in this case could be an individual, a student, a doctor, or an IT professional.
Now that you are familiar with what a user story is, there are a few things to keep in mind when writing user stories.
A user story’s size is expressed in story points/ideal days in order to reflect its complexity or business worth.
A story must have all the features it needs.
If a story has more than one objective, it is always advisable to divide it into smaller stories.It is simpler to concentrate on smaller chunks than to be perplexed by the user story.
Every story has to meet a criterion and have a very clear purpose or advantage.
What are crucial components ?
The user story structure consists of five crucial parts that should be taken into consideration. Having these segments allows developers to have clarity on software requirements and QAs to quickly list out test scenarios.
Components of user-stories
Agile teams and relationship :
Engineering team consists of Product Owner, Developers and QA.
Product Owner:
The user story’s author is in a position to validate its success once the necessary features have been implemented.
Developers:
Developers are responsible for feature development
Quality Assurance:
Before the software is released to end users, QA is in charge of locating software defects and sending them to the developer for bug fix.
The engineering team can recognize software dependencies and risks, which helps to take respective action before the software release.
Who is responsible to write or modify user stories?
Responsibilities
User story association:
One-to-one mapping and one-to-many mapping are shown in the image below.
User story association
The bubble shows a one-to-one mapping and one-to-many stickies in green.
When user stories are created ?
Hierarchy of User Story
The below diagram states the hierarchy
Characteristics of User story
The most effective user-stories are possible using an INVEST approach.
Independent: The user stories should, to the greatest extent feasible, continue to operate independently of one another. It is better to keep user stories as self-contained as possible.
Negotiable: User stories should facilitate collaboration between customers and developers.User Story are not explicit contract
Valuable: Demonstrating how a feature adds value to the user should be an Agile user story’s top priority in order to convince stakeholders that the feature should be implemented.
Estimable: Developers need to have a thorough understanding of everything that goes into the production of a feature. Developers should be provided with user stories that are well defined and easy to comprehend so that the user stories can be broken down into individual tasks and successfully planned.
Small: User stories should not be lengthy that contain an excessive amount of information. They should be brief, to the point, and straightforward to comprehend and they should able to be completed in less than forty hours of work.
Testable: User stories need to be able to be tested so that it can be determined whether or not they are comprehensive.
Let’s not forget DEEP,
“To ensure that the product backlog is DEEP and stays that way, you have to groom or refine it regularly. Grooming the product backlog is an ongoing, collaborative process that involves the product owner and team.”
– Roman Pichler, co-creator, DEEP backlog approach
Detailed in a sufficient manner: Each item in the backlog should include pertinent and detailed information for the cross-functional team.
Emergent: The product backlog is constantly changing, and new stories may be added or deleted depending on the new information that is obtained.
Estimation: it is necessary to formulate an estimate for the amount of time necessary to accomplish each upcoming task.
Prioritization: Items are prioritized according to their value as well as the strategic objectives that they serve in order to determine their order of importance. A high priority corresponds to a great value.
Please share your ideas on user stories with me; I’d like to learn from you as well.
Thank you for reading my article.Please applaud as many times as you can if you enjoyed my article. It enables me to continue creating fantastic material and helps me get this content out there.
