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)