Agile Scrum Mastery 

Notes For PSM1

PSM1 Certification Checklist The Increment

About The PSM1 Exam The Definition of Done
Introduction to Scrum The Developers
The Scrum Team The Time-Box
The Product Owner Sprint Planning
Scrum Artifacts The Sprint Backlog
The Product Backlog Daily Scrum
The Product Goal The Sprint
The Scrum Master The Sprint Review
The Sprint Goal The Sprint Retrospective
 

PSM1 Certification Checklist

Step 1​ - Print out...
❏ ​The Scrum Guide
❏ T
​ he Scrum Glossary

❏ PMS1 Certification Notes (this document)

Step 2
❏ Watch all lectures in this course. Those with [Not For PSM1] in the title are optional

Step 3
❏ Complete all quizzes in the course

Step 4
❏ Watch all ‘PSM1 Notes’ lectures right after each quiz e.g. ‘Notes: Introduction to Scrum’

Step 5
❏ Complete all practice exams and assignments in this course. Practice, practice, practice...

Step 6
❏ You’re ready to Ace the PSM1 Exam
 
About The PSM1 Exam

1. Exam length is ​1 hour​.

2. You have to answer ​80 questions​.

3. Pass score is ​85%​ i.e. get 68

questions correct

4. It is an ​“open book”​ exam.

5. No expiration ​(Lifetime Certificate).

6. It costs ​$150 per attempt​.

 

Introduction to Scrum

1. “Scrum is a ​lightweight framework​ that helps people, teams and organizations ​generate
value​ through adaptive solutions for complex problems.” - ​Scrum Guide 2020

2. Scrum is ​intentionally incomplete​ i.e. it has to be complemented with other processes

3. Scrum must be ​implemented in its entirety​. Otherwise it cannot be called Scrum.

4. Scrum is based on ​empiricism​ and ​lean thinking

5. Scrum relies on the ​3 empirical pillars​: 1) Transparency 2) Inspection, and 3) Adaptation.

6. The​ ​Five Scrum Values​ ​are 1) Commitment 2) Courage 3) Focus 4) Openness, and 5)
Respect

7. The decisions that are made, the steps taken, and the way Scrum is used ​should reinforce
the Five Scrum Values, ​not diminish​ or undermine them.
 
Introduction to Scrum

8. The​ ​Five Scrum Events​: 1) Sprint Planning 2) The Sprint 3) Daily Scrum 4) Sprint Review
and 5) Sprint Retrospective

9. Scrum is built upon the ​collective intelligence​ of the people using it

10. While Scrum has roots in software product development, it can be ​used in many other
domain areas​ where complex work is done in an uncertain environment.

11. Both Scrum & Agile use an ​incremental​ and ​iterative​ approach to development
a. Incremental​ - “Let’s build ​some of it​ before we build all of it”
b. Iterative​ - In one iteration (Sprint), we go through ​all of the development processes​ to
create a usable increment

12. Plan-Driven Development (Waterfall) is about creating ​one huge increment with one
huge iteration
 

The Scrum Team

13. The fundamental unit of Scrum is ​a small team of people​: the Scrum Team.

14. There are ​3 accountabilities​ in Scrum

a. The Developer
b. The Scrum Master
c. The Product Owner

15. Accountabilities are ​not job titles​ but an area of responsibility e.g. a Finance Manager
could be a “Developer” in a Scrum Team.

16. Scrum Teams are ​Cross Functional & Self Managing

17. Scrum Teams are typically ​10 or fewer people

a. If the team grows too large, we have to consider reorganizing into smaller teams

18. There can be multiple Scrum Teams working on a Product, but only ​one Product Owner
working on a Product. The general rule to remember is:
1 Product = Only 1 Product Owner + Only 1 Product Backlog + Only 1 Product Goal
 
The Scrum Team

19. There is only 1 team in Scrum (The Scrum Team) & ​no sub-teams or hierarchies​.

