The origin of user stories
User 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 story
User 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.
Usually, a user story can be summarized with a simple template.
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."
Why write user stories
User 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.
Card
The user story can be written on the card, and the content includes a short description of the user story, acceptance criteria, etc.
Conversation
The details behind the user story come from communication with customers or product owners.
Confirmation
Pass the acceptance test to confirm that the user story is completed correctly.
How to write a user story
To write a good user story, you can follow the INVEST principle. Read Story Writing to know more about this principle.
I — Independent
A 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 — Negotiable
A 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 — Valuable
Each 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 — Estimable
Developers 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 — Small
A 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— Testable
User 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.