The User Story is the most granular unit of requirement on a Scrum Project. The Product Owner writes the User Stories. The Sprint Backlog gets elaborated into User Stories when the Sprint Planning is done.
It is important to note that the user story is a medium that helps in
- Gathering basic information about requirements
- Records high level requirements
- Developing estimates
- Defining acceptance test to validate successful completion
User Story is the starting point of Communication about the details of requirements and once they are agreed then they represent the agreement between team and customer about what customer can expect from implementation.
User Stories adhere to a specific, predefined structure and are a simplistic way of documenting the requirements and desired end-user functionality. A user story tells you three things about the requirements
- Who
- What
- Why
The requirements expressed in User Stories are short, simple and easy to understand statements. The predefined, standard format results in enhanced communication among the stakeholders are better estimations by the team. Some User Stories may be too large to handle within a single sprint. These large User Stories are often called Epics. Once Epics come up in Prioritized Product Backlog to be completed in a upcoming sprint they are further decomposed in to smaller User Stories.
The Prioritized Product Backlog is a dynamic list that is continuously updated because of reprioritization and new, updated, refined, and sometimes deleted User Stories. These updates to the backlog are typically the result of changing business requirements.
The Three components of a User Story are
| Cards |  |
The Card is meant to indicate that the story is typically written by hand on a index card about 4 X 6 inches in dimension. The idea behind writing the story on a card is to try and limit the size of User Story.
When you write like this the author of the story has to take efforts in making the story less verbose and clearer to the team. |
| Conversation |  |
Conversation means that the Story should be the starting point of the conversation between the team and the Product Owner who typically would write the Story.
The Story should leave the implementation details to the team who have a potential to innovate and try to implement it. |
| Confirmation |  |
Confirmation means that you typically have to provide acceptance criteria for the story. Acceptance tests are typically written on back of the card and help the team understand how the work done satisfies the requirements. |
Another Acronym to describe the Attributes of a User Story is INVEST
| I | Independent | Story should be as far as possible independent of each other and deliverable as a unit |
| N | Negotiable | Leave room for negotiation for nature of implementation |
| V | Valuable | That is it should result in some value to the Customer |
| E | Estimable | User Story should be clear enough for the team to come up with reasonable estimates to work on |
| S | Small | Story should not be so big that it cannot be done within an sprint. Agile requires that story should be no more than 40 man hours of effort |
| T | Testable | It should be possible to test the Story for correctness based on description and success criteria provided. |
User Story Format
As a <role/persona>,
I should be able to <requirement>
so that <benefit>
User Story Examples
| Front and Back of Card Example
|
Acceptance Criteria details should be added and following information can be added to provide context
GIVEN [Context] <and/or [Some more Context]
WHEN [Event]
THEN [Outcome]
<and/or [another Outcome]
| Example: A Ticket booker needs to be prevented from making excessive bookings in a day. This is to avoid Ticket Booking Agents from booking tickets on behalf of others and in turn charging a premium from individuals.
GIVEN that the ticket booker places another ticket booking Request WHEN The ticket booker has already booked 3 tickets today (Maximum tickets to allowed per day = 3) THEN Flash a message that you are not allowed to book more than 3 tickets a day |
Story Card Information
Following information can be captured on a Story Card. This is an indicative list and you should customize as per project requirements
- Story Identifier
- Description : Couple of sentences on the story
- Story Type : (Customer/Technical)
- Estimated Work Effort
- Estmated Value Points : Which gives how much of value it delivers the customer.
- Requirement Uncertainty : That is same as Requirement variability i.e. how much variability is expected in the requirement. Sometimes called “Exploration Factor”.
- Story Dependencies : If the story depends on other stories
- Acceptance Tests : Typically written on back of the card. It indicates how story should be tested.
Please refer to the following links to know more about User Story