User stories are a simple description of requirements and a popular agile method to capture user requirements. It can be used as a guide for the team on user needs. The user story is one of the many agile technologies or methods you will learn in the agile project management course.
User stories provide the expected background and clarity, without paying attention to technical details. Defining technical details too early can hinder alternative design options and changes. User stories are deliberately vague, providing space for creativity and interpretation.
User stories are told from the perspective of end-users and follow the following format:As... I...... want to......
User stories encourage team dialogue, which may reveal hidden assumptions and requirements. They should be kept short and should always meet the assigned acceptance criteria or the definition of "completed".
Who can write a user story?
Users are ideal for writing user stories. If you're using scrum, the job of the product owner is to fill the product backlog with user stories. During the scrum sprint, the most important stories were extracted from the backlog.
The key to writing effective user stories is to determine who, what, and why. Make sure your user stories follow INVEST standards - independent, negotiable, valuable, estimable, small, and testable. We can write user stories in the following four steps:
The first thing to do when writing a story is to define the end-user. Who will use your product? A useful way to visualize users is to make them role profiles. Give this person a name, and then find them a picture. Add their relevant attributes, attitudes, and behaviors. Finally, give them a goal. The following example is a useful definition of the smart baby monitor.
For this part, you need to consider the solutions your product offers. What do your end-users expect from your product? Refer to the "goals" section of the character profile and add a brief description of this to the story. The following example shows the requirements for end-users to use the smart baby monitor.
As a "parent", I want to "check my sleeping baby without going into their room"
3. Describe the benefits of the product
Imagine that you are the end-user talking to product developers. Tell developers about the benefits you will get from using this product. The following example shows how end users can use the smart baby monitor.
As a "parent", I want to "check my sleeping baby without entering their room", so I can "make sure they are safe without disturbing them".
4. Add acceptance criteria
In Agile, teams need to provide products that may be delivered. Acceptance standard is the clearest and quickest way to determine whether the user story is completed.
Each user story should have at least one acceptance criteria, but try not to list too many. You can use SMART goals to make sure your standards are measurable. Always remember to write from the end user's perspective, rather than confusing acceptance criteria with to-do lists.
As "parent", I want to "check my sleeping baby without entering their room", so I can "make sure they are safe without being affected".
-Night camera mounted on crib monitor
-Infant temperature and respiratory monitor function
-Data sent to parents' smartphones
-If there is a problem, an alert will be sent to the parent of the smartphone
Start building backlog
After you have written a user story, you can add it to the to-do list. Once you have a large number of user stories in hand, you can prioritize and estimate the workload.
Embracing change is part of the agile philosophy, so product requirements may change during the sprint, and you can improve the user story as you progress. If you find that your user story becomes complex or cannot be undone, you can break it down into smaller user stories. In this way, the story is unlikely to be incomplete at the end of the sprint.