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.
Oldest comments (10)
Very helpful!
Thank you
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...
Wawu! I just read through it. Awesome
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.
Very correct.
Very well explained 🙌
Thank you
While working/figuring out user values and tasks, I tend to use an alternative format:
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.
well done.