Roadmap To Success - The Ultimate Agile Leader

Introduction Agile Principles & The Scrum Team

(Downloadable Files) Scrum Overview (3 Sets Of Accountabilities)

Scrum Artifacts &

The Scrum Events Agile Leadership
(5 Official Events) Commitments (Scrum)
(3 Artifacts & 3 Commitments)

How To Approach Practice Questions You Get A

The Exam (Exam Simulator) Certificate

A TRADEMARK NOTICE STATEMENT: Scrum.org, Professional Agile Leadership™, PAL I™, PSM™, PSM I™, PSM II™, PSM 1, PSM 2, PSPO, PSPO I, PSPO II, PSPO 2 are trademarks of
Scrum.org and may be registered in the United States Patent and Trademark Office and in other countries. This unofficial course and practice exams are neither endorsed by, nor in
partnership, nor affiliated with Scrum.org or any other organizations.
 A DISCLAIMER STATEMENT

This course and practice exams are neither endorsed by, nor in partnership, nor affiliated with scrum.org™ or any other organizations.

The statements made and opinions expressed herein belong exclusively to the creator of this course and are not shared by or represent the viewpoint of
scrum.org™. This training does not constitute an endorsement of any product, service, or point of view. scrum.org™ makes no representations, warranties, or
assurances of any kind, express or implied, as to the completeness, accuracy, reliability, suitability, availability, or currency of the content contained in this
presentation or any material related to this presentation. In no event shall scrum.org™, its agents, officers, employees, licensees, or affiliates be liable for any
damages whatsoever (including, without limitation, damages for loss of profits, business information, loss of information) arising out of the information or statements
contained in the training. Any reliance you place on such content is strictly at your own risk.

A TRADEMARK NOTICE STATEMENT

Scrum.org™, Professional Agile Leadership™,, Professional Scrum Master™, Professional Scrum Product Owner™, Professional Scrum Developer™, Scaled
Professional Scrum™, Professional Agile Leadership™, Professional Scrum with Kanban™, Professional Scrum Trainer™, Evidence Based Management™, PAL
I™, PSK™, EBM™, EBMngt™, SPS™, PSM™, PSM I™, PSM 1™, PSPO™, PSPO I™, PSPO 1™ are trademarks of scrum.org™ and may be registered in the
United States Patent and Trademark Office and in other countries.

ATTRIBUTION AND USE FOR THE SCRUM GUIDE™, NEXUS GUIDE™, AND EVIDENCE-BASED MANAGEMENT GUIDE™

This course uses screenshots from the Scrum Guide™, Nexus Guide™, and Evidence-Based Management Guide™ to point the attention of the student to important
concepts, ideas, rules, and practices.

The authors of the Scrum Guide™ are Ken Schwaber and Jeff Sutherland.

The Nexus Guide™ is developed and sustained by Ken Schwaber and scrum.org™

Evidence-Based Management™ was collaboratively developed by scrum.org™, the Professional Scrum Trainer Community, Ken Schwaber, and Christina
Schwaber.

No changes have been made to the content of the Scrum Guide™, Nexus Guide™, and Evidence-Based Management Guide™

Licence for the three guides: Attribution Share-Alike license of Creative Commons 2
Agile Leadership Exam (by Scrum.org)
1. The exam length is 60 minutes.
2. You have to answer 36 questions.
3. Three types of questions:
a. Multiple Choice
b. Multiple Answer
c. True/False
4. The passing score is 85%.
5. No expiration (Lifetime Certificate).
6. It costs $200 per attempt.
7. Difficulty: Intermediate.
Agile Principles & Scrum Overview

4
Agile - Part 1
1. The Adaptive Approach to development is known as Agile. The Predictive Approach to development
is known as Waterfall.
2. For IT projects, we prefer Agile because typically we face many unknowns. We deliver value way
faster than Waterfall, and by using a feedback loop, we build what the customer wants and expects.
3. Agile needs frameworks and methodologies that support the Agile concepts and principles, and
this is why we have Scrum, Dynamic Systems Development Method (DSDM®), Extreme
Programming® (XP), Crystal, and more.
4. We do planning in Agile, but we are against detailed upfront plans (which is typical for Waterfall).
5. In Agile and Scrum, we use Iterative and Incremental Development.

