The Scrum Guide
- 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