DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 963,673 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for How To Write A User Story
 Faith Pueneh
Faith Pueneh

Posted on

How To Write A User Story

Introduction:

One of the difficulties in developing a software application is determining and meeting the needs of the end user. This problem is easily solved by writing a user's story, which allows us to understand the end user's point of view. This article defines a user story, the benefits of writing one, and how to write one.

What is a user story:

User stories are agile software development tools used to explain a software feature written from the end user's perspective in an easy-to-understand format.
They are not written in detail and should not be big or small.
They only explain how a particular type of work will add value to the end user, who can be either colleagues or external users. They are written down on index cards, sticky notes, and project management software.

Benefits of the User Story:

Some of the benefits of the user story include but are not limited to these:

  • It helps the teams deliver high-quality content.
  • It enables collaboration with team members.
  • It helps in improving transparency.
  • It reduces risk by giving clarity to the requirement of the user.
  • It helps in supporting iterative development.
  • It helps focuses on vocal communication

How to write a user story:

User stories capture the most critical aspects of a requirement:

  • Who is it aimed at?
  • What does it expect of the system?
  • Why is it valuable (optional)?

They are written in this format:
As a [role], [i want to] [so that]
The β€œrole” refers to the user that would interact with the system
The β€œwant to” represents the behavior of the system and is peculiar to each story.
β€œSo that” explains the benefit of the story.
As an example:
As a manager, I want to be able to track my team’s progress so that I can record our successes and failures.

Conclusion:

User stories can be understood by anyone and keep you from becoming entangled in technical jargon. It develops each proposed idea for new functionality from the point of view of real users.

Top comments (9)

Collapse
 
j3ffjessie profile image
J3ffJessie

Also, another good thing to have in your user stories are the acceptance criteria for that story. After describing the above you need to explain what the acceptable functionality and UI are for the user story where possible.

Not all user stories will have that, but should be included in those that have functionality or UI tasks associated.

Collapse
 
puenehfaith profile image
Faith Pueneh Author

Very correct.

Collapse
 
klesand profile image
Klesta

Very helpful!

Collapse
 
puenehfaith profile image
Faith Pueneh Author

Thank you

Collapse
 
tandrieu profile image
Thibaut Andrieu

Very good summary of what should be a story :)

btw, I wrote an article a few months ago with the same title word for word πŸ˜‚
kissyagni.com/2022/05/05/how-to-wr...

Collapse
 
puenehfaith profile image
Faith Pueneh Author

Wawu! I just read through it. Awesome

Collapse
 
liunate profile image
Nate Liu

While working/figuring out user values and tasks, I tend to use an alternative format:

AS A [role],
IN ORDER TO [value],
I NEED TO [tasks]
Enter fullscreen mode Exit fullscreen mode

This format helps focus on the [value] first, and I can just leave that [tasks] empty until I discover all the [value]s in an epic. With proper value-prioritization, then I can start filling in those [tasks] and resource allocation accordingly.

Collapse
 
yuridevat profile image
Julia πŸ‘©πŸ»β€πŸ’»

Very well explained πŸ™Œ

Collapse
 
puenehfaith profile image
Faith Pueneh Author

Thank you

Need a better mental model for async/await?

Check out this classic DEV post on the subject.

β­οΈπŸŽ€ JavaScript Visualized: Promises & Async/Await

async await