5
Agile - Part 2
a. Iterative refers to the development processes (e.g. design, code, integrate, test, and so on). It
means that we go through all the phases in one iteration. In Scrum, we call iterations Sprints.
b. Incremental refers to the fact that we are developing the product incrementally. One increment
at a time. The concept can be explained with a simple sentence: “Let’s build some of it before we
build all of it.”
6. Timeboxing is an agile concept that refers to having a maximum duration of the events.
7. Scrum is the most popular agile framework for developing, delivering, and sustaining complex
products in complex environments.

6
Agile Planning
1. Agile is against detailed upfront plans.
2. In Scrum, we can consider the Product Backlog to be the big plan for the project. And the Sprint
Backlog as a smaller plan for the Sprint.
3. The Product Owner (PO) can reduce waste if they refine items for a few Sprints ahead (for example
2 sprints but that would depend on the Sprint length).
a. Anything more than that could be considered as too much upfront planning.

7
Scrum Overview - Part 1
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 founded on Empiricism and lean thinking”
3. Three pillars uphold Scrum - Transparency, Inspection, and Adaptation.
4. Five Scrum Values - Commitment, Courage, Focus, Openness, and Respect.
5. Five Scrum Events - Sprint Planning, the Sprint, Daily Scrum, Sprint Review, and Sprint Retrospective.
6. All Scrum events are timeboxed (we cannot extend their duration).

8
Scrum Overview - Part 2
9. For 1 month Sprint:
a. Sprint Planning is a maximum of 8 hours.
b. Sprint Review is is a maximum of 4 hours.
c. Sprint Retrospective is a maximum of 3 hours.
d. Daily Scrum is always 15 minutes.
10. All Scrum Events, besides the Sprint, can end sooner as long as the purpose of the event is achieved.
11. Three different sets of accountabilities - The Developers, the Scrum Master, and Product Owner.
12. There are no sub-teams or hierarchies within a Scrum Team™.

9
Scrum Overview - Part 3
16. Three Scrum Artifacts and their Commitment.
a. The Commitment for the Product Backlog is the Product Goal.
b. The Commitment for the Sprint Backlog is the Sprint Goal.
c. The Commitment for the Increment is the Definition of Done.

10
The Benefits Of Being Agile
1. The core benefit of agile is value maximization. The Scrum Team does that by delivering value
frequently and constantly inspecting and adapting going forward.
2. A secondary benefit of agile is risk minimization.
3. Scrum Teams must have a strong focus on increasing customer satisfaction!
4. Generally, agile teams strive to improve their Time To Market (T2M).
a. This means faster delivery of value to the end-users.
5. Scrum Teams improve T2M by
a. Eliminating waste and non-value-added activities to the delivery process.
b. Release fewer features.
c. Automate the delivery process (if applicable)
d. Do Product Backlog Refinement.
The Scrum Team
1. Scrum Teams are cross-functional and self-managing.
2. Cross-functional teams have all the skills necessary to create a valuable increment every Sprint
without depending on others outside the team.
3. Cross-functionality helps professionals develop skills in more than one area.
4. Self-managing teams…
a. decide who does what, when, and how.
b. know their boundaries.
c. are deeply involved in the hiring process. They decide if new professionals are needed or
not.
 The Scrum Team
(3 Sets Of Accountabilities)

