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]}

A common format for writing user stories is:

User story format: As a {user type/role} I can {function} so that {benefit}

Examples (from a Learning Management System):

1. As a student, I can download files uploaded by lecturers, so that I can get my own copy of the files
2. As a lecturer, I can create discussion forums, so that students can discuss things online
3. As a tutor, I can print attendance sheets, so that I can take attendance during the class

We can write user stories on index cards or sticky notes, and arrange on walls or tables, to facilitate planning and discussion. Alternatively, we can use a software such as GitHub Project Boards to manage user stories digitally.

🏆 Able to explain what is a user story

• 1. They are based on stories users tell about similar systems
• 2. They are written from the user/customer perspective
• 3. They are always written in some physical medium such as index cards or sticky notes

• 1. Reason: Despite the name, user stories are not related to 'stories' about the software.
• 2.
• 3. Reason: It is possible to use software to record user stories. When the team members are not co-located this may be the only option.

Critique the following user story taken from a software project to build an e-commerce website.

As a developer, I want to use Python to implement the software, so that we can resue existing Python modules.

Refer to the definition of a user story.

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]}

This user story is not written from the perspective of the user/customer.

🏆 Able to write simple user stories in a known format

Bill wants you to build a Human Resource Management (HRM) system. He mentions that the system will help employees to view their own leave balance. What are the user stories you can extract from that statement?

Remember to follow the correct format when writing user stories.

User story format: As a {user type/role} I can {function} so that {benefit}

As an employee, I can view my leave balance, so that I can know how many leave days I have left.

Note: the {benefit} part may vary as it is not specifically mentioned in the question.

This video explains the rationale behind user stories. The video uses the term 'agile principles/processes'. If you don't know what that means, just think of it as 'a good thing to have'.

^{source: http://dilbert.com/strip/2003-01-10}

The {benefit} can be omitted if it is obvious.

As a user, I can login to the system so that I can access my data

It is recommended to confirm there is a concrete benefit even if you omit it from the user story. If not, we could end up adding features that have no real benefit.

We can add more characteristics to the {user role} to provide more context to the user story.

• As a forgetful user, I can view a password hint, so that I can recall my password.
• As an expert user, I can tweak the underlying formatting tags of the document, so that I can format the document exactly as I need.

We can write user stories at various levels. High-level user stories, called epics (or themes) cover bigger functionality. We can then break down these epics to multiple user stories of normal size.

[Epic] As a lecturer, I can monitor student participation levels

• As a lecturer, I can view the forum post count of each student so that I can identify the activity level of students in the forum
• As a lecturer, I can view webcast view records of each student so that I can identify the students who did not view webcasts
• As a lecturer, I can view file download statistics of each student so that I can identify the students who do not download lecture materials

We can add conditions of satisfaction to a user story to specify things that need to be true for the user story implementation to be accepted as ‘done’.

• As a lecturer, I can view the forum post count of each student so that I can identify the activity level of students in the forum.
  Conditions:
  [ ] Separate post count for each forum should be shown
  [ ] Total post count of a student should be shown
  [ ] The list should be sortable by student name and post count

Other useful info that can be added to a user story includes (but not limited to)

• Priority: how important the user story is
• Size: the estimated effort to implement the user story
• Urgency: how soon the feature is needed

User stories for a travel website (credit: Mike Cohen)

• As a registered user, I am required to log in so that I can access the system
• As a forgetful user, I can request a password reminder so that I can log in if I forget mine
• [Epic] As a user, I can cancel a reservation
  • As a premium site member, I can cancel a reservation up to the last minute
  • As a non-premium member, I can cancel up to 24 hours in advance
  • As a member, I am emailed a confirmation of any cancelled reservation
• [Epic] As a frequent flyer, I want to book a trip
  • As a frequent flyer, I want to book a trip using miles
  • As a frequent flyer, I want to rebook a trip I take often
  • As a frequent flyer, I want to request an upgrade
  • As a frequent flyer, I want to see if my upgrade cleared

🏆 Able to write more detailed user stories

...

...

...

...

User stories capture user requirements in a way that is convenient for scoping, estimation and scheduling.

[User stories] strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
^{[Mike Cohn, MountainGoat Software 🔗]}

User stories differ from traditional requirements specifications mainly in the level of detail. User stories should only provide enough details to make a reasonably low risk estimate of how long the user story will take to implement. When the time comes to implement the user story, the developers will meet with the customer face-to-face to work out a more detailed description of the requirements. [🔖]

User stories can capture non-functional requirements too because even NFRs must benefit some stakeholder.

As a	I want to	so that
impatient user	to be able experience reasonable response time from the website while up to 1000 concurrent users are using it	I can use the app even when the traffic is at the maximum expected level

This article by Mike Cohn from MountainGoatSoftware explains how to use user stories to capture NFRs.

🏆 Able to use user stroies to manage requirements of project

...

...

eXtreme Programming (XP)

Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. [wikipedia, 2017.05.01]

uses User stories to capture requirements.

This page in their website explains the difference between user stories and traditional requirements.

One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face.