20. The entire Scrum Team is responsible for ​all product related activities​ including:
a. Stakeholder collaboration
b. Verification
c. Maintenance
d. Operation
e. Experimentation
f. Research & Development
g. Etc..

21. The Scrum Team can ​release as many times as they want​ during the Sprint.

22. “​The entire Scrum Team is accountable for creating a valuable, useful Increment every
Sprint” - ​The Scrum Guide

23. The Scrum Team creates The ​Sprint Goal

24. The Scrum Team creates the “​Definition of Done​”,

 

The Product Owner

25. The Product Owner (PO) is ​accountable​ for

a. Maximizing the Value​ ​of the Product

b. Effective ​Product Backlog Management​ which includes

i. Creating and communicating a ​Product Goal

ii. Creating and explaining ​Product Backlog Items ​(PBIs)
iii. Ordering the Product Backlog Items
iv. Making sure the Product Backlog Items are ​transparent

26. The PO may ​delegate​ Product Backlog work to others, but he/she ​remains accountable​.

27. Anyone who wants to change the Product Backlog will have to first ​convince the PO

28. The PO is ​always one person​, never a committee

29. PO can only succeed if everyone in the organization ​respects his/her decisions
The Product Owner

30. Only the PO can ​cancel the Sprint​.

31. The PO is the ​expert on the marketplace​ for the Product

32. During Sprint Planning, the ​PO brings a business objective​, based on which the Scrum
Team crafts a Sprint Goal

33. There can only be ​one PO for a product​. But ​a PO can work on multiple products​.

34. During Sprint Review, the PO ​seeks feedback​ from key stakeholders

35. A PO can also ​work as a developer​ ​on the team

36. The PO can attend, but ​cannot “participate” in Daily Scrum meetings​, except in the
capacity as a developer

37. The PO can attend but ​cannot participate in any PBI sizing​ (estimation) activities e.g.
during Sprint Planning
 
Scrum Artifacts
38. There are ​3 Scrum Artifacts​:
a. The Product Backlog
b. The Sprint Backlog
c. The Increment

39. Each Scrum Artifact ​contains a commitment​ to ensure it provides information that
enhances transparency and focus.
a. For the ​Product Backlog​, it is the ​Product Goal​.
b. For the ​Sprint Backlog​, it is the ​Sprint Goal​.
c. For the ​Increment​, it is the ​Definition of Done​.

40. The three commitments are ​mandatory​.

41. The PO works with the Scrum Team and ​creates the Product Goal​.
a. The ​PO is accountable​ for the Product Goal.

42. The entire Scrum Team creates and is accountable for the Sprint Goal.

43. The entire Scrum Team creates and is accountable for the Definition of Done
 
The Product Backlog
44. The Product Backlog (PB) is an ​ordered list​ of what is needed to improve the product.

45. The PB is the ​single source of work​ undertaken by the Scrum Team

46. Product Backlog Items (PBIs) that can be ​completed in 1 Sprint​ are considered ​“ready”
for selection for a Sprint during Sprint Planning

47. The Product Owner orders the PB in a way to ​maximize product value

48. The Product Backlog will exist ​as long as the Product exists​. It is ever-changing and
dynamic

49. Product Backlog refinement is the ​act of breaking down​ and further defining Product
Backlog items into ​smaller more precise items​. This includes adding detail such as:
a. Description
b. Order
c. Size
d. Etc
The Product Backlog

50. PBI attributes (e.g. description, order) often ​vary depending on the domain of work

51. PBI’s on the top of the PB are ​more refined and hence smaller​ than PBI’s at the bottom.

52. The Product Backlog can be refined ​at any time as needed

53. Multiple Scrum teams can ​share the same Product​ ​(and they would then have the same
Product Backlog, Product Owner & Product Goal)

54. Only the Developers can ​determine the size​ (estimate effort involved) for Product
Backlog Items