13
The Scrum Team - Part 1
1. There are three different sets of accountabilities in a Scrum Team
a. The Scrum Master™
b. The Product Owner™
c. The Developers
2. The Scrum Team is cross-functional & self-managing.
3. The Scrum Team is typically 10 or fewer people.
a. If the Scrum Team becomes too large, we have to consider reorganizing it into multiple
cohesive Scrum Teams.
4. There are no sub-teams or hierarchies in a Scrum Team.
5. The entire Scrum Team is responsible for all product-related activities including…
a. Product Releases
i. We can release as many times as we want during the Sprint.
14
The Scrum Team - Part 2
i. Stakeholder collaboration
ii. Verification
iii. Maintenance
iv. Operation
v. Experimentation
vi. Research and development
vii. And more.
6. “The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.”
- Scrum Guide™ 2020
7. The entire Scrum Team creates the Sprint Goal.
8. The entire Scrum Team creates the Definition of Done.

15
The Scrum Team - Additional Notes
1. Cross-functional teams have all the skills necessary to create a valuable increment every Sprint
without depending on others outside the team.
2. Cross-functionality helps professionals develop skills in more than one area.
3. Self-managing teams…
a. decide who does what, when, and how.
b. know their boundaries.
c. are deeply involved in the hiring process. They decide if new professionals are needed or
not.
Scrum Master™ Summary - Part 1
1. The SM (Scrum Master™) is accountable for the Scrum Team™’s effectiveness.
2. The SM is a true leader.
a. The SM serves the Scrum Team™
i. They cause the removal of impediments to the Scrum Team™'s progress.
ii. They ensure that all Scrum events take place and are positive, productive, and kept
within the timebox.
b. The SM serves the Product Owner™
i. They facilitate stakeholder collaboration when requested or needed.
ii. They help the PO to find techniques for effective Product Goal definition and Product
Backlog management;
c. The SM serves the Organization
i. They lead, train and coach, the organization in its Scrum adoption
17
Scrum Master™ Summary - Part 2
3. 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
enacts the Scrum theory, values, rules, and practices.
4. The Scrum Master™ is NOT a Project Manager.
a. A Project Manager role does not exist in Scrum.
5. They can work part-time as well as full-time.
6. Scrum doesn’t prohibit one person to act as a SM and a PO but it doesn’t recommend it either.
The same applies to SM and a Developer.

18
Product Owner™ Summary - Part 1
1. The PO (Product Owner™) is a value maximizer.
2. They are accountable for effective Product Backlog Management, which includes…
a. Creating and communicating a Product Goal.
b. Creating and explaining PBIs.
c. Ordering the Product Backlog.
d. Making sure the Product Backlog is transparent.
3. The PO is one person, not a committee.
4. To succeed, everyone in the organization must respect his or her decisions.
5. Only the PO has the authority to cancel a Sprint.

19
Product Owner™ Summary - Part 2
7. The PO is extremely knowledgeable about the marketplace of the Product.
8. During Sprint Planning the PO brings a business objective based on which the Scrum Team™
collaboratively crafts the Sprint Goal.
9. During the Sprint Review, the PO seeks feedback from key stakeholders.
10. PO must be available to answer any questions the developers have!
11. The PO reviews “Done” items.
a. If he or she has written Acceptance Criteria for the PBIs, they make sure the conditions are
met. Writing Acceptance Criteria for the PBIs is NOT mandatory but the Definition Of Done is.
12. If 2 Products are being developed, there can be one person acting as a PO for both Products. As
well as, there can be 2 POs, one for each Product.

20
The Developers Summary
1. The Developers are the people who create a usable increment each Sprint.
2. They create the plan for the Sprint, this is the Sprint Backlog.
3. The developers choose the number of PBI to select from the Product Backlog to the Sprint Backlog.
4. They are responsible for sizing the PBIs and the techniques they would use to turn PBIs into a usable
increment.
5. Developers are required to participate in Daily Scrum and come up with an actionable plan for the next
day.
6. Developers are required to conform to the DoD (Definition of Done).
7. If there are multiple Scrum Teams™ working together on a Product, they must mutually define and
comply with the same DoD.
8. Both the Developers and the PO do Product Backlog Refinement.
9. The Developers hold each other accountable as professionals.
21
The Most Misunderstood Scrum Value
1. Scrum Values drive behaviors.

