Scrum Bootcamp: Learn the Basics of Scrum Programming (2016)

Chapter 5. The User Stories

In the“software development” industry, product features serve important roles. These features attract consumers and encourage them to purchase or use the completed product. In general terminology, product features are called“requirements.” The success of a software generation project depends on knowing the users’ needs precisely and incorporating them into the finished product. That means that the team members should know the requirements or product features that they need to work on before starting any project.

Kent Beck, an American software engineer, coined the term“User Stories” back in 1999. A user story, which is narrated from the user’s point of view, informs software developers regarding the needs of the end-user instead of what the product can do for him/her. The development perspective changed from being“product-focused” to“user-focused.” Because of their effectiveness, user stories became standard requirements for teams that use any“Agile” framework.

When it comes to the Scrum framework, project backlogs serve as a collection of user stories. The ScrumMaster must identify, prioritize and discuss these user stories during the sprint planning stage.

In most cases, Scrum teams base their estimations and goals on the user stories of the project.

The Structure of a User Story

User Stories follow this format:

As a <kind of user>,

I need to <complete a task>,

So I can <attain a goal/enjoy a benefit/receive something.>

Let’s analyze how user stories are formed. Here, let’s assume that a bank client wants to withdraw money from an ATM.

User Story– Client’s ATM Withdrawal

As a Client, I need to withdraw money from an ATM, so I can get the cash I need without going inside the bank.

The Acceptance Criteria

User stories involve acceptance criteria (i.e. tests that gauge the effectiveness of a user story). The acceptance criteria helps Scrum teams in analyzing the effects of the user story/stories on the current project.

Here’s a simple acceptance criteria for the user story given above:

First Acceptance Criterion:

Given Information:

· The client is creditworthy.

· The debit/credit card is acceptable.

· The machine has enough cash.

Situation:

· The client needs the money.

Then:

· Make sure that the proper account is charged.

· Make sure that the machine dispenses the right amount.

· Make sure that the machine returns the client’s debit/credit card.

Second Acceptance Criterion:

Given Information:

· The client’s account doesn’t have enough funds.

· The client’s card is acceptable.

Situation:

· The client needs the money

Then:

· Display a rejection message on the screen.

· Make sure that machine doesn’t dispense any money.

· Make sure that the machine returns the card.

How to Write a User Story

Since the project backlog holds the user stories, the product owner is responsible for managing the project’s user stories. However, the product owner isn’t the only person who can write a user story. Basically, any team member can accomplish this task. That means the ScrumMaster may spread this responsibility across the entire team.

The Non-Functional Requirements in a User Story

Scrum teams may incorporate non-functional requirements into a user story. In the example given above, the non-functional requirement is the ATM’s 24/7 availability.

How to Manage a User Story

You should use the project backlog in order to manage a user story. Often, Scrum teams arrange user stories based on their importance. The most important stories are improved to the fullest, while non-important ones are worked on minimally. For each sprint, the product owner records the most important (and the most detailed) user stories in the sprint backlog. When adding a user story to any backlog, the product owner checks its priority: he/she will place the user story in the project backlog according to its priority.

Important Note: Team members can remove or reprioritize user stories, depending on their situation.

The Benefits Offered by User Stories

· User stories help development groups to focus on the end-users. This is important since ultimately, the end-users will buy and use the product once it is released in the market. Thus, user stories help Scrum teams to connect with their end-users.

· The structure of user stories helps Scrum teams to determine the goals/values/benefits that the end-users want to achieve.

· The acceptance criteria, which is an important aspect of any user story, can help Scrum teams in analyzing their projects objectively.

· The members of a Scrum team may modify user stories while working on a project. For instance, they may split a user story into smaller ones if its scope grows too large. The team members may also change the acceptance criteria used for the project.

· Since the Scrum team delivers the product increment to the client each time a sprint ends. They may acquire feedback and suggestions that can be used in the subsequent sprints.

Conclusion

User stories bring you closer to the end-users of your projects; thus, these stories can help you generate usable products and prevent undesirable results.

All materials on the site are licensed Creative Commons Attribution-Sharealike 3.0 Unported CC BY-SA 3.0 & GNU Free Documentation License (GFDL)

If you are the copyright holder of any material contained on our site and intend to remove it, please contact our site administrator for approval.