What are "user stories" and why do we need them?

[joshuamabina]

Guidelines

• [ ] What is a user story?
• [ ] Why create a user story?
• [ ] How to write a user story?
• [ ] Can you show some user story examples?
• [ ] Who writes user stories?
• [ ] When are user stories written?
• [ ] Do user stories replace a requirements document?
• [ ] Any tips, recommendations and helpful links.

Further reading

• User Stories and User Stories Examples by Mike Cohn
• User Stories with Examples and Template | Atlassian
• Advantages of the “As a user, I want” user story template.
• Advantages of User Stories for Requirements

[elineka]

What is a user story?

is an informal, natural language description of one or more features of a software system. Is a 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. User stories are used in agile to plan features and functionality and often written from the perspective of an end user or user of a system.

[elineka]

Why create a user story?

• Stories keep the focus on the user. A To Do list keeps the team focused on tasks that need checked off, but a collection of stories keeps the team focused on solving problems for real users.

• Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.

• Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.

• Stories create momentum. With each passing story, the development team enjoys a small challenges and a small win, driving momentum.

• They facilitate sense making and communication; that is, they help software teams organize their understanding of the system and its context

[elineka]

How to write a user story?

Consider the following when writing user stories:

• Definition of “Done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.

• Outline sub tasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.

• User personas — For Whom? If there are multiple end users, consider making multiple stories.

• Ordered Steps — Write a story for each step in a larger process.

• Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.

• Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.

User stories are often expressed in a simple sentence, structured as follows: “As a [persona], I [want to], [so that].” Breaking this down: • "As a [persona]": Who are we building this for? We are not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We have hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max.

• “Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you're missing the point.

• “So that”: how does their immediate desire to do something this fit into their bigger picture? What is the overall benefit they’re trying to achieve? What is the big problem that needs solving?

For example, user stories might look like:

• As Max, I want to invite my friends, so we can enjoy this service together.

• As a manager, I want to be able to understand my colleagues progress, so I can better report our success and failures.

This structure is not required, but it is helpful for defining done. When that persona can capture their desired value, then the story is complete. We encourage teams to define their own structure, and then to stick to it

[elineka]

Can you show some user story examples?

1) As a user opening Ride-My-Way app, I want to see an option to either login or register, so I can access my online account of the app.

Detail added:

-user should see screen with input data field for username and password

-User should see an option to Register/Signup if they do not have an account

-User should have an option link to reset password in case password forgotten

2) As a user, I want to see the page where I can add detail as a driver to offer a ride so that I can add a ride offer

3) As s Rider I want to see all available ride offer added by the driver so that I can decided join the ride.

[mkawa125]

From my perspective user story can not be ready to be implemented if it does not have acceptance criteria, when do you guys write acceptance criteria of each user story?

Acceptance criteria will make the definition of done of that story. Or how do you guys make sure the product owner accepts this story is really done? @joshuamabina and @elineka