2. The Developers commit to the Sprint Goal.

a. They do not commit to the Sprint Backlog or individual PBIs.

3. To achieve excellence, Scrum Teams must work by the Scrum Values.

The Scrum Events
(5 Official Events)

23
The Sprint Summary
1. “Sprints are the heartbeat of Scrum, where ideas are turned into value.”
2. The purpose of the Sprint is to create usable increments.
a. We can consider Sprints as short Projects.
3. The Sprints happen one after another. There are no pauses or other events.
4. The maximum duration of the Sprint is one month.
5. Typically, when the project is risky, shorter Sprints are preferred, so we can generate more learning
cycles.
6. The Sprint can be canceled when the Sprint Goal becomes obsolete.
7. 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.
8. During the Sprint quality goals do not decrease, and scope might be re-negotiated as more is learned.
a. The Scrum Team™ does not make changes that would endanger the Sprint Goal.
24
 The Sprint Planning Summary
1. During Sprint Planning, the PO ensures that attendees are prepared to discuss the most important PBIs and
how they map to the Product Goal.
2. During Sprint Planning we answer three important questions:
a. Why is this Sprint Valuable?
b. What can be done this Sprint?
c. How will the chosen work get done?
3. The entire Scrum Team™ attends and collaborates on creating the Sprint Goal.
4. The Developers decide how many PBIs to select for the Sprint Backlog.
5. The Developers decide on the practices they would use to turn PBIs into a usable increment.
6. The more the Developers know about their past performance, upcoming capacity, and the DoD, the more
accurate forecasts they would be able to do.
7. The Sprint Backlog is created during Sprint Planning and it is a combination of 3 things.
a. The Sprint Goal, the selected PBIs, and a Plan to deliver them.
8. The Scrum Team™ may invite other people to attend Sprint Planning to provide advice.
9. Sprint Planning is a maximum of 8-hours for a 1-month Sprint. 25
The Daily Scrum Summary - Part 1
1. The purpose of the Daily Scrum is to inspect progress towards the Sprint Goal and adapt the Sprint
Backlog if needed.
2. Daily Scrum is a mandatory event for all Developers of the Scrum Team™.
3. The SM ensures that Daily Scrum takes place, but the Developers are responsible for conducting the
event.
4. During Daily Scrum, the Developers plan the work for the next day.
5. The SM and PO are allowed to attend Daily Scrum.
6. Daily Scrum is always 15 minutes (regardless of the length of the Sprint and the number of
Developers).

26
The Daily Scrum Summary - Part 2
7. Daily Scrum is held at the same time and place every working day of the Sprint to reduce complexity
and eliminate waste.
8. Developers choose the structure of the Daily Scrum event.
9. The focus of the event should be:
a. “Progress towards the Sprint Goal”
b. “An actionable plan for the next day.”
10. Daily Scrums...
a. Improve communications,
b. identify impediments,
c. promote quick decision-making,
d. and consequently eliminate the need for other meetings.
11. 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. 27
The Sprint Review Summary
1. The purpose of the Sprint Review event is to inspect 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.
2. Attendees of the Sprint Review event are the Scrum Team™ and key stakeholders.
3. Sprint Review is not just a demo or a presentation of the increment.
4. The Scrum Team™ presents only items that have been 100% done according to the DoD.
5. 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.
6. The Product Backlog may also be adjusted to meet new opportunities.
7. The Sprint Review is a maximum of 4 hours for a 1-month Sprint, it is usually shorter for shorter Sprints.

