In Agile projects, the end requirements are not set in stone—they keep evolving, which makes the process of gathering clear requirements a challenge, to say the least. This is where user stories play an important role. A critical component in the Agile software development approach, a user story is a simple, yet powerful construct used to elicit the details of a requirement from an end-user's point of view.
In this blog, we will help you understand what a user story is, how to write a good user story, the characteristics of a well written user story and the advantages of following this approach for requirement gathering.
Source Link: User Story
‘User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.’ – Mike Cohn, Mountain Goat Software
While they are very simple (who doesn’t love a good story!) user stories are very effective. They describe bits of functionality from the end-user’s perspective, in clear and concise terms. They take into consideration what exactly the user needs, and the value that can be gained from this.
The format is short and to the point, and typically reads:
“As a <type of user>, I want <goal> so that <reason>”
The first reference to a user story was made in 1998 when Alistair Cockburn, one of the signatories for the Manifesto for Agile Software development, coined the phrase "A user story is a promise for a conversation.” User Stories had their origins in Extreme Programming (XP), and in 1999 Kent Beck, another of the 17 software engineers who co-created the Agile Manifesto, introduced the usage of user stories in planning in his book Extreme Programming Explained.
The best way to build software that meets users' needs is to begin with user stories: simple, clear, brief descriptions of functionality that will be valuable to real users--User Stories Applied, Mike Cohn
Especially when requirements keep changing, a user story is a great way to define the goals with clarity. The functionality of the product can be easily articulated and documented to avoid any ambiguity. User stories are written in plain, simple English, with no technicalities, so that they are easily understood by all.
This approach facilitates very meaningful product discussions between team members as well as stakeholders, that can result in well fleshed out product features. When there is a conversation around each story, all doubts can be cleared and there is a proper basis for communication and collaboration—resulting in products that offer genuine value to users.
As we have seen, user stories lay out the why and what behind each task, and offer significant benefits:
User stories are written on cards and comprise a short-written description of the story. The idea of using cards is so that there is just enough text to identify the description, and it does not become a rambling detailed outline.
The conversation is an exchange of thoughts and feelings around the requirement, with the goal of building a shared understanding.
There should be an agreement on what to build, and a definition of the acceptance criteria for the story that are recorded as a set of confirmation tests.
Identifying a User Story
The process of identifying a user story can be broken down into 4 simple steps:
User stories are crucial for managing work in progress and to better plan sprints which is why they should be planned before development begins. Every user story should be able to define how the software feature to be developed will deliver value to the end-user.
A user story is not a large body of work but a short description with very few details. As the development progresses, requirements may be added to it.
User stories can be written by anyone on the team. Although the Product Owner is responsible for making sure that the product backlog always has user stories for the team to work on, the actual writing of the user story can be taken up by anyone who is conversant with the task at hand.
A good agile project starts off with a user story writing workshop in which all team members participate and decide what functionalities would be incorporated into the product being developed. Usually, during the project, every team member contributes to the product backlog by adding user story examples to it.
Initial User stories that are informal or of high level are also called epics and give a birds-eye view of the requirements. These high-level user stories are broken down into more detailed user stories that are then picked up for sprints by the development team.
Formal user stories are more detailed user stories. They are created when informal or high-level user stories are broken down to more detailed stories. Even though they are more detailed than the high-level stories, they are not intended to provide complete specifications of the requirements. They are written to capture the value and features of the requirements to be built.
Example: (Source: agilebusiness)
While the user story starts as a short simple description in just a couple of sentences, more detail may be added later. If more details make the story too long, then it may have to be split into smaller agile stories.
A user story can also be made more detailed by adding certain ‘acceptance criteria’. These describe the conditions that are satisfied once the user story gets completed.
Different teams may have different ways of writing user stories. Most agile user stories follow INVEST to create their user stories.
A good user story should be:
Source: Agile Alliance
A user story, as mentioned above is a short description of user needs or the functionality that needs to be delivered. Since it is told from the perspective of the user, it has to define an end user also called a persona. It should also specify the tasks to be performed and the expected end goal. Some user stories also have the acceptance criteria mentioned, which is a good way to determine if the user story meets the definition of done.
User stories typically follow the following template:
As a Gmail user, I can forward messages with a specific subject line to an alternative email id, so that my inbox isn't filled up with things I don't need saved.
As Alice, I want to create a To-do list, so I can schedule my week.
Templates are generally a good starting point for teams new at agile. Following the format makes sure they do not miss out essential points including the end deliverable and who it is for.
Roman Pichler gives the following tips for working with user stories:
As the project progresses and more and more user stories are added to the product backlog, organizing the backlog items can become a nightmare. User stories need to be managed efficiently so that product releases can be accomplished without compromising on quality or time frames.
Managing user stories will help:
Every product may have certain non-functional requirements, which are defined as a system’s attributes that enhance the system’s functionality such as scalability, security, performance etc. By their very definition, non-functional requirements are not functional and are very different from functional requirements that directly affect the user.
These non-functional requirements are still an indispensable part of the product and cannot be ignored. Whether they are added to the user stories or not depends on team preferences. Many product owners prefer to add them as separate backlog items, which are developed and tested before the item is ‘done’.
User stories are identified and outlined in a story writing workshop that is held at the beginning of the project. This is a session where the team gets together to brainstorm as many user stories as possible, given the requirements at hand. During this session, each story is estimated, and priorities are set. This prioritized list is the Product backlog. The team estimates the time they would take for each user story, and the rate at which they can complete the user stories (the velocity). This is required to plan schedules.
Next, when the team sits for the iteration planning process, the user stories that have been listed out in the product backlog are allocated to different sprints. At this event, the user stories that will be done in the first sprint are prioritized into a sprint backlog.
During the iteration, each user story is discussed between members of the agile team. They flesh out the details and write down acceptance tests to confirm completion of each story. These user stories can be updated to keep up with emerging requirements, till the end of the sprint.
If the user story is left incomplete during the sprint, it gets added to the next sprint backlog and is taken up during the next iteration.
When projects are large, starting out with small user stories can seem like a daunting task—but going from macro to micro is the key. It’s important to understand that user stories are what will define the day-to-day tasks and functionalities.
Starting off with an epic, which is the macro and then breaking it down into smaller user stories helps teams assimilate the work that needs to get done.
Stories should be put out there for everyone to see and refer to. They can be written down on cards and pinned up on boards which the whole team can see. This also fosters communication, transparency and more collaboration between team members.
Ready to write your first user story? Here’s how to break it down into steps:
It could be difficult to figure out what the first step should be, and it’s often easier to start at the very end. What are you trying to achieve, and for whom are you creating the product? Once the persona and the end goal or values are clearly articulated, then you can define the solution more easily.
Keeping the persona and the end goal in mind, you can retrace the steps needed to achieve that goal. Work backwards and write down all the steps needed to get to the very beginning.
If any user story seems too big to define clearly, consider splitting it up into smaller steps.
Once you have sufficient detail and clarity on each user story, write it down on a card. Each step will make up one user story, and it can be laid out in the simplest language possible. These cards can be moved around on a table when you are prioritizing tasks, and they can be given out to the team member who is working on them.
A Last Word
The beauty of Scrum and Agile projects is that they are simple—not just in terms of processes but because of their underlying philosophy which is ‘do fast, fail fast, learn fast and succeed’.
While writing a user story may seem like a simple exercise, it is a very significant one that yields great results. User stories keep the focus on the end user, give clarity on features, promote collaboration and communication and help to create high-value products that create customer delight.