A user story details a specific feature. It should be specify a single feature. For example the following story: “Create a login box with a remember me checkbox and a forgot password link” should be splited into tree stories, one for the login box, another for the remember me and another one for the forgot password link.

This ensures the stories remain small ans can be implemented quickly

A User Story, much like its implementation also has some phases or stages, this ensures the Story has enough quality when it reaches the development team

##Definition of ready

The Definition of Ready is very important for the team and Product Owner. It says when a User Story is in a state that the team can pick it up, as such is also the Definition of Done for the Product Owner

Our definition of Ready includes the following points:

The story is clear:

  • The Story specifies who, what and why

The story is testable:

  • Acceptance criteria is written

Team understands the story:

  • The story is discussed with the team before commitment

The client approved the story:

  • The client has seen the story, or at least the designs/wire frames and has given his approval

All needed resources are available:

  • Data from 3rd party
  • Layouts
  • Diagrams,
  • translations, etc

Only when this points are checked the User Story will be considered for development

Acceptance Criteria

The Acceptance Criteria is a list of Behavioural requirements for the User Story, Functional and Unit Tests will be written based on the Acceptance Criteria.

Great care should be taken when writing the Acceptance Criteria, all possible Behaviours should be taken into consideration and described

As the User Story MUST comply to this criteria the Product Owner has in this criteria a very useful mechanism to ensure the Story behaves as he envisions.

The acceptance criteria is also very important to the team as it tells how the code should behave.

The Acceptance Criteria can also serve as feature documentation, when the project grows is hard to keep track of all features and they should do. By keeping a record if all Acceptance Criteria we can easily know how the system should behave

Examples of Clear User stories:

Example 1:

As a Site Visitor I can create an account in order to become a member of the site.

Example 2:

As an Account Holder I want to withdraw cash from an ATM So that I can get money when the bank is closed

Examples of Acceptance Criteria:

Example 1:

A user should enter an email address and a password

Test that both the email address and password are entered (not blank)

Test that the email address is in a valid format

Test that the password is at least 6 characters

Example 2:

Given the account balance is $100

And the card is valid

And the machine contains enough money

When the Account Holder requests $20

Then the ATM should dispense $20

And the account balance should be $80

And the card should be returned

Definition of Done<

The Definition of Done is very important for the scrum team, it lets the team know when a User Story can be declared Done and another User Story can be picked up.

Our definition of done includes the following points:

Code has quality:

  • Code review passed
  • 75% unit test coverage
  • Complies to coding standards
  • Functional tests to written according to Acceptance Criteria

Code is tested:

  • Signed off by the Quality Assurance team
  • Functional tests passed
  • No failing Unit Tests

Code can be deployed:

  • install package is created
  • code is deployed into the integration server

Story can be demoed:

  • All needed preparations to demo the story are done (power point, sample data, etc)