What Is User Story In Agile?

By Susan May

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 StoryWhat are Agile User Stories?‘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>” Origins of User StoriesThe 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.Why User Stories?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.Why the User Story Approach Works Well As we have seen, user stories lay out the why and what behind each task, and offer significant benefits: They help maintain focus on the user. It’s all too easy to get side-tracked while developing code, and the user story helps to keep the team focused on doing things from the user’s perspective. They enable easier collaboration. The user story clearly defines the end goals, and the team can work together to decide how best these goals can be met. Stories enable innovation. Creative, out-of-the-box thinking, and innovative solutions can be arrived at through brainstorming sessions. They drive momentum, as the team can see the progress and move toward completing tasks quickly. 3 C’s in User Stories: Card, Conversation and ConfirmationRon Jeffries, one of the three founders of XP, formulated the 3Cs of a user story: Card, Conversation and Confirmation. Card –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.Conversation –The conversation is an exchange of thoughts and feelings around the requirement, with the goal of building a shared understanding.Confirmation – 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: Identify the persona (or personas) for whom the product is being developed. For each persona, identify the features of the product. Think from the customer’s point of view. Outline the user’s journey for each persona. Use these steps to write down the user story, remembering to keep it short! User Stories and PlanningUser stories should be written at the start of the sprint before the development begins. If the user story is too large, it becomes an epic and should be broken down into smaller stories.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.Who is responsible for creating a User Story?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 (Informal)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. At a project level As a Marketing Director, I need to improve customer service So that we retain our customers. Initial User Stories (Formal)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)As an Investor, I need to see a summary of my investment accounts, So that I can decide where to focus my attention Detailing a User StoryWhile 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.The User Story Structure 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: “I” ndependent (of all others) “N” egotiable (not a specific contract for features) “V” aluable (or vertical) “E” stimable (to a good approximation) “S” mall (so as to fit within an iteration) “T” estable (in principle, even if there isn’t a test for it yet) 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 story template and examplesUser stories typically follow the following template: As a [role], I want [an action] so that [a benefit/value follows] 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. Working with user storiesRoman Pichler gives the following tips for working with user stories: Users come first: Since the user story defines the product being built, it is important that it is written from the point of view of the user. Understanding the user is very important in order to write a good user story. Creating user personas: Creating a user persona helps you empathise with the end user, understand their needs, prioritise stories and define metrics for success. Create stories collaboratively: Creating user stories is not the responsibility of any one person. Instead, it is a collaborative effort between the product owner and the development team. A user story is more of a precursor for a detailed collaborative discussion that goes on between members of the team. Simple stories: A user story by its very definition is a simple representation of what is needed. Making it confusing and filled with jargon will defeat the purpose of writing concise user stories. Start with epics: Getting a bird’s eye view of the project and requirements is the first step towards creating user stories. Also called epics, these help in defining the overall scope and functionality of the project. Refine stories till they are ready: The epics are then broken down into smaller and smaller units. These small user stories are simple, yet provide the amount of detail and clarity needed. Add conditional statements: Adding conditional statements or acceptance criteria helps to create more detailed user stories, which in turn help developers create products that are acceptable by the users. Managing User StoriesAs 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: To manage backlog To prioritise items effectively To divide epics into effective user stories To accomplish milestones Non-Functional Requirements in User StoriesEvery 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’.Lifecycle of a User StoryUser 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.How to Write User StoriesWhen 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: 1. Start with the end goal 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. 2. Retrace your steps 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. 3. Split the steps If any user story seems too big to define clearly, consider splitting it up into smaller steps. 4. Write the stories on cards 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.

Rated 4.0/5 based on 22 customer reviews

What Is User Story In Agile?

By Susan May 01st Jul, 2021

Susan May

Blog

Category: Blog
7814 843

7814 843 01st Jul, 2021

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

What are Agile User Stories?

‘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>”

Origins of User Stories

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.

Why User Stories?

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.

