Skip to content

Latest commit

 

History

History
58 lines (35 loc) · 4.92 KB

README.md

File metadata and controls

58 lines (35 loc) · 4.92 KB
Raw

#USER STORIES

Index

User Stories

User Stories are narrative texts that describe an interaction between an user and a system, focusing on the value that the user gains from the system. Rather than a full requirement document, an User Story is a summary of collaborative work and agreements about the User Story itself (human collaboration over documentation)

A good user story uses the “INVEST” model:

  • (I)ndependent: Reduced dependencies = easier to plan
  • (N)egotiable: Details added via collaboration
  • (V)aluable: Provides value to the customer
  • (E)stimable: Too big or too vague = not estimable
  • (S)mall: Can be done in less than a week by the team
  • (T)estable: Good acceptance criteria

User Story writing Process

The story-writing process is very important to build good User Stories.

The typical template has 3 parts: the title, the description (or body of the user story), and the acceptance criteria. The title is used to reference the User Story and should be kept very short, around 3 to 10 words. The description is where the User Story is described. It is the only part that can be explained as a reasonable template. The acceptance criteria are used to determine when the user story has met the goal of the user – sort of a test.

  1. Start by writing the title. It should be long enough to allow the team to differentiate it from other stories but short enough to fit on a small sticky card when written with a marker.

  2. Now write the description. You can use the following template:

As a [user role] I want to [goal] so I can [reason]

If the description becomes too long (more than will fit on an index card), you should reconsider the User Story. It is likely that it needs to be split into several stories. You might also consider whether you are trying to include too many details. Remember that the purpose of an User Story is to encourage collaboration. An User Story is a commitment to have a future conversation; it is not meant to document every aspect of the work, as you might expect in traditional requirement documents.

When writing an User Story, you might include some acceptance criteria, perhaps in the form of a test case or a brief description of "done", if those criteria help make the User Story's purpose clearer or easier to remember. When the team is ready to work on that story, however, the team and the product owner must discuss the User Story. This process will include addition of acceptance criteria so the team will know what 'done' means for it. Later, as the team members begin to work on the story, they might need to contact the Product Owner and discuss new or different acceptance criteria as their understanding of the story grows. Acceptance criteria enrich the understanding of the story, which in turn brings out new acceptance criteria and more meaningful conversations about what the customer really wants.

Frequent Mistakes in User Stories

There are three main problems related to User Story creation:

  1. Too much information in the description. This leads to a loss of collaboration and a reliance on the old ways of documenting everything. An User Story should be thought of as a "talking points", a "to-do list," or a "tickler that a conversation must occur about a topic." The User Story is a placeholder for a conversation or a series of conversations: it is only through collaboration that a User Story works as an agile tool; otherwise it's just a requirement written on an index card.

  2. Missing information in acceptance criteria. Before starting to work on a story, the team must understand the acceptance criteria. These are essential for knowing what needs to be done in order to complete the user story. Acceptance criteria should be detailed enough to define when the user story is completed, yet not so detailed as to reduce collaboration. Writing acceptance criteria is a crucial part of an user story.

  3. Confuse acceptance criteria and test cases. Both are necessary for an User Story. Acceptance criteria answer the question: “How will I know when I’m done with the story?” and on the other hand, test cases answer the questions: “How do I test and what are the test steps?”. While both of them should be added to the user story via collaboration, only acceptance criteria are required. Test-driven development is often used to fulfill test cases as the code is written.

References

BEEVA | Technology and innovative solutions for companies