Associated with each User Story is a set of Acceptance Criteria. The Acceptance Criteria defines what the Product Owner would want in order to accept the story as being done. You could view the Acceptance criteria as an elaboration of the feature since it adds additional details to the user story. The User Story and associated Acceptance Criteria forms the basis for development and test of the feature.
A good User Story follows the INVEST principle. INVEST is a mnemonic standing for the following:
| I | Independent | The user story should be self-contained in a way that there is no inherent dependency on another user story. |
| N | Negotiable | Details of how the user story will be implemented will be created by the dev team implementing the user story. |
| V | Valuable | A user story must deliver value to the end user. |
| E | Estimable | The development team must always be able to estimate the size of a user story. |
| S | Small | A user story must be small enough to fit within a Sprint. If it is large then it is an Epic and must be decomposed into stories prior to a sprint. |
| T | Testable | You must be able to test a user story to meet its defined acceptance criteria |
You should also know what is an EPIC?
An Epic is a large user story. It follows the same format as a User Story (As a ___ I want to ____ so that ____). The difference between an Epic and a User Story is size. If it is too large to be implemented in a Sprint then it is an Epic.
It is the Development Team’s responsibility to size the Product Backlog items. A Product Backlog often contains user stories on the top and Epics on the bottom. The Product Backlog is continuously refined or groomed.
As Epics become higher in priority they need to be decomposed before they are ready to be included in a sprint.
The initial Product Backlog containing user stories and epics is often created during product planning to identify the vision and scope of the system. This Product Backlog is dynamic. For example, as the team demonstrates software completed during sprints, feedback is obtained by customers and stakeholders and new user stories may be added, existing user stories may be deleted, modified or re-prioritized. Because user stories and epics are a single sentence, they are very easy to work with and to evolve.
Here are a couple of examples of user stories that anyone would understand:
- As a restaurant client, I want to be able to view a menu, so that I know the current selection of food and associated prices.
- As an airline passenger who purchased a ticket, I want to select a seat, so that I know exactly where I will be sitting on the plane.
There are several different ways of writing acceptance criteria. The simplest form would be to write as a bullet list in terms of what the development team would need to demonstrate back to the Product Owner in order for user story to be accepted.
An example of Acceptance Criteria for the restaurant example (1st user story) above would be:
- Given customer visits the restaurant, views lunch or dinner Menu
- When customer selects dinner menu
- Then customer should able to view selection of foo, daily specials and prices.
Sample: Healthcare User Story
- Display Claim-Member Information: As a user, I need ability to view information for a specific claim. so that I can see information specific to the claim being resolved /searched.
- Given user is athuenticated
- When system allow the user to view historical information of correspondence generated and sent in the Documents and Correspondence tab of Claim Views section
- Then system shall display the documents and correspondence assigned to the claim during the process of adjudication, system shall allow user to click on a template and view the image of correspondence/Document, system shall allow the user to print the image.