Often during Project Execution, developer raises concerns that requirements are not clear or very open ended or during UAT phase of project, customer raises concerns that this is not what we asked for. Because at times traditionally written requirement statements are imprecise.

Agile Methodology shifts the focus from writing about a requirement to talking about it. Agility focusses on interaction between developers and customers on a requirement so as to arrive at an agreement which is known as User Story. Contrast to Use Case which contains a larger picture of a requirement; a User Story is:

• a short and snappy description capturing “who”, “what” and “why”,

• an agreement between customer and developer,

• something that the application needs to do from the customer or user prospective and which a developer understands well,

• and must have an Acceptance Criteria which acts as starting point for Acceptance Test.

For example
For an HR Software, a requirement statement says Employee can avail leave. There are several sub-requirements and conditions hidden under this one statement. Which when discussed between Developer and Customer, forms different user stories including the following:

User-Story 1:

• As an Employee

• I can apply leave

• So that I can be off from work without a salary deduction

Its Acceptance Criteria will be:

• Should have enough leave balance.

• Leave cannot be applied for previous month.

• Leave cannot be applied for Holiday.

• Leave cannot be applied twice for same day.

• Leave cannot be applied for the day employee has worked.

• And other situations as per leave policy…

Acceptance Criteria is the DONE agreement of a User Story.

Planning

Product backlog which is another form of Software Requirement Specification in Agile methodology is groomed by converting every wish list i.e. requirements – functional as well as non-functional to User Stories and prioritizing them.

Product Backlog is further used as base for project/Sprint planning.

A sprint is known as one iteration during project execution and a complete project is carried in various sprints or iterations. One or multiple user stories can form a Sprint. But one user story can never span over multiple sprints. Based on sprint size (number of days) and Story points (size of User Story), one Sprint is formed.

At times a User Story at top level looks short, but when discussed between Developer and Customer, is identified as too large to fit into one sprint. Then it’s referred as EPIC and is further broken down into smaller User Stories.

For example Employee can avail leave. This requirement user story will behave differently for different roles so will be referred as EPIC and shall be broken down into many user stories including these three:

• As an Employee I can apply leave, so that I can be off from work without a salary deduction.

• As a Resource Manager I can accept/reject leave based on work requirement.

• As a HR Manager, I can accept/reject leave based on employee behavior.

Within planning, I talked about Story points and sprint size. In the next post I will talk about it with estimating techniques within Agile Methodology in more detail.

So here to conclude on User Story, every project team must I.N.V.E.S.T into good user stories.

Image Courtesy: http://goo.gl/iyAN4N

Often during Project Execution, developer raises concerns that requirements are not clear or very open ended or during UAT phase of project, customer raises concerns that this is not what we asked for. Because at times traditionally written requirement statements are imprecise.

Agile Methodology shifts the focus from writing about a requirement to talking about it. Agility focusses on interaction between developers and customers on a requirement so as to arrive at an agreement which is known as User Story. Contrast to Use Case which contains a larger picture of a requirement; a User Story is:

• a short and snappy description capturing “who”, “what” and “why”,

• an agreement between customer and developer,

• something that the application needs to do from the customer or user prospective and which a developer understands well,

• and must have an Acceptance Criteria which acts as starting point for Acceptance Test.

For example
For an HR Software, a requirement statement says Employee can avail leave. There are several sub-requirements and conditions hidden under this one statement. Which when discussed between Developer and Customer, forms different user stories including the following:

User-Story 1:

• As an Employee

• I can apply leave

• So that I can be off from work without a salary deduction

Its Acceptance Criteria will be:

• Should have enough leave balance.

• Leave cannot be applied for previous month.

• Leave cannot be applied for Holiday.

• Leave cannot be applied twice for same day.

• Leave cannot be applied for the day employee has worked.

• And other situations as per leave policy…

Acceptance Criteria is the DONE agreement of a User Story.

Planning

Product backlog which is another form of Software Requirement Specification in Agile methodology is groomed by converting every wish list i.e. requirements – functional as well as non-functional to User Stories and prioritizing them.

Product Backlog is further used as base for project/Sprint planning.

A sprint is known as one iteration during project execution and a complete project is carried in various sprints or iterations. One or multiple user stories can form a Sprint. But one user story can never span over multiple sprints. Based on sprint size (number of days) and Story points (size of User Story), one Sprint is formed.

At times a User Story at top level looks short, but when discussed between Developer and Customer, is identified as too large to fit into one sprint. Then it’s referred as EPIC and is further broken down into smaller User Stories.

For example Employee can avail leave. This requirement user story will behave differently for different roles so will be referred as EPIC and shall be broken down into many user stories including these three:

• As an Employee I can apply leave, so that I can be off from work without a salary deduction.

• As a Resource Manager I can accept/reject leave based on work requirement.

• As a HR Manager, I can accept/reject leave based on employee behavior.

Within planning, I talked about Story points and sprint size. In the next post I will talk about it with estimating techniques within Agile Methodology in more detail.

So here to conclude on User Story, every project team must I.N.V.E.S.T into good user stories.

Image Courtesy: http://goo.gl/iyAN4N[:]