The document provides an overview of the Scrum process. Some key points: - Scrum is an agile process that focuses on delivering high business value in short iterations through inspecting working software every 2-4 weeks. The business prioritizes features. - Roles include the Product Owner who manages the product backlog, Scrum Master who facilitates the process, and cross-functional team. - Artifacts include the product backlog, sprint log/burndown chart, task board, and velocity/capacity metrics. - Activities include sprint planning, daily stand-ups, sprint demo/review, and retrospective meetings. Definitions of ready, done are established along with team values.

1. Scrum Process Overview
Thien Nguyen – May 2016
thiennv1211@gmail.com

2. Agile Methodologies

3. Waterfall vs Agile

4. What is Scrum?
• Scrum is an agile process that allows us to focus on delivering the
highest business value in the shortest time
• It allows us to rapidly and repeatedly inspect actual working software
(every two weeks to one month).
• The business sets the priorities. Teams self-organize to determine the
best way to deliver the highest priority features.
• Every two weeks to a month customer can see real working software
and decide to release it as is or continue to enhance it for another
sprint

5. Why is it called Scrum?

6. Scrum Overview

7. Scrum Overview (cont)

8. Project Road Map

9. To Start Up
Sprint 0: To “setup” a project or product, to do non-functional work

10. Scrum Roles

11. Scrum Roles (cont)

12. Product Owner
• Define the features of the product
• Managing and prioritizing the Product Backlog
• Decide on release date and content
• Be responsible for the profitability of the product
• Adjust features and priority every iteration, as needed
• Accept or reject work results

13. Scrum Master
• Responsible for enacting Scrum values and practices
• Ensures that the process is followed
• Removes impediments
• Ensure that the team is fully functional and productive
• Shield the team from external interferences

14. Scrum Team
• Typically 5-9 people
• Cross-functional:
Programmers, testers, user experience designers, etc.
• Members should be full-time
• Development to achieve sprint goals

15. Artifact
• The Product Backlog
• Sprint log
• Sprint Burndown Chart
• Task Board
• Velocity
• Capacity

16. The Product Backlog
User Story
 Description:
As a <user role> I want to be able to <user wish/goal>,
so that I can <business value>
 Business Acceptance Criteria
 Current and Suggested Mock-up Screens
 Workflows

17. Sprint log - MS Excel

18. Scrum Log - Jira

19. Scrum Log - TFS

20. Sprint Burndown Chart

21. Task Board

22. Velocity
Velocity is the number of story points completed by a
team in an iteration
The velocity can be estimated as the average, over several
recent sprints, of the sum of the estimates for the amount of
work completed by a team per sprint — so in the chart
above, the velocity = (37 + 47 + 50 +57) / 4 = 48. A team's
recent velocity can be useful in helping to predict how much
work can be completed by the team in a future sprint

23. Capacity

24. Scrum Activities
• Release Planning (Grooming)Meeting
• Sprint Planning Meeting
• Daily Meeting
• Sprint Demo/Review Meeting
• Sprint Retrospective Meeting
• Ad-hoc meeting

25. Release Planning meeting

26. Release Planning meeting (cont)

27. Sprint Planning Meeting

28. Sprint Planning Meeting (cont)
• Product Owner
Present the Sprint goal and the highest priority Product Backlog.
Review and clarify each item.
Break each big story into smaller stories and clearly defined acceptance
criteria.
• Team
Break-down each user story to tasks
Estimate for each task.
Commitment to complete the tasks.
Update to sprint backlog

29. Sprint Planning Meeting (cont)
Agreement what will be done in the sprint

30. Planning Poker
• https://www.planningpoker.com
• Card set
Fibonacci ( 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ?, Pass,
Break )
Modified Fibonacci ( 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100,
?, Pass, Break )
T-shirts ( xxs, xs, s, m, l, xl, xxl, ?, Pass, Break )
Powers of 2 ( 0, 1, 2, 4, 8, 16, 32, 64, ?, Pass, Break )
Others custom pointing scale

31. Daily Meeting

32. Daily Meeting (cont)
Meet everyday to check the progress
• Every one answer 3 questions

33. Sprint Demo/Review Meeting

34. Sprint Demo/Review Meeting (Cont)

