Introduction to Scrum Framework

1. Introduction to
SCRUM
Md. Mojammel Haque
CSP, CSD, CSPO, CSM- Scrum Allience

6. Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

7. Agile Principles

8. #1: Customer satisfaction by rapid delivery
of useful software

9. #2: Welcome changing requirements, even
late in development

10. #3: Working software is delivered
frequently

11. #4: Close, daily cooperation between
business people and developers

12. #5: Projects are built around motivated
individuals, who should be trusted

13. #6: Face-to-face conversation is the best
form of communication (co-location)

14. #7: Working software is the principal
measure of progress

15. #8: Sustainable development, able to
maintain a constant pace

16. #9: Continuous attention to technical
excellence and good design

17. #10: Simplicity—the art of maximizing the
amount of work not done—is essential

18. #11: Self-organizing teams

19. #12: Regular adaptation to changing
circumstance

20. Introduction to SCRUM

21. What is SCRUM?
Scrum is an Agile framework for developing,
delivering and sustaining complex products.
Scrum is Iterative & Incremental method
Scrum is
Lightweight
Simple to understand
Difficult to master

22. What SCRUM Follows
Empirical Process Control theory i.e. knowledge
comes from experience & makes decision based on
what is known.

23. Values of SCRUM
Commitment
Courage
Focus
Openness
Respect
When they are embodied and lived by the Scrum Team,
the Scrum pillars of transparency, inspection, and
adaptation come to life and build trust for everyone.
The Scrum Team members learn and explore those values
as they work with the Scrum roles, events, and artifacts.

24. History of SCRUM
Scrum formalized in 1990 by Jeff Sutherland & Ken Schwaber

25. What is Scrum being used for?
Commercial software
In-house development
Fixed-price projects
Financial applications
ISO 9001-certified applications
24x7 systems with 99.999% uptime requirements
Video game development
US FDA-approved software for X-Rays, MRIs
Satellite-control software
Websites, Mobile phones
Network switching applications
Large database applications
CMMi organizations
Multi-location development
Non-software projects

26. Scrum has been used by-
Microsoft
Yahoo
Google
Electronic Arts
High Moon Studios
Lockheed Martin
Philips
Siemens
Nokia
Capital One
BBC
Intuit
First American Real Estate
BMC Software
Ipswitch
John Deere
Lexis Nexis
Sabre
Salesforce.com
Time Warner
Turner Broadcasting
Oce
Intuit
Nielsen Media

27. Disadvantages of SCRUM
SCRUM is hard!
Makes all dysfunction visible
Scrum doesn’t fix anything: the team has to do it
Feels like things are worse at the beginning
Bad product will be delivered sooner and doomed projects will
fail faster
Some teams and organizations are not right or ready for it
Team willingness, capabilities
Management
Risk of turnover during adoption
Some people will refuse to stay on a Scrum team
Some people will refuse to stay if Scrum is abandoned
Partial adoption may be worse than none at all

28. Foundations of SCRUM
The heart of SCRUM is “Sprint”- a time boxed which are not
extended
There are 02 artifacts, 03 roles, 04 events are closely related with
the Sprint.

29. SCRUM Roles- The Product Owner

30. SCRUM Roles- The Product Owner
Responsible for the overall project vision and goals
Responsible for managing project ROI vs. risk
Responsible for managing Product Backlog
Clearly express the product backlog items
Ordering the items based on their priorities
Ensures backlog items visible, transparent and clear to
all
Ensures development team understands the items of
backlog to the level as needed.
Participates actively in Sprint Planning and Sprint Review
meetings, and is available to team throughout the Sprint
Determines release plan and communicates it to upper
management and the customer

31. SCRUM Roles- The Development Team

32. SCRUM Roles- The Development Team
Responsible for delivering a potentially releasable
increments of “Done” product at the end of the sprint
Self Organizing
Team manages itself to achieve the Sprint commitment
Cross Functional
All the skills as a team necessary to create a product
Increment
Team takes on tasks based on skills, not just official “role”
Size should be of 6 persons, + or -3
Can be shared with other teams (but better when not)
Can change between Sprints (but better when they don’t)
Can be distributed (but better when co-located)

33. SCRUM Roles- The Scrum Master

34. SCRUM Roles- The Scrum Master
Servant-leader for the team.
Does everything to help the team achieve success
including-
Serving the Team
Protecting the Team
Guiding the team’s use of SCRUM

35. Scrum Master- Serving the team
Takes action to help remove impediments to the team’s
effectiveness.
Facilitates the team’s group interactions, to help the team
achieve its full potential
Coaches the team, to help them improve their practices
and effectiveness

36. Scrum Master- Protects the Team
Protects the team from
anything that threatens its
effectiveness, such as
outside interference or
disruption
Deal with uncomfortable
issues, both inside and
outside the team

37. Guiding the team’s use of Scrum
Teaches Scrum to the team and organization
Ensures that all standard Scrum rules and practices are
followed
Organizes all Scrum-related practices

38. Difference between Boss & SM

39. The Servant Leader

40. What happens to the “Project Manager” in SCRUM?

