The Rules of the Game.

2. User stories
• Title
• Story point
• Acceptance Criteria
• definition of Done
• definition of Ready

3. Title
As a <user>
I want to <action description> or <function>
So that <value statement>

4. Definition of Done
Code Complete
Unit tests written and
executed
Integration tested
Performance tested
Documented (just enough)

5. Definition of Done
• Definition of Done for a feature (story or product backlog item)
• Definition of Done for a sprint (collection of features developed within a sprint)
• Definition of Done for a release (potentially shippable state)
• Can we do this activity for each feature? If not, then
• Can we do this activity for each sprint? If not, then
• We have to do this activity for our release!

6. Acceptance Criteria
Acceptance criteria define the boundaries of a user story, and are used to
confirm when a story is completed and working as intended.
For the above example, the acceptance criteria could include:
• A user cannot submit a form without completing all the mandatory fields.
• Information from the form is stored in the registrations database.
• Protection against spam is working.
• Payment can be made via credit card.
• An acknowledgment email is sent to the user after submitting the form.

7. Acceptance Criteria
• As you can see, the acceptance criteria are written in simple language,
just like the user story. When the development team has finished
working on the user story they demonstrate the functionality to the
Product Owner, showing how each criterion is satisfied.
• Including acceptance criteria as part of your user stories has several
benefits:
• they get the team to think through how a feature or piece of
functionality will work from the user’s perspective
• they remove ambiguity from requirements
• they form the tests that will confirm that a feature or piece of
functionality is working and complete.

8. definition of Ready User Stories
• User Story defined
• User Story dependencies identified
• User Story sized by Delivery Team
• Scrum Team accepts User Experience artifacts
• Performance criteria identified, where appropriate
• Person who will accept the User Story is identified
• Team has a good idea what it will mean to Demo the User Story

9. definition of Ready Backlog
• The Sprint Backlog is prioritized
• The Spring Backlog contains all defects, User Stories and other
work that the team is committing to
• No hidden work
• All team members have calculated their capacity for the Sprint
• Full-time on project = X hours per day
• All User Stories meet Definition of Ready

10. • Start doing
• Stop doing
• Continue doing
• What went well during the sprint cycle?
• What went wrong during the sprint cycle?
• What could we do differently to improve?
Retrospective
The meeting is facilitated by the ScrumMaster and Product owner is
typically not in the room.

11. • Attendees include the Scrum Team and key stakeholders invited by the
Product Owner;
• The Product Owner explains what Product Backlog items have been
“Done” and what has not been “Done”;
• The Development Team discusses what went well during the Sprint,
what problems it ran into, and how those problems were solved;
• The Development Team demonstrates the work that it has “Done” and
answers questions about the Increment;
Review
The meeting is facilitated by the Scrum master

12. • The Product Owner discusses the Product Backlog as it stands. He or
she projects likely completion dates based on progress to date (if
needed);
• The entire group collaborates on what to do next, so that the Sprint
Review provides valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might
have changed what is the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace
for the next anticipated release of the product.
Review
The meeting is facilitated by the Scrum master