28
The Sprint Retrospective Summary
1. The main purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
2. “The Scrum Team™ inspects how the last Sprint went with regards to individuals, interactions, processes,
tools, and their Definition of Done”
3. It is a maximum of 3 hours for a 1-month Sprint.
a. For shorter Sprints, the event is usually shorter.
4. It is an opportunity to inspect and adapt the process the Scrum Team™ has been using to build the
increments.
5. The whole Scrum Team™ attends the event.
6. During the Sprint Retrospective, we talk about the context, not the content.
a. For example, tools to help us communicate with members of the team who work remotely. Or the
importance of communication between team members. Or the length of the Sprint. Or the
structure of the Daily Scrum. Or the DoD, and so on.
29
Scrum Artifacts & Commitments
(3 Artifacts & 3 Commitments)

30
Scrum Artifacts & Their Commitments
1. There are 3 Scrum Artifacts:
a. The Product Backlog
b. The Sprint Backlog
c. The Increment
2. 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.
3. The three commitments are mandatory.
4. The PO works with the Scrum Team™ and creates the Product Goal.
a. The PO is accountable for the Product Goal.
5. The entire Scrum Team™ creates and is accountable for the Sprint Goal.
6. The entire Scrum Team™ creates and is accountable for the Definition of Done.
31
Product Backlog Summary
1. The PB (Product Backlog) is an ordered list of items.
2. It is the single source of work undertaken by the Scrum Team™.
3. The PB is ordered in a way that maximizes the value the product delivers.
4. The PB is never complete. It is ever-changing and dynamic.
5. One Product has:
a. One Product Backlog
b. One Product Owner™
c. One Product Goal at any given time
6. PBIs on top of the PB are clearer, hence smaller than those on the bottom.
7. “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
32
The Product Goal Commitment
1. The Product Goal describes a future state of the Product.
a. “The Product Goal is the long-term objective for the Scrum Team™.”
2. The PO is accountable for creating and explicitly communicating the Product Goal.
3. We cannot have more than one Product Goal at any given time.
4. It is recommended that the Product Goal is clear and concise.
5. Each increment (Sprint) moves the Product toward the Product Goal.
6. The Product Goal is measurable, the Scrum Team™ knows when the goal has been achieved.
7. The Product Goal can change, but it is highly unlikely for this to happen during a Sprint.
8. Refinements to the Product Goal happen during the Sprint Review event.
9. Generally, the Product Goal is one part of a bigger Product Vision.
10. Multiple Scrum Teams™ working on the same Product, share the same Product Goal, the same
Product Backlog, and the same Product Owner™.
33
The Sprint Backlog & The Sprint Goal
1. The SB (Sprint Backlog) 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).
2. The SB is a plan by and for the Developers.
3. The SB is highly-visible.
4. The SB changes during the Sprint.
5. The PO and the Developers may change/negotiate the scope of the Sprint but this should not affect
the Sprint Goal in any way.
6. We move the incomplete items back to the Product Backlog for future considerations.
7. The Sprint Goal helps the team stay focused during the Sprint.

34
The Increment Summary
1. An Increment is a stepping stone toward the Product Goal.
2. Each Increment is additive to all prior increments.
3. The Scrum Team™ creates one or multiple Increments each Sprint.
4. All Increments must be verified and usable.
5. The whole Scrum Team™ decides when to release the Increment.
6. Scrum does not tell us when to release. We can release as many times as we want.
7. Work cannot be considered part of an Increment unless it meets the Definition of Done.

35
The Definition of Done (DoD) Summary
1. “The DoD is a formal description of the state of the Increment when it meets the quality measures
required for the Product.”
2. The DoD is mandatory and it increases transparency.
3. If DoD is part of organizational standards, the Scrum Team™ must follow it as a minimum.
4. If DoD is not part of organizational standards, the Scrum Team™ must create one that is appropriate
for the Product.
5. The DoD may be improved during the project, the result would be a higher quality of the work.
6. If multiple Scrum Teams™ are working on the same Product, they must mutually define and comply
with the same DoD for the integrated increment.

36
Agile Leadership
(Scrum)