Why the User Story Approach Works Well

As we have seen, user stories lay out the why and what behind each task, and offer significant benefits:

They help maintain focus on the user. It’s all too easy to get side-tracked while developing code, and the user story helps to keep the team focused on doing things from the user’s perspective.
They enable easier collaboration. The user story clearly defines the end goals, and the team can work together to decide how best these goals can be met.
Stories enable innovation. Creative, out-of-the-box thinking, and innovative solutions can be arrived at through brainstorming sessions.
They drive momentum, as the team can see the progress and move toward completing tasks quickly.

3 C’s in User Stories: Card, Conversation and Confirmation

Ron Jeffries, one of the three founders of XP, formulated the 3Cs of a user story: Card, Conversation and Confirmation.

Card –

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.

Conversation –

The conversation is an exchange of thoughts and feelings around the requirement, with the goal of building a shared understanding.

Confirmation –

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:

Identify the persona (or personas) for whom the product is being developed.
For each persona, identify the features of the product. Think from the customer’s point of view.
Outline the user’s journey for each persona.
Use these steps to write down the user story, remembering to keep it short!

User Stories and Planning

User stories should be written at the start of the sprint before the development begins. If the user story is too large, it becomes an epic and should be broken down into smaller stories.

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.

Who is responsible for creating a User Story?

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 (Informal)

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.

At a project level
As a Marketing Director,
I need to improve customer service
So that we retain our customers.

Initial User Stories (Formal)

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)

As an Investor,
I need to see a summary of my investment accounts,
So that I can decide where to focus my attention

Detailing a User Story

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.

The User Story Structure

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:

“I” ndependent (of all others)
“N” egotiable (not a specific contract for features)
“V” aluable (or vertical)
“E” stimable (to a good approximation)
“S” mall (so as to fit within an iteration)
“T” estable (in principle, even if there isn’t a test for it yet)

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 story template and examples

User stories typically follow the following template:

As a [role],
I want [an action]
so that [a benefit/value follows]

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.

Working with user stories

Roman Pichler gives the following tips for working with user stories:

Users come first: Since the user story defines the product being built, it is important that it is written from the point of view of the user. Understanding the user is very important in order to write a good user story.
Creating user personas: Creating a user persona helps you empathise with the end user, understand their needs, prioritise stories and define metrics for success.
Create stories collaboratively: Creating user stories is not the responsibility of any one person. Instead, it is a collaborative effort between the product owner and the development team. A user story is more of a precursor for a detailed collaborative discussion that goes on between members of the team.
Simple stories: A user story by its very definition is a simple representation of what is needed. Making it confusing and filled with jargon will defeat the purpose of writing concise user stories.
Start with epics: Getting a bird’s eye view of the project and requirements is the first step towards creating user stories. Also called epics, these help in defining the overall scope and functionality of the project.
Refine stories till they are ready: The epics are then broken down into smaller and smaller units. These small user stories are simple, yet provide the amount of detail and clarity needed.
Add conditional statements: Adding conditional statements or acceptance criteria helps to create more detailed user stories, which in turn help developers create products that are acceptable by the users.

Managing 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:

To manage backlog
To prioritise items effectively
To divide epics into effective user stories
To accomplish milestones

Non-Functional Requirements in User Stories

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’.

Lifecycle of a User Story

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.

How to Write User Stories

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:

1. Start with the end goal

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.

2. Retrace your steps

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.

3. Split the steps

If any user story seems too big to define clearly, consider splitting it up into smaller steps.

4. Write the stories on cards

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.

Agile

Susan May

Writer, Developer, Explorer

Susan is a gamer, internet scholar and an entrepreneur, specialising in Big Data, Hadoop, Web Development and many other technologies. She is the author of several articles published on Zeolearn and KnowledgeHut blogs. She has gained a lot of experience by working as a freelancer and is now working as a trainer. As a developer, she has spoken at various international tech conferences around the globe about Big Data.