Agile projects make progress by shipping user stories.
User stories are to agile methodologies as requirements are to waterfall methodologies. In simple words a user story is an all-inclusive statement that describes the desired outcome of the application from a customer point of view and how a feature will be implemented.
Read this article to learn everything there is to learn about agile user stories.
Definition of a user story
User stories are informal and conversational style explanations used to capture the feature requirements. The purpose of user stories in scrum is to clearly communicate to the engineering team the behavior of the feature from customer perspective.
Kent Beck invented user stories for Extreme Programming (XP) agile methodology.
Format of a user story
“As a <user>, I want <feature>, so that <feature benefit>”
There are three sections in a user story.
User: The persona who needs this feature and who will benefit from this feature. Eg: If your product has an admin login and a customer login, you will have two types of users.
A feature: A feature that should be added to the product
Benefit: Describes why the users want this feature.
What are good user stories
According to Bill Wake of agile alliance, a good user story follows the INVEST Model. The stories are
Independent of each other from a development perspective.
The development team can negotiate how the story can be implemented.
The story adds value to the customer.
The effort for implementing the story can be estimated.
They are small and take a few hours to a maximum of a couple of days in the worst case.
They can be tested and passed.
Examples of some user stories
Here are a few examples from different industries.
Payments Industry: As a merchant, I want to be notified of disputes through email, so that I can take corrective action and avoid chargeback.
Transport: As a customer, I want to receive a PDF invoice at the end of my trip, so that I can use it to claim reimbursement.
Where do user stories come from
Product team is responsible for creating and maintaining user stories.
But how does the product team even know what features to be built down the road? One of the main responsibilities of the product team is to spend time with customers or sales teams to understand the customers problems and feedback.
Modern product lead growth companies also resort to tools like www.prodroll.com to get 10x more feedback from customers.
This feedback is carefully analyzed and the product team will take a call on what features need to be built next.
In a scrum team, the person handling the product owner role is responsible for user stories.
Acceptance criteria for user story
A user story is not complete without its acceptance criteria. Acceptance criteria clearly lays out the scenarios that the software should handle for the user story to be “completed”.
One single user story can have multiple acceptance criteria.
A generally used format for writing an acceptance criteria is Given-when-then format. This comes from behavior driven development (BDD) way of testing.
Example:
Scenario: The customer has logged in.
Given the I have logged in,
When I go to the dashboard,
I should have an opinion to submit a new feature request.
When are user stories written in agile
When a product owner starts writing a story, the acceptance criteria, the details of various tasks and subtasks may not be available. It is also not recommended that the product owner put all the details in advance.
Authoring user stories and creating tasks/subtasks is a collaborative effort from the product and the engineering teams. But the ownership of the process lies with the product owners. They need not literally author the stories themselves. They can also simply enable the engineering team to break down tickets or write acceptance criteria.
In scrum methodology, maximum time and effort must be spent on hashing out those stories that will enter the sprint backlog from the product backlog. This can be done either during the backlog grooming sessions or in the sprint planning meetings. But user stories with acceptance criteria must be well documented and understood by the engineering team before the sprint starts.
How much detail should a user story have
It depends! The answer to this question varies from team to team. If you are managing a mature product with a well settled team, your stories need not be detailed.
On the other hand, if you are managing a complex product or a brand new engineering team, product owners need to collaborate more with the engineering team to hash out the details and document them.
Where are user stories written
User stories, acceptance criteria, tasks and sub-tasks are generally captured in an issue tracking tool like JIRA or Asana. These issues are further tracked in agile PRDs , usually in a table format, so that the overall progress of the feature or the initiative can be tracked separately.
How are user stories organized
With issue tracking tools like JIRA, you can use hierarchy to organize your features.
A large feature can be an EPIC.
A epic will have multiple user stories.
User stories can have multiple tasks
A task can have multiple sub-tasks.
If a user story is simple and straightforward, you may not need an epic/task/sub-task. User story, task and subtasks must be completed in one sprint. But an EPIC can span one to several sprints. An EPIC will also have several user stories.
User stories and story points
A user story in agile is sized through story points. Story points are assigned in the sprint planning meetings by playing planning poker with developers.
Fibonacci sequence (1, 2, 3, 5, 8, 13, …) is pretty common while assigning story points to account for unknowns. If a story is too big (say engineers decide to assign 21 story points or more), the story should be broken down further.
A tiny user story might have a story point of 1 and might take 1 hour to complete. A large story will have 21 story points and might take 3 days to complete.
Why story points and not hours? Story points are supposed to capture the complexity of implementing the story and not the effort required. Eg: Integration with a third party API with outdated documentation has more complexity compared to writing a couple of dashboard endpoints for your own application.
The purpose of story points is to help the product teams do capacity and release planning. Over the course of a few sprints the product owner will know the “average” number of story points that the team can deliver in a sprint. This average is called “team velocity”. This velocity is used to project when the upcoming features will be completed or whether to increase the velocity by adding more engineers.
Conclusion
Product matures with implementation of user stories with every iteration.
A well written user story can be estimated, developed and tested independently.
Product owners should spend more time on stories that are about to enter the sprint backlog. Before the sprint starts, the user stories (and breakdown into tasks/subtasks), the acceptance criteria, and the story points should be finalized.
