In Scrum, a user story is a short and simple description of a product feature. A stakeholder, an end user, or a team member may request a feature. In Scrum, the product is “manufactured” by developing the product features existing as user stories in the product backlog – a master list containing all functionality and features required to develop a working model of the product – through the daily product incremental cycles known as sprints.
What is user stories? In simple terms, a user story can be understood as an independent product “part” that is required to be developed by programmers or developers in the daily sprint cycle. In Scrum, the entire product is broken down into its constituent features and functionalities. Each feature or functionality is described as a user story in the product backlog. At the time of development, few user stories having high business values are taken from the top of the product backlog (the backlog has to be “groomed” or prioritized as per the business value or “market worth” of each story “contained” in it) and transferred to a “sprint backlog”. The sprint backlog is “processed” for development in the sprint cycle. Each working day, developers “work” upon a particular story and develop it using a programming language (C++, Visual Basic, etc.) or a web development platform (PHP, Java, Joomla, Ruby, etc.). Each sprint “extends” for a predetermined period. It cannot be extended. The user story has to be developed before the sprint ends. Once a story is developed, it is presented for “verification” to the product owner and stakeholders. The story is accepted as “Done” when they okay the development. Each story, when developed, results in a fully functional, bug-free, and deployable product feature. After all user stories are developed, they are “integrated” to form a working version of the final deployable product.
What to consider while writing Scrum stories
User stories are essential to Scrum and they help to organize and prioritize the development activity. Ideally, while writing Scrum stories, the fundamental Agile virtues, which are:
- Continuous delivery of product features
- Face-to-face interactions between the team and end-users
- Collaboration
Should be “utilized” to avail an “in-depth” insight as to what the feature really is, and what should it actually consist of to be useful to the end-user.
The story should focus upon:
Actor
The person or thing (noun) using the feature or service.
Narrative
What is required, or needed to be done (verb).
Goal
The outcome or result desired out of the activity.
In Agile, user stories should also include the acceptance criteria – “what” should be done, and in what “manner” – for quality assurance purposes. Each story when developed should be thoroughly tested and bug-free. In addition, stories have to be documented and should be “shippable” i.e. ready for deployment to the end user.
How to write user stories
It is not difficult to write user stories. A team member may write a user story in a number of ways, however, for the stories to be effective and usable, it is imperative they are written from the end user’s point-of-view and perspective. Scrum focuses primarily on the end user and stakeholders. Scrum events and activities are designed primarily keeping these two entities in mind. When user stories are written from the user’s point of view, they end up reflecting a true picture of what its features ideally should be from the market’s perspective. That way, stories can become more useful, effective, and possess a certain “business value”
Typically, user stories should follow a certain “format” while they are drafted:
As a [some type of user] I want [to do “something” or fulfill a certain objective] so that [something can “occur”]
For example:
As a [product promoter] I want [to upload a video from my local machine] so that [any user can view it]
From the software developer’s perspective, a user story ought to be written as:
As a [role] I want [feature] so that [goal]