55. Product Backlog Refinement is an ​ongoing activity​ done by the ​PO and the Developers

56. “A Product is a ​vehicle to deliver value​. It has a clear boundary, known stakeholders,
well-defined users or customers. A product could be a service, a physical product, or
something more abstract.” - Scrum Guide 2020
 
The Product Goal

57. The Product Goal describes ​a future state​ of the Product. It is the ​long term objective
for the Scrum Team.

58. The Scrum Team must ​fulfill or abandon​ one Product Goal before taking on another

59. Therefore a Scrum Team can only have ​1 Product Goal at a time

60. The PO is responsible for ​creating​ and ​communicating​ the Product Goal

61. The Scrum Master helps the PO find techniques for ​effective Product Goal definition

62. The increment is a stepping stone ​toward the Product Goal

63. The Product goal is a stepping stone ​toward the broader Product Vision

64. The Product Goal should be ​measurable​. The team should know when it's achieved

65. The Product Goal can be changed, but it is ​unlikely to happen during a Sprint

66. Progress ​toward the Product Goal​ is discussed with stakeholders during Sprint Review
 
The Scrum Master

67. The Scrum Master (SM) is accountable for:

a. Establishing Scrum​ (as per the Scrum Guide) in the Scrum team and the Organization
b. The Scrum Teams ​effectiveness

68. The SM is a ​true leader​ ​who serves:

a. The Scrum Team by:
i. Causing the ​removal of impediments​ to the Scrum Team's progress
ii. Ensuring that all Scrum events that take place and are ​positive, productive, and
kept within the timebox

b. The Product Owner by:

i. Helping find techniques for effective ​Product Goal Definition​ & ​Product Backlog
Management
ii. Facilitating ​stakeholder collaboration​ as needed.

c. The Organization by:

i. Leading, coaching & training​ them on Scrum adoption
The Scrum Master

69. If the SM (or PO) is ​actively working on PBIs​ in a Sprint, they do so as “​ developers”

70. The SM acts as a team coach and teacher. They manage ​not the people but the
process​.
a. They possess what’s called “​Process Authority​” and make sure everyone understands
and embraces the Scrum theory, values, rules, and practices

71. The Scrum Master is ​NOT a Project Manager

a. A Project Manager role does not exist in Scrum

72. The SM can work ​part-time​ as well as full-time

73. Scrum doesn’t prohibit one person to act as a ​SM and a PO​ but it doesn’t recommend it
either.

74. The SM can work on ​multiple Products & Product Teams

 
The Sprint Goal

75. The Sprint Goal is a ​Single Objective​ ​for the Sprint

76. The Developers ​make a commitment​ to delivering the Sprint Goal

77. While the Sprint Goal is a commitment by the Developers, it provides ​flexibility on the
exact work​ needed to achieve the goal

78. The Sprint Goal is ​set by the Scrum Team​ during Sprint Planning and then a
​ dded to the
Sprint Backlog

79. The PO and the Developers may ​negotiate the scope​ of the Sprint ​without affecting​ the
Sprint Goal

80. The PO can cancel a Sprint if he/she decides the Sprint Goal is no longer valid. ​Only the
PO​ is allowed to cancel the Sprint
 
The Increment

81. An Increment is a ​stepping stone​ toward the Product Goal

82. Each Increment is ​additive​ to all prior increments

83. The ​sum of all Increments​ is presented to Stakeholders at the Sprint Review. However,
Increments can be released to Stakeholders ​at any time

84. The Scrum Team has to create ​one or more useful​ Increments each Sprint

85. All Increments must be ​verified and usable

86. The ​whole Scrum Team​ decides when to release an Increment.

87. Multiple increments​ can be released to stakeholders during a Sprint

88. Work ​cannot ​be considered part of an Increment unless it meets the Definition of Done
(DoD)

89. The ​commitment​ for the Increment is the ​DoD

 
The Definition of Done

