User Stories in Agile and Scrum

What is a User Story in Agile and Scrum?

User story basically encompasses the requirements of the business and instructs the software building teams as to what needs to be created. Simply it is a means to express ‘Stakeholder requirements’. Software building team encompassing developers and testers communicate with the product owner or the key stakeholders to understand what a customer exactly wants. 

In today’s progressive era of cut-throat competition, every organization thrives to organize their work in a way that may follow certain values and principles. For these organizations, customer satisfaction is of utmost importance and holds highest priority. In IT world, companies measure their progress through continuous and early delivery of working software. It is very difficult and important for the organizations to keep a track of all the work which might or might not have been completed. Hence, work is broken, organized and chunked into units. 

In simpler words, these units basically represent work, broken into fragments or parts which are then imparted priority. Some fragment of this work may hold higher priority and value over other fragment.

Imparting priority can also be one of the challenging jobs as sometimes the customers might not know themselves what they want and hence get confused over the kind of product they envision and desire and hence proper communication between the two parties is very important . For those closely associated with IT business, will understand this dilemma of communication very well. It is important to strike a right chord so as to maintain fine balance between the business and software building team so that no single party overpowers the other. Hence, decisions are made based on the information provided and these decisions are made quite often. Work is not taken all at once but divided into fragments. This work fragment is called a USER STORY. To sum up, a user story is requirement for a feature written in maximum 5 lines. The concept of user story was evolved from Extreme Programming. The term ‘requirement’ has different name in different types of project. In ‘agile’ project, it is referred to as ‘epic’ or Agile user story. Team should not get confused by the use of user stories and epics. Word ’epic’ which simply means ‘A large user story’. This epic then goes on to be broken down into smaller fragments or pieces called as user story. 

User story works well for both traditional and agile projects. Now, a novice may ask the effectiveness of a user story as whatever a user story does can be done in exactly the same manner with the help of a normal cue card which in turn is easier to use and can be well understood by everyone  starting from business to developers /testers, so now the question arises: 

Certified Scrum

Master Course

Get Certification on 2nd Day

View course

Why to Write or Create User Stories?

Simple answer to this question lies in the fact that user stories go end-to-end vis-à-vis have all the sections covered in it starting from UI design to business logic to database structure. These components do not have any value by themselves as they cannot be deployed independently but combination of all these components does the trick. Now having understood the basics of user story and why it is necessary at all to write/create a user story, there would be few more questions that would arise with the origin of user stories. Let us try and take up few more questions in this context to understand user stories more accurately.

Structure of Agile User Story or

The structure of the user story that is widely used in industry these days is:

AS A  role the author represents,

I/WE  can do or have something

With these qualities

TO achieve my goal or objective 

Now even though the structure stated above is predominantly used to write a user story, any method that expresses STAKEHOLDER REQUIREMENT, does not creates confusion, is agreed upon in the organization and is crisp and clear can be used to serve the purpose. 

For the developers and testers to ensure that what they worked on is exactly what business wanted,   the concept of ACCEPTANCE CRITERIA comes into picture. Acceptance Criteria is a set of accepted conditions which the functionality should satisfy in order to be accepted by stakeholders. Missing any of the acceptance criteria can induce lot of cost as it defines the ‘definition of done’. The structure of acceptance criteria is as follows:

<<Given a precondition when we perform an action then result is expected>>

So now, the structure of Agile user story will look something like the below mentioned:

AS A  role the author represents,

I/WE  can do or have something

With these qualities

TO achieve my goal or objective 

Acceptance Criteria (AC):

<<Acceptance Criteria 1 >>

<<Acceptance Criteria 2>> and so on..

The overall structure looks like:

Product backlog is a collection of user stories. Epic is a big user story.  Epics are then broken down into user stories. Multiple epics can be present in one product backlog.

Examples of user story and acceptance criteria  

Let us go through few user stories examples to see how a user story prototype may actually look like:

1). <<As a travel user, I want to

     Cancel a reservation>>

     Acceptance Criteria: Verify on cancellation an email is sent to the travel user’s registered id.

                                            Verify that the travel user gets 100% refund if reservation is cancelled within 10 hrs.

2). <<As a vacation traveler, I want to

      See photos of the hotels >>

      Acceptance Criteria: Verify two types of photos are displayed, one from travelers and other from hotel staff.

3). <<As a website user, I want to

     Reserve a hotel room>>

     Acceptance Criteria:  Verify that all categories of hotel rooms are displayed simultaneously.

One single requirement for example : ‘a hotel website’s landing or first page’ can have multiple user stories as mentioned above dealing with different smaller functionality that the customer may want to implement as part of the larger implementation. Hotel website’s landing or first page can be treated as a epic which can then be further iterated

Who has to write a user story?

The user stories are written by Product owner who also has the responsibility of prioritizing the stories. The Business Analyst then reviews the story and the acceptance criteria and then these stories are taken up and discussed in brainstorming sessions. These brainstorming sessions where user stories are planned and refined are called Planning and Refinement sessions.

How to write a user story?

A good user story should basically follow the terminology: ’INVEST’ wherein an ideal story should have the following characteristics: 

-A user story Agile should be independent, 

-It should be negotiable,

-Should be deemed valuable by customer,

-Must be estimable so that it can be sized easily, 

-Should be small as smaller size can help in better planning and prioritizing. The stories should be simple with more emphasis on business logic rather than being complex which increases misunderstandings.

-Should be testable.

The first and foremost step here is to gather the scrum user-stories which can be done through various techniques that include use of flowcharts to extract stories. Multiple story gathering workshops can be set where customers give their requirements. Mockups are also used for extracting a story. There could be system maps, process flows, scenarios, concept designs which could help in extracting a good user story.

Effective ways to write a user story also includes face-to-face communication and planning. Based on latest learnings and team based collaboration and innovation in the planning sessions, effective user stories can be created. This communication removes false sense of accuracy and also infuses confidence in the business/stakeholder about the end product. Customer here can provide feedback and in turn developers and testers can proactively react to the needs of the customer.    

How user stories are used in agile project?

User stories in agile project should be short and should be clear to business as well as development team so as to satisfy the client requirements. Developers closely communicate with business so as to develop a product based precisely on the instructions given and desired by the business team.

Certified Scrum

Master Course

100% Success Rate

View course

 

Conclusion:

To conclude, user stories scrum are created to ease the understanding of business requirements for both business and development teams. Understanding of user story and acceptance criteria is only possible by immense brainstorming and spending lot of time by deeply studying it.  Gradually with experience and gained knowledge, the understanding of the product becomes more logical and clear. Advice to all members of the business and development team is to initially spend time during planning and refinement meeting so as to get proper and absolutely clear understanding of the stakeholder requirement. Everybody has to be sure to be on the same page about user stories and their acceptance criteria along with the definition of done. There should be immense amount of communication between BA’s , PO’s and development team.