WHAT IS A USER STORY?
A user story is a part of an Agile software development approach to present the details of a requirement from a customer’s point of view. A user story specifies what type of user you are, what you want and the reason behind it. A user story helps to create a simple and short description of a requirement told from the user’s perspective.
They generally follow a simple approach for a user story:
As a < type of user >, I want < a goal > so that < a reason >.
Another approach includes:
As a <user type>, I want <a goal> because <why>.
Originally, Agile user stories were meant to be very short and simple to write on sticky notes or index cards. They were fixed on tables or walls to simplify their planning and discussions. Therefore, they actively shift the target from writing about features to explaining them. In reality, these explanations are more important than the story is written. We can know them prominently in any major Agile process.
What does a user story mean? Let us try to understand with an example.
Imagine you are using an app on your phone. Now, you like the app, but you would love to have an additional feature in this app. How would you describe your wish to the developer of the app? You will say something like-
"I want to have X functionality so that I am able to get Y benefit."
While creating a user story, you write in the exact same way, the only additional information which you need to provide is about the type of user you are.
The advantages of user stories can be written at different levels in details. We can write a user story to cover a huge amount of functionalities. These large user stories are generally called ‘epics’. Let us clarify this with a few more examples-
“As a user, I can view the license terms before purchasing or subscribing so that I know what I’m getting.”
“As an app user, I can read FAQs, so I can get quick answers.”
“As a website admin, I want all the offers to get unpublished on the website after 7 days of publishing so that the expired offers are not still listed if I forget to delete them.”
In all these examples, it is clear who want the features, what they want, and what benefits they would get with the additional functionality.
WHO WRITES THE USER STORIES?
Business people are responsible for writing the user stories in a customer-specific language. We have to do this because we want user requirements to be clean and clear to both the development team and the business. The role of a development team is to satisfy the end-user acceptance criteria of the storyboard. In Scrum process, the product owner is responsible to represent the business as well as to finish the activity.
WHEN TO WRITE USER STORIES?
In an Agile project, User stories are generally written in the end. Usually, writing a user story workshop is held close to the beginning of the project in Agile. Everyone should participate in writing or adding the user stories to the product backlog at any time. If your team members are predicted to deliver the stories, then roughly we have to maintain 3 sprints of user stories in the backlog. The additional aspects of efforts and features are a superset of user stories. In these cases, the product owner team interacts with the development team to split user stories into enough levels.
Enhance your project management skills with a PRINCE2 Practitioner Certificate. Unleash your potential and begin your journey towards success today!
WHY ARE USER STORIES USED IN SOFTWARE DEVELOPMENT?
User stories are used because they provide many benefits in software development. Here are some of them.
- User stories help in delivering value to the customer.
- User stories talk about the immediate customer needs. Because of this, the features implemented and delivered to the end user is of the highest value.
- User stories enable a project to be quickly adjustable.
- Since user stories help in adding small features one by one, it becomes easier for the developing team to steer towards new direction if it is required.
- User stories increase the collaboration of end user.
Since user stories are short, the people involved in the project need more explanation from the end user to clearly understand the story. This increases user collaboration.
User stories are followed by Acceptance Criteria. Acceptance Criteria clarifies the end user that in which situations the story will be fulfilled. They are a list of requirements. They are written in "Given, When, Then" format.
Let us see an example for a clearer understanding of user stories. Suppose, there is a story for a website user which goes like this-
"As a logged out user,
I want to be able to sign in to the website,
So that I can see my previous transactions."
Now the acceptance criteria for this story can go something like this
Scenario: The registered user signs in with a valid username and password
“Given I am logged out of the website
and I am on the Sign-In page.
When I fill in the “Username” and “Password” fields with my valid credentials
and I click the Sign-In button
Then I get signed in to the website”
Acceptance criteria help create a clear understanding between the developers and the clients about when and how the features will work. The client understands what to expect from the project. And hence, the chances of miscommunication between the parties get reduced.
