PO: How to write user stories?
- 2020-11-25 15:43:16
- Renee Fey
- Original 3146
PO: How to write user stories?
The origin of user storiesUser stories are the concepts first proposed in Extreme Programming. It has also been used in Scrum. Compared with requirements documents or prototypes, user stories are organized in an itemized way, which is simple to maintain, easy to estimate and sort, and facilitate development teams to complete delivery in small iterations.
Whether a product can be split into user stories with appropriate granularity is the prerequisite for the entire team to be agile.
What is a user storyUser stories describe the features from the perspective of users. A good user story includes three elements, namely role, activity and business value.
- Who is the role to use this feature;
- What feature does the activity need to complete;
- Why this function is needed and what value this feature can bring.
For example, "As a department manager, I hope that the system can have a daily to-do, so that I can understand the work progress of each employee in the department."
As a <a type of user>, I hope to <achieve a goal>, so that <what value it can bring>.
Why write user storiesUser stories can help you communicate functional requirements to the development team. It will be easier for the development team to understand why this feature is developed and how users will use it.
To write a user story, you can use 3Cs.
CardThe user story can be written on the card, and the content includes a short description of the user story, acceptance criteria, etc.
ConversationThe details behind the user story come from communication with customers or product owners.
ConfirmationPass the acceptance test to confirm that the user story is completed correctly.
How to write a user storyTo write a good user story, you can follow the INVEST principle. Read Story Writing to know more about this principle.
I — IndependentA user story should be independent of the other user story. The interdependent stories would make it quite difficult to do the planning, prioritizing and estimation. Dependency can be reduced through story combination/subdivision.
N — NegotiableA user story should be negotiable. A story card should contain a brief introduction of the story, which is defined through meetings and discussions. A card which contains much information actually reduces the talking with clients.
V — ValuableEach user story must be valuable for clients (both the customers and the users). One way to make user stories valuable is to let the clients write them. Once clients realize that a user story is not contractual but negotiable, they will be very willing to write them.
E — EstimableDevelopers need to estimate the user story in order to set priorities and make plans. But what makes it difficult for developers to estimate is the lack of relevant knowledge in a certain industry, which could be solved by more communication; or because the story is too big, and should be subdivided.
S — SmallA great user story should be small in terms of workload and description, and it could be done by two/three persons. User stories bigger than the workload of 2-3 persons will cause problems when subdivided and estimated.
T— TestableUser stories are testable and can be finished through testing. Remember, stories that are not testable should not be developed. If you cannot test the stories, you will never know when they can be finished. An example of untestable user stories is that software should be user-friendly.
When you truly understand the value of user stories, questions about how to write user stories and which format to use will be solved, because you will have comprehended the key of agile user story practice, that is to facilitate discussion, to clarify values, and to get consensus.
Write a Comment
- ZDOO Cloud
- Request Demo
- Tech Forum
- Private Policy
- Term of Use
- Google Groups
- Leave a Message
- Email: email@example.com