35. Sprint Retrospective Meeting

36. Sprint Retrospective Meeting (cont)
• To check:
What went well during the last sprint?
What went wrong during the last sprint?
What could be improved in the next sprint?
Action need in the next sprint
• Lessons Learnt and Best Practice Log
To record during the project that can be usefully applied to other projects. As
a minimum it should be updated at the end of each stage in the project.
 The Root Cause should explain why it happened, and the Lesson Learned
should specify whether it was something that ‘worked well’, or identified as
an ‘area for improvement’.

37. Sprint Retrospective Meeting (cont)
• Lessons Learnt
ID Area Description of Event/Situation Root Cause Lesson Learned
1
2
3
ID Process Area Description of Event/Situation Best Practice
1
2
3
ID Action Description Owner Due date
1
2
3
• Best Practice
• Action Need

38. Define for project
• Definition Of Ready
• Definition Of Done
• Sprint Acceptance Criteria
• Team Values
• Jira issue types Hierarchy
(epic, story, task)

39. Definition Of Ready
I Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
V Valuable A user story must deliver value to the end user. (vertical slicing)
E Estimable The development team has to be able to estimate the size of a user story.
S Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T Testable The user story or its related description must provide the necessary information to make test development possible (acceptance criteria).

40. Definition Of Done
• User Story
 User story is provided or approved by Product Owner and they have to be based-line
 Selected User Story for the sprint is completed and understood by the team
 Tasks for selected user stories have been identified and estimated by the team (with consult by Technical lead)
 Technical Design Document is completed with respect to product theme and understood by the team (depends on user story)
 Technical Design Document is approved by Technical Lead (and stakeholders) and it have to be based-line (depends on user story)
 Code meets Coding Standard (e.g. as defined in Code Review Check list)
 Code is peer reviewed (or Technical lead reviewed) and checked in to SVN
 Code checked in there's no build errors on build server and not break any others existing code
 Code merged to another branch in case of enhancement or bug fix (depends on development process and source control tool used)
 Unit tests are written and executed to make sure that the code is covered and all unit test cases are passed (defined by the team in sprint
planning)
 All test cases of the User Story are executed and passed
 Integration tests of the affected areas are conducted and passed
 All acceptance tests of the User Story are met
 Non-functional requirement fulfilled (browser capabilities, scalability, reliability, security etc..).
 All Tasks and sub tasks are set to done or removed
 Remaining hours for story set to zero
 Necessary Documentation is updated and completed such as design document, installation guide, ...

41. Definition Of Done (Cont)
• Sprint
Installed demo system for review
The Acceptance Criteria for the Sprint is met
The sprint must be accepted by the product owner
Release package is based-line
Release documentation is updated and completed such as Release note,
Product installation guide, User manual, ...

42. Sprint Acceptance Criteria
• All test cases of each
user story are passed
• There are no Critical
or Major bugs
• Define number of
opened bugs before
release to customer
Type of defect Description
Sprint 1
Blocker/ Critical Showstopper - An error that makes the whole or a significant part of the
application inoperable or otherwise has a significant effect upon Customer's
business.
Tester cannot proceed with any tests e.g. system crash
0
Major An error that has a material effect upon the functionality, performance or user
experience of the application function upon which Customer relies for the
efficient conduct of its business.
Tester can-not proceed with any tests in a functional area
0-1
Normal A major error (as defined above) that has an acceptable work around OR
An error that has a nominal effect upon the functionality or performance of the
application function upon which Customer relies for the conduct of the
business. Does not stop testing - but limits it e.g. data validation wrong
0-2
Minor A minor or cosmetic error that and that causes a minimal effect upon the
Customer's business.
e.g. screen spelling or error message wrong
0-3

43. Team Values
• Trust communication
• Respect team mate and do not take critic personal
• Think careful before saying something
• Respect lunch time
• Teamwork and support, sharing knowledge
• On time for meeting, delivery
• Never do deployment on Friday or before holidays
• Questions and open discussion for un-clear things
• Quality and performance
• Work progress and tasks information updated

44. Jira issue types Hierarchy (epic, story, task)

45. Jira issue types Hierarchy (epic, story, task) (cont)