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
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
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]
<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.