Scrum - User Stories
As you have understood, the User Stories are commonly used to describe the product features and will form part of the Scrum Artifacts – Product Backlog and Sprint Backlog.
User Stories
In software development, the product features play a crucial role. It is the features that the user ultimately likes to use in the final product. They are known as Requirements in the general terminology. The software development project success lies in understanding the user requirements accurately and appropriately, and then implementing them in the final product. Thus, requirements or product features need to be thoroughly known to the development project team.
In 1999, Kent Beck came up with a term User Stories for the product features. He described that a User Story is narrated from user perspective regarding what he or she wants to have rather that what system can do for him. Thus, the view changed from product to user completely and User Stories became de facto standard for Requirements in all Agile frameworks.
In Scrum projects, the Product Backlog is a list of user stories. These User Stories are prioritized and taken into the Sprint Backlog in the Sprint Planning Meeting.
Estimation is also based on user stories and the size of the product is estimated in User Story Points.
The User Story Structure
The User Story structure is as follows -
As a <Type of User>,
I want <To Perform Some Task>,
So that <I can achieve some goal/benefit/value>.
Let us take a look at how a user story is framed for the scenario of a Bank Customer withdrawing cash from ATM.
User Story: Customer’s Cash Withdrawal
As a Customer,
I want to withdraw cash from an ATM,
So that I don't have to wait in line at the Bank
User Story Acceptance Criteria
Each User Story also has Acceptance Criterion defined, so that correctness of implementation of the user story is confirmed by passing the Acceptance Test that is based on the Acceptance Criterion.
Following are the sample acceptance criterion for the example of User Story Customer’s Withdrawal of Cash.
Acceptance Criterion 1:
Given that the account is creditworthy
- And the card is valid
- And the dispenser contains cash,
When the customer requests the cash
Then ensure the account is debited
- And ensure cash is dispensed
- And ensure the card is returned.
Acceptance Criterion 2:
Given that the account is overdrawn
When the customer requests the cash
Then ensure the rejection message is displayed
- And ensure cash is not dispensed
- And ensure the card is returned.
Writing User Stories
Product Owner is responsible for the Product Backlog and thus for the User Stories. However, it does not mean that only product owner writes the user stories. Anyone in the Scrum Team can write the user stories, and the activity can be spread across the project as requirements get refined and new functionalities get added.
Non-Functional Requirements in User Stories
It is possible to incorporate the non-functional requirements also in the user stories. In the given ATM example, the ATM to be available to the user 24X7, 365 days is a non-functional requirement, which can be described by a use case.
Managing User Stories
User Stories are managed in the Product Backlog. The User Stories are ordered according to priority. The most prioritized user stories are refined to granular level, while the least priority user stories are kept at a lesser detail level. For every sprint, the most prioritized and hence more granulated user stories are taken into the sprint backlog. If a user story is to be added to the product backlog, its priority is first determined, and it is placed according to its place as per the priority. The user stories can be reprioritized at any time. It is also possible to remove any of the user stories if required.
Benefits with User Stories
The major benefit of User Story lies in the user centric definition itself. This is because, ultimately, it is the user who will be using the product in the relevant user scenarios. It connects the end users to the team members.
The syntax of the User Story itself ensures to capture the goal or benefit or value that the user wants to achieve.
Since the acceptance criteria forms part of user story itself, it will be an added advantage to the Scrum Team.
It is possible to make changes to a user story in course of the execution of the project. If the scope of the user story becomes large, it needs to be split into smaller user stories. The conditions in the acceptance criterion can also be changed.
As working product increments are delivered to the users at the end of each sprint, the scrum team can get feedback from the users in sprint review meeting. This enables incorporation of feedback into the product continuously.
Conclusion
Scrum's User Stories bring the users closer to the Scrum team and prevents last-minute surprises.