41. Transforming “Project Manager” to …..
There is no such role is scrum where we can have a project
manager.
We need to transform our traditional project managers to
Scrum Master (Highly risk involved as the intention of
managing the team will be there)
Product Owner
Team Member (Hard to adjust as a member of the
team)

42. Starting SCRUM

43. Product Backlog

44. Product Backlog
Product Owner lists items
in descending order of
priority (highest priority
item is listed first, next-
highest is second, etc.)
Size estimates are rough
estimates (can either be
arbitrary “points”, or
“ideal days”)

45. Product Backlog
List of everything that could ever be of value to the business for the
team to produce
Ranked in order of priority
Priority is a function of business value versus risk
Product Owner can make any changes they want before the start of
a Sprint Planning Meeting
Items added, changed, removed, reordered
How much documentation is up to the team and Product Owner to
decide
The farther down the list, the bigger and less defined the items
become
~2 Sprints worth are defined in detail

46. User Stories
User Stories are a good approach for writing
Product Backlog Items
User Stories are a short, plain-language
description of the functionality, in terms of the
customer benefit and need

47. Good Format of User Stories
As a …..
I want …..
So that …..

48. Examples of well formatted user stories
“As a customer, I can place an item on my wish-
list, so that I can decide later whether or not I
want to buy it”
“As a frequent flyer member, I can see the
number of miles I have earned in my frequent
flyer account, so that I can decide whether to
redeem them for a ticket”
“As a new user, I can set up a profile so that
potential employers can find out more about
my skills and qualifications”

49. Epics
Larger user stories are referred as Epic.
Epics generally take more than one or two
sprints to develop and test. They are usually
broad in scope, short on details, and will
commonly need to be split into multiple,
smaller stories before the team can work on
them.

50. Themes
A theme is a collection of related user stories
A user Story can belong to one or more themes.
An Epic can be sliced into several stories. One way
to remember that all of these sliced stories is
related is to say that they belong to a particular
theme

51. Tasks
An user story can be further sliced further tasks
like-
UI Design
Database Design
Server side Business logic implement
Client side Business logic implement etc.
Tasks are generally contains by “Sprint
Backlog”

52. INVEST in Good Stories and SMART Tasks
Stories should be-
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
Tasks should be-
S – Specific
M – Measurable
A – Achievable
R – Relevant
T – Time-boxed

53. How to Set the Story point (Est. Size of Story)
Planning Poker
First of all team should agree a story (from backlog
item) as “baseline” or “benchmark” and give it a
size e.g.- 5
Size = Effort x Complexity x Uncertainty

54. How to Set the Story point (Est. Size of Story)
Planning Poker
Team will given / create cards with following
values-

55. How to Set the Story point (Est. Size of Story)
Planning Poker
1. Product owner will pick a story from backlog and ask
the team to estimate it’s size in respect of already
estimated story
2. Each person will decide their cards at the same time. In
this case no one will share his/her number with other.
This is very secret.
3. Everyone will show their card at once when Scrum
Master will says “1-2-3-show”
4. If estimates vary significantly then high and low
estimators will explain briefly why
5. Repeat step 2-4 until estimates stop converging
6. Decided estimates are the size of Backlog item
7. Move to next backlog item

56. How to Set the Story point (Est. Size of Story)
Planning Poker

57. Estimated Size / Story Point of Product Backlog

58. Sprint Planning Meeting

59. Sprint Planning Meeting
Takes place before the start of every Sprint
Team decides how much Product Backlog it will commit to
complete by the end of the Sprint, and comes up with a plan
and list of tasks for how to achieve it
What’s a good commitment?
Clearly understood by all
Shared among the team
Achievable without sacrificing quality
Achievable without sacrificing sustainable pace
Attended by Team, Product Owner, Scrum Master,
Stakeholders
May require
2 hours for each week of Sprint duration
2 week Sprint = 4 hours,
4 week Sprint = 8 hours

60. Sprint Planning Meeting (Cont.)
Sprint Planning Meeting further divided into two parts-
Sprint Pre-Planning Meeting
Sprint Planning Meeting
Sprint Pre-Planning Meeting
Team understands the details of what the Product
Owner has prioritized on the Product Backlog
Team Set the Size of each Story
Sprint Planning Meeting
Team decides how much productive time it has available
during the Sprint
Team decides how many Product Backlog items it can
commit to complete during the Sprint

61. Sprint Pre-Planning Meeting
Should take place 2-3 days before the actual sprint
planning meeting
Team must understand the prioritized items by product
owner and ask for clarification if required
Provide rough estimation for new items
Calculate team’s available days, hours etc.
The Dev Team, Product Owner, and ScrumMaster look
ahead to upcoming Product Backlog Items (or User Stories)
coming in the next 2-3 Sprints
They split larger items into smaller slices – ideally, small
enough that 1-2 people could completely finish them in 3-4
days (“1-2-3-4”)
They start to get a more detailed understanding of the
requirements for these upcoming Product Backlog Items
No fixed format, timing, or timebox: try a 2-3 hour session
for Dev Team, Product Owner and ScrumMaster

62. Sprint Cycle- 2 Weeks Sprint

63. Sprint Cycle- 4 Weeks Sprint

