A user story is a basic development made by XP (extreme programming) project teams (Ron, 2001). It is a highly-defined requirement type containing useful information that can be used by developers to provide estimations for implementing such improvement (Ron, 2001). This is a form of a story told from user perspectives with brief but concise descriptions that are essential to software used by either mere users or actual customers (Carroll, 2001).
A good user story must be able to establish an effective conversation with the project stakeholders or customers. It should explicitly preferred functionality answering the question of “who wants it?” and “how and why the functionality must be utilized?” (Carroll, 2001) User stories have three basic aspects, namely: cards, conversation and confirmation (Carroll, 2001).
Basically, user stories are written on cards. However, the card does not comprise all information needed for a requirement; it only has enough texts to recognize the requirement and to reiterate to everyone what the story is about (Ron, 2001). The card is very important in the representation of a requirement. It is used in planning, where all basic notes are written for contemplating precedence and costs (Ron, 2001). Often, this is given to programmers for implementation schedules and then given back to the customer after it was completed.
A conversation for the requirement is made through an interaction between programmers and the customers. This takes place mainly after the plan is released and again in a planning meeting wherein a schedule for its implementation is established (Ron, 2001). The discussion is mostly in verbal form but is often supported by documents. Spreadsheets illustrating calculations, proposed window layout sketches, even multi-page documents are commonly seen at these meetings (Ron, 2001).
We can’t be certain of what must be in need to be done no matter how many discussions or documents we have completed. Acceptance tests should be done prior to its implementation (Ron, 2001). First of all, iteration is held wherein the customer tells the programmer what she wants and by confirming the plan made ready for implementation (Ron, 2001). Then secondly, the implementation of the story is made anchored in the acceptance test presented (Ron, 2001). And lastly, the programmers will now show the customer for the verification of the produced output story, which will now determine its success (Ron, 2001).
Furthermore, a well-written user story follows various considerations that are identified as the INVEST model (Cohn, 2004). This model possesses six attributes, namely: independent, negotiable, valuable, estimable, small, and testable.
A user story must be independent. It must avoid dependencies. Dependencies lead to problems in planning and prioritization (Cohn, 2004). Moreover, these make approximations much complicated than it is supposed to be. More frequently, dependencies can be minimized by either combining the stories into one or by dividing them in a different manner (Cohn, 2004).
Moreover, it must be negotiable. The details written in the card must provide openness to discussions, however brief they may be (Cohn, 2004). These inputted details are being managed during the phase of discussions. Nonetheless, if details are inclusive of too much information, the conversation becomes limited (Cohn, 2004).
Each written story must have remarkable value to either the user or the purchaser itself. Being able to get the customers to write stories is an appropriate way to make them. As soon as the customers have understood that these user stories are negotiable and not contract-based, they will be at ease in producing more stories (Cohn, 2004).
To further permit prioritization and better planning of the story, a user story must first be estimated by the developers (Carroll, 2001). Problems that are usually encountered from estimations include lack of knowledge in the given field in which more negotiations are needed; or if the story is very broad, that in which the story must be split into pieces first (Carroll, 2001).
Also, story size must matter because planning can’t be established if stories are too big and too large and, more importantly, if it is too small. Breaking out stories that cannot be estimated enables the customer to prioritize the research separately from new functionalities (Cohn, 2004). However, too small stories are more difficult to do in terms of estimations because it would take much time than revising them (Cohn, 2004).
Likewise, stories written must certainly be testable. If stories are not capable of testing, developers won’t know if they had finished programming (Cohn, 2004). Passing the test successfully indicates that a story is effectively developed.
We may ask, “why user stories?” User stories are deemed to be important because they encompass similar characteristics of cases that were formerly used and conventional requirements stated (Carroll, 2001). It is essential to make distinctions from the earlier methodologies to these modern requirements to further establish a good user story (Carroll, 2001).
User stories give emphasis on the verbal form of communication (Cohn, 2004). The vagueness of written texts alone are mostly the problem encountered and may lead to misunderstandings between the customer and developer; that is why further discussions are being organized at hand (Carroll, 2001). Direct employment in project planning is another advantage of having user stories. They are opted to be written so that either the developer or the customer can give estimations on the complexity or extensiveness of the story for its further progress (Carroll, 2001). And also, because one story is discussed in a single iteration, it must be of great advantage to both the programmer and the customer to have with them the user stories (Cohn, 2004). Additionally, putting off a collection of details for the team is encouraged by user stories. A story can have more details once it becomes more vital to have them (Cohn, 2004). In this way, when projects that have limited time are situated, these user stories may be perfect.
References
- Carroll, John. Making Use: Scenario-Based Design of Human-Computer Interactions (MIT Press, 2000).
- Cohn, Mike. “User Stories Applied”. Addison-Wesley, 2004.
- Ron Jeffries. “Essential XP: Card, Conversation, and Confirmation,” XP Magazine, 2001.