90. “The Definition of Done (DoD) is a formal description of the ​state of the Increment when
it meets the quality measures​ required for the Product”. - The Scrum Guide 2020

91. The moment ​a PBI meets the DoD​, an Increment is born

92. The DoD is ​mandatory​ and it increases ​transparency

93. If DoD is part of organizational standards, the Scrum Team must follow it ​as a minimum

94. If DoD is not part of organizational standards, the Scrum Team ​must create one​ that is
appropriate for the Product

95. PBI’s that do not meet the DoD ​cannot be released, or presented​ at the Sprint Review

96. If multiple Scrum Teams are working on the same Product, they ​must mutually define
and comply with​ the same DoD for the integrated increment

97. The DoD is not the same as Acceptance Criteria. DoD applies to ​all PBIs​ whereas
Acceptance Criteria are written for ​each PBI
 
The Developers

98. The Developers are the people in the Scrum Team who ​create any aspect​ of a usable
increment during the Sprint.

99. The specific skills of the Developers will ​vary a lot ​depending on the domain of work i.e.
they ​do not have to be software developers​, but could be scientists, researchers,
manufacturing etc.

100. The Developers ​create the plan​ for the Sprint, this is the Sprint Backlog.

101. The Developers choose ​how many PBIs​ need to be included in a Sprint.

102. They are responsible for ​sizing (estimating) the PBIs​ ​and the techniques they would use
to turn PBIs into a usable increment

103. Developers ​participate in Daily Scrum​ and come up with an actionable plan for the day

104. Developers are ​required​ to conform to the DoD (Definition of Done)

105. The Developers hold ​each other accountable​ as professionals

 
The Time-Box

106. Scrum Events are ​Timeboxed​ ​i.e. they have a ​maximum duration​ not to be exceeded

107. A Sprint can be a ​maximum of 1 month​ ​and a ​minimum of 1 week

108. Scrum Teams ​choose the length​ of the Sprint

109. For a 1 month Sprint

a. Sprint Planning = ​8 hours
b. Sprint Review = ​4 hours
c. Sprint Retrospective = ​3 hours
d. Daily Scrum is always ​15 minutes

110. When a Sprint is less than 1 month, the other events are ​usually proportionately
shorter​, but this is not a requirement

111. All Events can vary in length based on the length of the Sprint, ​except the Daily Scrum

112. All Scrum Events, besides the Sprint, ​can end early​ when the ​purpose of the event is
achieved.
 
Sprint Planning

113. During Sprint Planning, the PO ensures that attendees are prepared to discuss ​the most
important PBIs​ and how they ​map to the Product Goal

114. During Sprint Planning we answer three important questions: ​a) Why is this Sprint
Valuable? 2) What can be done this Sprint? 3) How will the chosen work get done?

115. The ​entire Scrum Team​ attends and collaborates on creating the Sprint Goal

116. The Developers decide ​how many PBIs​ to select for the Sprint Backlog

117. The Developers decide on the ​practices to use​ to turn PBIs into a usable increment

118. The more the Developers know about ​their past performance, upcoming capacity, and
the DoD​, the more accurate forecasts they would be able to do

119. The Sprint Backlog is created during Sprint Planning and it is ​a combination of 3 things.
i) The Sprint Goal ii) the selected PBIs, and iii) a Plan to deliver them

120. The Scrum Team ​may invite other people​ to attend Sprint Planning to provide advice

121. Sprint Planning is ​8-hours for a 1-month Sprint​ and ​usually shorter​ for shorter Sprints
 
The Sprint Backlog

122. The Sprint Backlog (SB) consists of 3 things:

a. The Sprint Goal (which is ​the why​)
b. The selected PBIs (which is ​the what​)
c. The Plan for delivering the Increment (which is ​the how​)

123. The SB is a plan ​by and for the Developers

124. The SB should be ​highly-visible​ ​i.e. transparent

125. The SB ​changes during the Sprint ​(BUT the Sprint Goal does not)

