User story is one of the popular way of writing requirement in Agile. Lot of Agilists prefer the User Story format. However, that is not the only way of writing requirements in Agile projects. You could write requirements in many ways, for e.g.Use Cases, Business Requirement Specification, BDD etc
Scrum is a framework. That means, Scrum describes the boundries and some minimal things that you need to do to create a product. What Scrum says is that you need to write requirements in a Product Backlog. Now Scrum does not tell you whether you write using User Story or a Use case or a BDD format. All that Scrum requires is that requirements be written.
Thus Scrum is non-prescriptive about writing requirements in a specific format. However, User Story still remains a very popular way of writing requirement in Scrum.

The post Why is User Story not part of core Scrum? appeared first on World Of Agile.

What is a User Story?

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

User Story Format

As a <role/persona>,

I should be able to <requirement>

so that <benefit>

User Story Examples

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]

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

• Why is User Story not part of core Scrum?
• Splitting User Stories in Scrum
• Velocity

The post What is a User Story? appeared first on World Of Agile.

Why do we need to split user stories?

Writing User Stories is an art. It needs to be clear to the team what is required and at the same time let the team decide the implantation details by innovating.

The key to writing good User Stories are as follows

• The User Stories should be small, typically, No more than 40 person hours of effort
• Keeping Stories small allows the team to build incrementally and get validations done along the way.
• This helps small value to the end user / stakeholder and allows the stakeholders to provide early feedback

Let us study a few ways in which user stories can be split into smaller stories

Ways to split user stories

Split using menu-structure or a big picture

You can look at the features like a menu structure and do a broad level division. You can consider the structure like a backbone in a menu and submenus. For example, let us see one example of a mobile application for a rental app which consists of a backbone of Reservation, Access, Location, Payments and Support. Each of the backbone elements can be subdivided into smaller items. This way of splitting works beautifully to start with. The next few patterns can be applied to each of the elements of the menu structure.

Split using user types

Each of the functionality can be split using user types. For example, let us take an example of login. Then we can write the user stories as

• As a end user I should be able to login so that I can book rental cars
• As a sales user I should be able to login so that I can upload sales deals
• As a marketing user I should be able to login so that I can display marketing banners to the end user
• As an administrator I should be able to login so that I can see the support tickets and resolve them

Split using workflows

Each user goes through different workflows through the system and therefore the splitting can be done with each User Story for each different workflow. Let us take the same login functionality as above and write a few workflows

• As an end user I should be allowed to login so that I can book rental cars
• As an end user I should be able to change password so that I can secure my login
• As an end user I should be able to use forget password so that I can recover my password

Split using Business Rules

Each business rule can be a different User Story. For example, let us say that you are developing an insurance system then the various business rules could be

• As an insurance seeker when I select that I am diabetic extra premium should be added
• As an insurance seeker when I select that I am a heart patient then corresponding wait period should be applied
• As an insurance seeker when I select that I do not have any ailment then no extra premiums should be added
• As in insurance seeker when my age exceeds 50 and is less than 60 then the premium calculation should be 1.2 times the premium below

Split using Data Modification tasks

Each data modification element can be a different User Story

• As an administrator I should be able to add users
• As an administrator I should be able to modify user details
• As an administrator I should be able to delete user
• As an administrator I should be able to reset the password on behalf of user

Split using various types of Data

Each variation in data can be different User Story

• As an end user I should be able to save my data in English language
• As an end user I should be able to save my data in Hindi language
• As an end user I should be able to save my data in French language

Split using major vs minor effort

User stories can be split using minor and major efforts criteria. For example, let us say that we want to build a payment gateway interface. Then we can split them into

• Story 1 – Payment gateway interface (major effort)
• Story 2 – Master card (minor effort)
• Story 3 – Visa card (minor effort)
• Story 4 – Amex card (minor effort)

Identify Spikes

Sometimes there are unknowns in a functionality and one does not know how to implement. You can write a few spikes to try out first and then implement. For e.g. you are not sure how to implement a payment gateway then you may try

• Spike 1 : Try an interface using vendor 1
• Spike 2 : Try an interface using vendor 2
• Spike 3 : Try an interface using vendor 3

See what works and then select the vendor and implement the actual user story

• As an end user I should be able to make a payment using a credit card

Split using Main flow vs Alternative flow

Sometimes there are main flows vs alternative flows. You can write user stories such as

• As a traveler I should be able to book rental car (main flow)
• As a traveler I should be able to book car seat for my child (alternate flow for car seat booking)
• As a traveler I should be able to book a luxury car and select luxury features (alternate flow for luxury car booking)

Identify performance stories to do them later

Performance features can be added later using a separate user story

• As a traveler I should be place an order on stock market using my front end (main story)
• As a traveler I should be able to book an order on stock market using my front end AND I should be able to get an order response within 0.1 second (performance story)

Identify scalability stories to do them later

Scalability features can be added later using a separate user story

• As a traveler I should be place an order on stock market using my front end and get response within 0.1 second (main story)
• As 1 million concurrent travelers I should be able to book an order on stock market using our front end AND still should get response within 0.1 second (scalability story)

Split using types of interfaces

There can be different interfaces to get to the functionality. Each interface can be a separate user story

• As a traveler I should be able to login using client software
• As a traveler I should be able to login using mobile phone
• As a traveler I should be able to login using ATM machine
• As a traveler I should be able to login using IVR system

Manual vs automated

User stories can be split using manually doing some functionality vs automated way

• As an administrator I should be able to calculate the penalty amount for each customer by clicking a button
• As an administrator I should be automatically calculated the penalty amounts by an automated interface

Batch vs Manual

Some functionality can be developed a manual first and then automated

• As an administrator I should be able to create users manually
• As an administrator I should be able to create users using automated upload of user file

API vs User Interface

It is better to first create an API and then the User Interface

• Story 1 – API – As a system I should be able to access the database using API and get required data for booking ticket
• Story 2 – Web User Interface – As an Web end user I should be able to get the best prices while booking (using the above API)
• Story 3 – Mobile User Interface – As an Mobile end user I should be able to get best prices while booking (using the above API)
• Story 4 – ATM Interface – As an ATM end user I should be able to get best prices while booking (using the above API)

Each Error is a separate User Story

Each error can be split up into separate stories

• User story on handling Error 401
• User story on handling Error 402
• User story on handling Error 403

The above article lists some of the ways the user story can be split into smaller stories. While there may be different other ways which we can use to do the same, the simple principle one must keep in mind is that the smaller the better and my recommendation is to keep the size of the split item nothing more than 40 person hours of effort.

The post Splitting User Stories in Scrum appeared first on World Of Agile.