37
The Top 4 Behaviors Of The Agile Leader
1. The Agile Leader creates an environment where people and teams can thrive.
2. The Agile Leader…
a. Encourages experimentation.
b. Leads by example.
c. Facilitates and removes impediments.
d. Collaborates with the Scrum Teams and stakeholders.
3. The Agile leader respects Self-Management and the Scrum Framework.
The Agile Leader & Empiricism
1. According to David Snowden, leaders should determine the domain they are with to make better
decisions. David proposes 4 domains…
a. Simple,
b. Complicated,
c. Complex,
d. Chaotic.
2. Product Development lives in the Complex domain.
3. The best way to deal with complexity is to work empirically (Empiricism).
4. Releasing small increments frequently is a great way to reduce risk.
Navigating Conflicts & Dealing With Complaints
1. Conflicts within a group of people working together are natural.
2. Scrum Teams resolve team conflicts internally. The Agile leader should not intervene.
3. The SM possesses a skill set to navigate conflicts.
a. By using facilitation and coaching, the SM may initiate open and honest discussions.
4. An agile leader never undermines the autonomy of a Scrum Team.
How To Deal With Low Motivation In The Scrum Team
1. Generally, there are 2 types of motivation.
a. Extrinsic (external) motivation
b. Intrinsic (internal) motivation
2. Higher incentives (extrinsic motivation) often lead to worse performance.
3. Intrinsic motivation lasts longer.
4. According to Daniel Pink, the top 3 factors that affect our intrinsic motivation are
a. Mastery
b. Autonomy
c. Purpose
Evidence-Based Management
1. Evidence-based Management™ (EBM™) helps organizations improve their ability to deliver value
2. EBM™ focuses on four key value areas (KVAs)
a. Unrealized Value (UV)
b. Current Value (CV)
c. Ability to Innovate (A2I)
d. Time to Market (T2M)
3. We should focus on improving the outcomes and not the activities and outputs. Simply because
“working more hours (activities) and delivering more features (outputs) does not necessarily lead
to improved customer experiences (outcomes).” - The EBM™ Guide
Interruptions During The Sprint
1. When a Scrum Team faces too frequent interruptions, their productivity goes down and the
chance of reaching the Sprint Goal decreases significantly.
2. We should try to minimize interruptions during the Sprint. Some options are:
a. If the problem is a scarce skill, then consider knowledge transfer.
b. The Scrum Team should be conservative when planning the work for the Sprint and setting
the Sprint Goal.
c. Are there people outside the Scrum Team who can work on the interrupting work?
3. A Sprint cannot be extended to finish the remaining work.
How Are Great Scrum Teams Formed?
1. Agile leaders do not assign people to teams.
2. Always let the people self-organize into teams and remind them of the Scrum rules.
a. [Recommendation] 10 or fewer people.
b. [Rule] Cross-functionality.
3. When starting a new project, share the main business objective, the end-users, their needs, and
what success looks like.
4. Scrum is not against Distributed Teams but we should be aware of challenges such as…
a. Different time zones.
b. Difficulties with building trust.
5. Usually, newly formed teams go through 4 stages of development.
a. Forming, Storming, Norming, and Performing.
6. It takes time to achieve high performance. Well-established Scrum Teams collaborate, work in an
environment of trust and the Scrum values. They have a laser focus on the vision and goals, and
their ability to forecast is enhanced.
7. Ideally, Scrum Teams work on one product at a time.
Velocity
1. Velocity is the amount of work the Scrum Team gets done.

a. The Scrum Team considers an average velocity of the past several Sprints.

2. Velocity changes during the Product Development. Usually, it increases with time.

3. Most importantly, velocity is about speed and it does not have a direct relation to value.
What Agile Leaders Should Stop Doing Immediately
1. Don’t compare teams. This often leads to unhealthy behaviors.
2. Don’t expect 100% utilization of the people who work in a Scrum Team.
3. Don’t measure project success based on scope, time, and budget.
a. This is a Project Mindset. In Scrum, we prefer a Product Mindset - delivering value through
products.
4. Don’t encourage narrow specialization.
5. Don’t reward individual performance.