User Stories: How to write them?
1. In 7%: The content (the words, what was said)
2. At 38%: The tone of voice
3. In 55% facial expressions.
1. Card: All user history must be able to be described on a small piece of paper. If this is not possible, it means that too much information is being communicated.
2. Conversation: All user history must have a conversation regarding its content with the Product Owner, you must know how to respond to questions about the value and the expected result of the implementation. This conversation can occur at any time, as it is most common during the execution or selection of the Backlog or the Sprint Planning.
3. Confirmation: All user history must be explained so that the work team knows what they want to do and what the Product Owner expects. This expected value is known as acceptance criteria.
Title: a descriptive title of the user’s history.
Value: value (usually numerical) that the user history brings to the client or user. The objective of the team is to maximize the value and satisfaction perceived by the client or user in each iteration. This field will determine, along with the time, the order in which the user stories are going to be implemented.
Dependencies: a user story should not be dependent on another story, but sometimes it is necessary to maintain the relationship. In this field, the identifiers of other stories on which it depends will be indicated.
Acceptance tests: consensus tests between the client or user and the team that the code must overcome to complete the implementation of the user history. This field is also commonly referred to as “acceptance criteria or conditions.”
Writing a User Story**
As a < type of user >, I want < some goal > so that < some reason >
(Advantages of the “As a user, I want” user story template, Mike Cohn,2008)
|Record of notes|
|As a teacher, I need to record student grades to keep track of approved and failed students.|
|Estimation: 3||Value: 60||
– Record of notes per student (only numerical values)
– Satisfactory note registration notice
– Calculation of the average of approved and failed
Illustration User History Tab.
What is INVEST? Characteristics of a user history**
Independent: It is important that each user story can be planned and implemented in any order. For this, they should be totally independent. Dependencies between user stories can be reduced by combining them into one or dividing them differently.
Negotiable: A user history is a short description of a need that does not include details. The stories must be negotiable since their details will be agreed by the client/user and the team during the “conversation” phase. Therefore, a user history with too many details should be avoided because it would limit the conversation about it.
Valuable: A user story has to be valuable to the client or the user. One way to make a story valuable to the client or the user is to write it himself.
Estimable: A good user history should be estimated with sufficient precision to help the client or user to prioritize and plan their implementation. The estimate will usually be made by the team and is directly related to the size of the user’s history (a large user history is more difficult to estimate) and with the team’s knowledge of the need expressed (in the case lack of knowledge, more phases of conversation about it will be necessary).
Small: The user stories should include at most a few weeks/person of work. There are even teams that restrict them to days/person. A short description helps to reduce the size of a user’s story, facilitating its estimation.
Testable: The user history should be able to be tested (“confirmation” phase of the user history). If the client or user does not know how to prove the user’s history it means that it is not completely clear or that it is not valuable. If the team cannot prove a user history, they will never know if it has finished or not.