User Story in Agile: What are User Stories?

A core element of agile software development is making the users and customers the focus and user stories contribute to doing exactly that. They put the end-users at the center of the conversation. In, this article let’s discuss of a user story in agile.

Stories make the use of non-technical language in order to provide conditions for the development team and their efforts. The user story helps the team to understand their own goal, why they are building it. Also what they are building and the value that it creates at the end and along the way. Thus, user stories are one of the vital components of an agile program. They facilitate creativity, progress, and a better end product by giving the team a user-focused framework for their daily tasks. All agile stories focus on the requirements and help to create conversations through one or two sentences about the desired functionality.

The topics discussed in this article are:

• What are the user stories?
• Who is responsible for writing a user story?
• When to write user stories?
• Why create user stories?
• Working with user stories

What are User Stories?

User stories are simple and short descriptions of a feature by a user or customer of the system. They follow a common template:

As a <type of user>, I want <some goal> so that <some reason>.

Let’s get to know more about user stories.

• Usually, user stories are written on sticky notes and index cards. Then they are arranged on tables or walls for the purpose of planning and discussion, hence conversations are created around them.
• User stories, which are discussions revolving around and with the help of the user stories are very important and shift the focus from writing about features to actually discussing them.
• They are always expressed from the user’s perspective and does not classify as a feature. A user story is the tiniest part of an agile framework system.
• The main objective of a user story is to express and put across how a particular piece of work will deliver value to the user or customer. It is important to note that customers do not have to necessarily be external end-users, but can also be colleagues in your team or within your organization.
• User stories do not venture into details and consist of simple and few sentences.

User Stories in Scrum and Kanban

Both Scrum and Kanban use user stories in their frameworks. In Scrum, user stories are an addition to sprints and are used over the course of the sprint. In KanBan, teams add the user stories into their backlog and use them through their workflow. Thus they help in the better estimation, sprint planning, better accuracy at forecasting and greater agility in the Scrum team. On the other hand, KanBan teams can deal better with work in progress and improve their workflows through user stories.

Larger agile frameworks like epics and initiatives constitute of user stories. Epics are larger workpieces that are broken down into many stories and initiatives comprise of many epics.

There are two ways of adding details to user stories:

• By splitting the user story into smaller multiple stories.
• By adding conditions of satisfaction.

A condition of satisfaction refers to a high-level acceptance test that renders itself true once the agile user story is completed.

Who is responsible for writing the user story?

There is no set rule regarding who can write the user stories. The product owner has to ensure that the product backlog of user stories is in place but he does not necessarily have to write them. Ideally, a good agile project will have user stories written by each team member and more importance would be given to the team members being equally involved in the discussions after writing the user stories.

When to write user stories?

User stories are conceived throughout the agile project. A story writing workshop is usually conducted at the beginning of the agile project so that every team member can participate and potentially help to create a product backlog describing the desired functionality and end goal which can then be added to the project. Some of the user stories will end up turning into epics. In addition, these epics will later be broken down into multiple smaller stories which will fit better into an iteration. New stories can also be added from time to time to the product backlog according to requirements.

Why create user stories?

A User Story in Agile can seem like an additional step in the agile framework process but they provide important and valuable insight to the team and enlighten the tea about the value that their tasks bring to the project. User stories provide a number of benefits and advantages:

• • Foster user focus – A to-do list usually keeps the team on their toes with the tasks that need to be done and checked off the list whereas user stories put the entire focus on the users and help in solving their problems as they are written from the user’s perspective.
  • Enable collaboration – When the end goal is clear and defined for the team, they can work together efficiently to meet that goal as well as provide satisfaction and good service to the user.
  • Drive creativity – The process of writing and discussing user stories involves discussions and brainstorming which helps the team think critically as well as creatively as well as possibly come up with solutions to meet the end goal.
  • Provide momentum – Each story provides momentum to the development team through challenges and progress.

Working with user stories

1. A user story is conceptualized and written, then it is absorbed and implemented into the workflow. Usually, product owners, product managers or the program managers write user stories. Then they submit them for a review.
2. During a sprint or iteration planning meeting, the team makes a decision regarding what stories will be included during that particular sprint. Additionally, teams discuss the functionality and requirements of the story. Requirements can be added to the story after they are agreed upon by the team.
3. An important step in this meeting is to assess the stories based on their complexity and time of completion. A story should be able to be completed in one sprint. For this reason, the team needs to discuss the stories.

User stories throw light on the day to day workings of the development team as well as explain the processes followed by the team every day. The best way to exploit them in your project to uncover its benefits is to understand their role and contribution to the team’s work and delivery.

That’s it, folks! With this, we have reached the end of the ‘User Story in Agile’ article. You could also take a look at Scrum Master Interview Questions while you’re at it.

Got a question for us? Please mention it in the comments section of this article and we will get back to you as soon as possible.