64. Available Time during Sprint
*Net holidays & other days out of the office

65. Available Hours Per day
Different members can have different responsibilities. Based on those differences
approximate available hour per day calculation-

66. Available Hours Per day

67. Available Hours Per day

68. Available Hours Per day

69. Available Hours Per day

70. Definition of Done (DoD)
Definition of Done (DoD) has been described as a tool for bringing
transparency to the work a Scrum Team is performing.
It is related more to the quality of a product, rather than its functionality.
The DoD is usually a clear and concise list of requirements that a software
Increment must adhere to for the team to call it complete. Until this list is
satisfied, a product Increment is not done.
During the Sprint Planning meeting, the Scrum Team develops or reconfirms
its DoD, which enables the Development Team to know how much work to
select for a given Sprint.
The Definition of Done is not changed during a Sprint, but should change
periodically between Sprints to reflect improvements the Development Team
has made in its processes and capabilities to deliver software.

71. Demo of DoD

72. Demo of DoD

73. Demo of DoD

74. Creating Sprint Backlog
Team will break an Story into Multiple Tasks
Estimate the effort/time of each task
Here Volunteer means the member who will complete the task.

75. Sprint Planning Ends when…
Team’s available time is mostly committed
Good idea to go through and make sure there’s full
agreement on the commitment
After the meeting, Scrum Master turns the task list into
the Sprint Backlog

76. The Sprint is Begin

77. Daily SCRUM

78. Daily SCRUM
Purpose of Daily Scrum Meeting
Keep team coordinated and up-to-date with each other
Surface impediments daily
How it works
Every weekday
Whole team attends
Team chooses a time that works for everyone
Product Owner can attend, but doesn’t speak
Everyone stands in a circle, facing each other (not facing the SM)
Lasts 15 minutes or less
Everyone reports 3 things only to each other
What was I able to accomplish since last meeting
What will I try to accomplish by next meeting
What are my blocks / problems / difficulties
No discussion or conversation until meeting ends

79. Daily SCRUM- Not Allowed

80. Daily SCRUM- Perfect Standup

81. Update Sprint Backlog
After the Daily Scrum, team members update the
hours remaining on the Sprint Backlog
Also moves cards on the visual task board

82. Update Sprint Backlog
After the Daily Scrum, team members update the
hours remaining on the Sprint Backlog
Also moves cards on the visual task board

83. Update Sprint Backlog
*. Column 1,2,3,4,5,6 indicates days of the sprint.
*. Value of those columns i.e. 4,3,0 etc. indicates how much time remaining to complete
the task.

84. Burn-down Chart
Show the teams progress visually through a Chart.

85. Task Board

86. Task Board

87. Task Board

88. Task Board

89. Task Board

90. Task Board

91. Task Board

92. Task Board

93. Some important note (About Task Board)
Use sticky paper on a board or use pin and paper on a
soft board so that items are easy to move
Can assign different color for team members, task type or
themes
Should be visible from a sitting position (for everyone)
Item can move forward or backward
Can be customized to have more than 2 columns

94. What about any changes during the Sprint?

95. No Changes During Sprint
No Changes to the Deliverable
Once team has committed, no changes to the
deliverable
If something major comes up, Product Owner can
terminate the Sprint and start new one
Details and clarifications will emerge during Sprint, but
no new work or substantially changed work
Difference between “change” and “clarification”
“If there’s any doubt, then it’s a change

96. What if a change is required?
Do not allow any changes in current sprint
Move the item for next sprint
Break the sprint and start a new sprint with modified
backlog
Product owner should be responsible for breaking the
sprint or removing items from the sprint

97. The End of Sprint

98. Sprint Review

99. Sprint Review
Purpose of the Sprint Review
Demo what the team has built
Make visible whether the team completed what they set
out to
Generate feedback, which the Product Owner can
incorporate in the Product Backlog
Attended by Team, Product Owner, ScrumMaster,
functional managers, and any other stakeholders
A demo of what’s been built, not a presentation about
what’s been built
No Power-points allowed!
Usually 4 hours for 4 weeks sprint, 2 hours for 2 weeks, 1
hour for 1 week sprint

100. Sprint Retrospective

101. Sprint Retrospective
Occurs after Sprint Review and prior to next sprint
planning
03 hours meeting for one hour sprint, 1.5 hours for two
weeks sprint, 45 minutes for 1 week sprint
Product Owner, Team and Scrum Master will attended
Generally Scrum Master Facilitate the Meeting but if
possible call Neutral Person to Facilitate the Meeting
Discuss about
What’s working
What’s could better
Things try to next sprint

102. Why Retrospective Matter?
Accelerates the Visibility
Accelerates action to improve

103. Good approach of Retrospective
Create 03 large list on a whiteboard
What’s working
What’s could work better
Things to try in the next Sprint
Allow each person to add one or more items to the 3 lists
If people agree with something already on the lists then put a
tick mark next to that
Select a subset from “Things to Try” list and try in the next
sprint. (Scrum Master responsible for tracking this)

104. Good approach of Retrospective

105. Roles-Ceremonies-Artifacts of Scrum

106. Any Question?

107. Thanks