126. The PO and the Developers ​may change/negotiate the scope​ of the Sprint but this
should not affect the Sprint Goal in any way

127. We move the incomplete items ​back to the Product Backlog​ for future considerations.
 
Daily Scrum

128. The purpose of the Daily Scrum is to ​inspect progress​ towards the Sprint Goal ​and
adapt​ ​the Sprint Backlog if needed

129. Daily Scrum is for Developers. It is ​mandatory for all Developers​ of the Scrum Team

130. The SM ensures that Daily Scrum​ takes place, and is kept to 15 minutes​, but the
Developers are responsible for conducting the event

131. During Daily Scrum, the Developers ​plan the work for the next day

132. The SM and PO are allowed to ​attend but not participate​ in Daily Scrum

133. The SM and PO can participate in Daily Scrum ​as “Developers”​ if they are actively
working on Sprint Backlog Items

134. Daily Scrum is ​always 15 minutes​ regardless of Sprint length and number of Developers
Daily Scrum

135. Daily Scrum is held at the ​same time and place​ every working day of the Sprint to reduce
complexity and eliminate waste

136. Developers ​choose the structure​ of the Daily Scrum event

137. The focus of the event should be:

a. “​Progress towards​ the Sprint Goal”
b. “An ​actionable plan ​for the next day”

138. Daily Scrums...

a. Improve ​communications
b. identify ​impediments
c. promote ​quick decision-making
d. reduces​ the need for other meetings

139. The developers are ​allowed to adjust their plan​ to achieve the Sprint Goal ​outside
Daily Scrum​ as well. Often, they meet throughout the day for more detailed discussions.
 
The Sprint

140. “Sprints are the ​heartbeat of Scrum​, where ideas are turned into value.” - Scrum Guide

141. The purpose of the Sprint is to create ​usable increments​. A Sprint is like a ​small project

142. A new Sprint begins ​immediately after​ the previous one ends

143. A Sprint is ​one month or shorter​ in length

144. The Sprint is a ​container for all the other Events​. All the work necessary to achieve the
Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint
Retrospective, ​happen within Sprints

145. When ​risk is higher, shorter Sprints​ are preferred, to generate more learning cycles

146. A Sprint can be canceled when the Sprint Goal becomes obsolete ​by the Product Owner

147. Sprint cancellation is ​bad for the team​, and it requires regrouping of the team, a new
Sprint Planning event, as a result, resources are lost

148. During the Sprint ​quality goals do not decrease​, but scope might be re-negotiated
 
The Sprint Review

149. The purpose of the Sprint Review event is to i​nspect the outcome​ of the Sprint and
determine future adaptations​. The Scrum Team presents the results of their work to key
stakeholders and ​progress​ toward the Product Goal is discussed

150. Attendees of the Sprint Review event are the ​Scrum Team and key stakeholders

151. Sprint Review is ​not just a demo or a presentation​ of the increment

152. The Scrum Team only presents items that are ​100% done according to the DoD

153. If a customer routinely skips this event, the expectations of the Scrum Team and the
customer ​would become misaligned​ and both parties would not be happy

154. The Product Backlog may also ​be adjusted​ to meet new opportunities

155. The Sprint Review is a ​4-hour event for a 1-month Sprint​. For shorter Sprints, it's
usually shorter
 
The Sprint Retrospective

156. The main purpose of the Sprint Retrospective is to plan ways to ​increase quality and
effectiveness

157. The Scrum Team inspects how the last Sprint went with regards to ​individuals,
interactions, processes, tools, and their Definition of Done

158. It is a ​3-hour event for a 1-month Sprint​. For shorter Sprints, it’s ​usually shorter

159. It is an opportunity to ​inspect and adapt​ the process the Scrum Team has been using to
build the increments

160. The ​whole Scrum Team​ attends the event

161. During the Sprint Retrospective, we examine ​how we build the product, not the product
itself