This document provides an overview of the Professional Scrum Foundations course. The course introduces students to the Scrum framework and teaches the basics of implementing Scrum effectively. It addresses common challenges teams face in adopting Scrum and equips students to avoid common pitfalls. The course covers Scrum roles, events, artifacts, planning techniques, and includes hands-on exercises for students to practice Scrum. The intended audience is anyone working with a Scrum team, especially those new to Scrum or struggling with implementation.

1. PROFESSIONAL SCRUM
FOUNDATIONS

2. QUESTIONS
• Are Technical Skills Required to be a Scrum Master?

3. ABOUT COURSE
• Scrum Teams succeed best with a solid foundation and this course
prepares students to begin effectively using Scrum immediately. The
Scrum framework, mechanics, and roles of Scrum are emphasized
with emphasis on practical application.
• This course is the perfect introduction to Scrum for anyone new to
the framework. Whether your team needs a flawless Scrum launch or
needs to reboot a struggling Scrum implementation, this class lays
the foundation for an effective Scrum team.
• This course lays the foundation of knowledge needed for other, more
advanced training such as Professional Product Owner and
Professional Scrum Master.

4. COURSE PURPOSE
• Professional Scrum Foundations (PSF) is a course offered to
solidify the core principles of Scrum for individuals or teams.
Common missteps in the adoption of Scrum have been seen
over and over again across industries, companies, and teams.
Rather than coaching teams back from a poorly functioning
Scrum implementations, PSF exposes these common missteps,
increases the awareness of the associated symptoms, and
provides prescriptive guidance to avoid going off track.

5. COURSE PURPOSE
• This practical classroom experience equips attendees to get
started with Scrum, sustain successful habits, and avoid
common Scrum pitfalls. Students learn the basics of Scrum and
how to implement Scrum effectively and keep their team
practicing healthy behaviors.

6. COURSE PURPOSE
This class deliberately addresses common challenges teams will
face in their Scrum adoption by equipping students to mitigate
threats that can derail Scrum in some organizations, including:
• Flexible Time boxes
• Delaying bug fixes
• Unclear definitions of done
• Measuring effort rather than achievement

7. CONT…
• Ineffective Daily Scrum meetings
• Poorly structured Backlogs
• Ambiguous or ineffective requirements
• Uncommitted Scrum Team members
• Ad-hoc work requests
• And many others

8. CONT…
• Subconscious trending towards waterfall
• Unproductive retrospectives

9. HOW ATTENDEES LEARN
Understanding the Scrum framework is the beginning of applying
Scrum successfully. Using knowledge acquired in the class, students
learn how to apply Scrum by actively participating in:
• Working with a realistic Product Backlog
• Participate in Sprint Planning
• Decompose requirements into actionable Backlog Items
• Effectively estimate Backlog Items
• Sprint Planning, Sprint Reviews, and Retrospectives

10. AUDIENCE
• PSF is appropriate for anyone working on or with a Scrum Team. The
course is especially well suited to companies or teams investigating
Scrum, those who are currently struggling with Scrum, or those
beginning to utilize Scrum in their development environment.
• The PSF course isn’t for everyone. Well-functioning Scrum teams
looking for assistance with advanced topics like scaling Scrum or
implementing a rigorous ROI framework will not receive as much
benefit from this course. Teams looking to explore more advanced
topics should consider the Professional Scrum Master course.

11. PREREQUISITES
• Have been on or closely involved with a project that builds or
enhances a product.
• Want to know more about how Scrum works, how to use it, and
how to implement it in an organization.

12. STRUCTURE
• In addition to the subjects noted below, students actively
participate in the Scrum process with realistic and practical
hands-on exercises that reinforce the learning points.
Practicing Scrum ensures that students complete the class with
new skills in addition to new knowledge and theory.

13. CONT…
• The Scrum Framework
• Students dive into the Scrum software development framework
including, roles and responsibilities, principles, artifacts, and events and
time boxes, rules and customs.
• Introducing Scrum and Agile
• This module discusses the current state of the software industry and
Scrum’s role within it. Topics include the origins of Scrum,
misconceptions of the framework, the value that Scrum provides, and an
exploration of self-organization as a power tool for increasing
productivity.

14. CONT…
• Scrum Planning
• Learn practical techniques of planning releases, managing Product
Backlogs, keeping Sprints on track, and maintain healthy team
behaviors. Although many effective techniques exist for expressing
requirements, this module equips teams to discover, express, and
decompose requirements as Backlog Items using proven techniques

15. CONT…
• Keeping Scrum Healthy
• This module focuses on common missteps teams make when adopting
Scrum and strategies to avoid them. In addition to discussing typical
patterns/anti-patterns in this module, class attendees practice some of
the more courageous conversations that commonly occur.
• Getting Started
• Following an excellent training event, Teams often struggle
implementing what seemed so reasonable just a few days ago. This
discussion helps attendees plan and prepare to actually be effective with
Scrum immediately, marking the PSF as the true catalyst for change and
increasing agility within your organization.

16. ABOUT THE INSTRUCTOR
• Ahmed Hamza
• Senior software engineer, work in development area since 2007
• Have good knowledge in DevOps tools
• Work as Scrum Developer, Master and lastly as Product Owner.
• I worked as Team Leader and then as Project Manager in more than
25 projects.
• Scrum PSM Certified https://www.scrum.org/certificates/275110

17. WHY WE EVEN NEED SCRUM
• Requirements not clear
• Fear to go to next phase.
• Analysis paralysis.
• Requirements Change
• Changes get more and more expensive.
• Customers don’t get what they want.

18. WHY WE EVEN NEED SCRUM
• Project takes tool long
• Long duration defer revenue
• No time for testing
• Quality assurance gets crunched.
• Late integration mean late failure.

19. WHY WE EVEN NEED SCRUM
• Time wasted on junk
• Many of developed requirements rarely used.

20. THE SCRUM FRAMEWORK
• Definition of Scrum : Scrum (n): A framework within which
people can address complex adaptive problems, while
productively and creatively delivering products of the highest
possible value.
• Scrum is:
• Lightweight
• Simple to understand
• Difficult to master

21. SCRUM THEORY
• Scrum is founded on empirical process control theory, or
empiricism. Empiricism asserts that knowledge comes from
experience and making decisions based on what is known.
Scrum employs an iterative, incremental approach to optimize
predictability and control risk.
• Three pillars uphold every implementation of empirical process
control: transparency, inspection, and adaptation.

22. SCRUM THEORY
• Transparency
• Significant aspects of the process must be visible to those responsible
for the outcome. Transparency requires those aspects be defined by a
common standard so observers share a common understanding of what
is being seen.
• Inspection
• Scrum users must frequently inspect Scrum artifacts and progress
toward a Sprint Goal to detect undesirable variances. Their inspection
should not be so frequent that inspection gets in the way of the work.
Inspections are most beneficial when diligently performed by skilled
inspectors at the point of work.

23. SCRUM THEORY
• Adaptation
• If an inspector determines that one or more aspects of a process deviate
outside acceptable limits, and that the resulting product will be
unacceptable, the process or the material being processed must be
adjusted. An adjustment must be made as soon as possible to minimize
further deviation.

24. SCRUM THEORY
• Scrum prescribes four formal events for inspection and
adaptation
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

25. SCRUM VALUES

26. THE SCRUM TEAM
• The Scrum Team consists of a Product Owner, the Development
Team, and a Scrum Master.
• Scrum Teams are self-organizing and cross-functional.
• Self-organizing teams choose how best to accomplish their
work, rather than being directed by others outside the team.
• Cross-functional teams have all competencies needed to
accomplish the work without depending on others not part of
the team

27. SCRUM TEAM
• Scrum Teams deliver products iteratively and incrementally,
maximizing opportunities for feedback.

28. THE PRODUCT OWNER

29. THE PRODUCT OWNER
• The Product Owner is responsible for maximizing the value of
the product resulting from work of the Development Team.
• The Product Owner is the sole person responsible for managing
the Product Backlog. Product Backlog management includes:
• Clearly expressing Product Backlog items.
• Ordering the items in the Product Backlog to best achieve goals and
missions.
• Optimizing the value of the work the Development Team performs;.

30. THE PRODUCT OWNER
• Ensuring that the Product Backlog is visible, transparent, and
clear to all, and shows what the Scrum Team will work on next.
• Ensuring the Development Team understands items in the
Product Backlog to the level needed

31. THE PRODUCT OWNER
• Other responsibilities:
• Pick the release date.
• Give feedback
• Manage stakeholders
• Accept or reject the increment.

32. THE PRODUCT OWNER
• For the Product Owner to succeed, the entire organization must
respect his or her decisions.
• No one can force the Development Team to work from a
different set of requirements.

33. SCRUM MASTER

34. SCRUM MASTER
• The Scrum Master is responsible for promoting and supporting
Scrum as defined in the Scrum Guide. Scrum Masters do this by
helping everyone understand Scrum theory, practices, rules,
and values.

35. SCRUM MASTER VS PRODUCT OWNER

36. SCRUM MASTER SERVICE TO THE PRODUCT
OWNER
• Ensuring that goals, scope, and product domain are understood by everyone on the
Scrum Team as well as possible;
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog
items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize
value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.

37. SCRUM MASTER SERVICE TO THE
DEVELOPMENT TEAM
• Coaching the Development Team in self-organization and
cross-functionality;
• Helping the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational
environments in which Scrum is not yet fully adopted and
understood.

38. SCRUM MASTER SERVICE TO THE
ORGANIZATION
• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact
Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum
Team; and,
• Working with other Scrum Masters to increase the effectiveness
of the application of Scrum in the organization.

39. THE DEVELOPMENT TEAM

40. THE DEVELOPMENT TEAM
• The Development Team consists of professionals who do the
work of delivering a potentially releasable Increment of “Done”
product at the end of each Sprint

41. DEVELOPMENT TEAMS CHARACTERISTICS
• They are self-organizing. No one (not even the Scrum Master)
tells the Development Team how to turn Product Backlog into
Increments of potentially releasable functionality.
• Development Teams are cross-functional, with all the skills as a
team necessary to create a product Increment.
• Scrum recognizes no titles for Development Team members,
regardless of the work being performed by the person

42. DEVELOPMENT TEAMS CHARACTERISTICS
• Scrum recognizes no sub-teams in the Development Team,
regardless of domains that need to be addressed like testing,
architecture, operations, or business analysis.
• Individual Development Team members may have specialized
skills and areas of focus, but accountability belongs to the
Development Team as a whole

43. DEVELOPMENT TEAM SIZE
• 3-9
• Fewer than three Development Team members decrease
interaction and results in smaller productivity gains. Smaller
Development Teams may encounter skill constraints during the
Sprint.
• Having more than nine members requires too much
coordination. Large Development Teams generate too much
complexity for an empirical process to be useful

44. COMMON MISTAKES SCRUM MASTER
MAKES
• Scrum Master acting as a Project manager.
• Scrum Master making decisions for the team.
• Scrum Master holding sole responsibility for the delivery.
• Not conducting Retrospectives after every Sprint.
• Not removing obstacles at an initial stage.
• Less or No daily stand-ups.

45. COMMON MISTAKES SCRUM MASTER
MAKES
• Not adhering to the Scrum Theory.
• Non prioritized Product Backlog.
• Not handing over the ownership of Daily Scrums to the team.
• Overburdening the Scrum team.

46. QUESTIONS
• Are Technical Skills Required to be a Scrum Master?
• So Who Is the Project Manager?

47. SCRUM EVENTS & ARTIFACTS

48. EVENT 1: THE SPRINT

49. SPRINT

50. DURING THE SPRINT:
• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product
Owner and Development Team as more is learned.

51. CANCELLING A SPRINT
• Only the Product Owner has the authority to cancel the Sprint.
• A Sprint would be cancelled if the Sprint Goal becomes
obsolete.

52. SPRINT PLANNING

53. SPRINT PLANNING ANSWERS THE
FOLLOWING:
• What can be delivered in the Increment resulting from the
upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?

54. SPRINT PLANNING

55. SPRINT GOAL

56. SPRINT GOAL
• The Sprint Goal is an objective set for the Sprint that can be
met through the implementation of Product Backlog

57. DAILY SCRUM

58. DAILY SCRUM

59. SPRINT REVIEW

60. SPRINT REVIEW
• A Sprint Review is held at the end of the Sprint to inspect the
Increment and adapt the Product Backlog if needed

61. THE SPRINT REVIEW INCLUDES THE
FOLLOWING ELEMENTS:
• 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;

62. CONT …
• The Product Owner discusses the Product Backlog as it stands. He or
she projects likely target and delivery 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 releases of functionality or
capability of the product.

63. SCRUM IN REALITY
• https://www.youtube.com/watch?v=Q6jMgmPIxmk

64. SPRINT RETROSPECTIVE
• The Sprint Retrospective is an opportunity for the Scrum Team
to inspect itself and create a plan for improvements to be
enacted during the next Sprint.

65. SPRINT RETROSPECTIVE

66. SCRUM ARTIFACTS

67. PRODUCT BACKLOG
• The Product Backlog is an ordered list of everything that is
known to be needed in the product.
• It is the single source of requirements for any changes to be
made to the product
• The Product Owner is responsible for the Product Backlog,
including its content, availability, and ordering.

68. SPRINT BACKLOG
• The Sprint Backlog is the set of Product Backlog items selected
for the Sprint, plus a plan for delivering the product Increment
and realizing the Sprint Goal

69. PRODUCT BACKLOG

70. SPRINT BACKLOG
• There is no specific rule on documenting, storing, and
presenting the Sprint Backlog. It can be on a board similar to
one shown in the next slide.

72. PRODUCT BACKLOG REFINEMENT

73. INVEST IN GOOD STORIES, AND SMART
TASKS

74. WHAT ARE CHARACTERISTICS OF A GOOD
STORY
• I – Independent
• N – Negotiable
• V – Valuable
• E – Estimable
• S – Small
• T – Testable

75. WHAT ARE CHARACTERISTICS OF A SMART
TASKS
• S – Specific
• M – Measurable
• A – Achievable
• R – Relevant
• T – Time-boxed

76. MONITORING PROGRESS TOWARD GOALS
• At any point in time, the total work remaining to reach a goal
can be summed. The Product Owner tracks this total work
remaining at least every Sprint Review.
• At any point in time in a Sprint, the total work remaining in the
Sprint Backlog can be summed. The Development Team tracks
this total work remaining at least for every Daily Scrum to
project the likelihood of achieving the Sprint Goal.

77. INCREMENT
• The Increment is the sum of all the Product Backlog items
completed during a Sprint and the value of the increments of all
previous Sprints

78. INCREMENT

79. 5 CHALLENGES CREATING A DONE
INCREMENT
• Lack of Team Ownership
• Lack of Collaboration
• There is Not a Clear Sprint Goal
• Too Much Change During the Sprint
• Impediments Are Not Being Removed

80. DEFINITION OF “DONE”
• This is the definition of “Done” for the Scrum Team and is used
to assess when work is complete on the product Increment.
• The same definition guides the Development Team in knowing
how many Product Backlog items it can select during a Sprint
Planning.
• As Scrum Teams mature, it is expected that their definitions of
“Done” will expand to include more stringent criteria for higher
quality

81. SCALING SCRUM

82. SCRUM WITH KANBAN

83. 7 COMMON AGILE DEVELOPMENT FAILS
• Using high friction tools.
• Designing for conformity.
• Not stopping what doesn't work.
• Focusing on data over teamwork.
• Measuring output over outcomes.
• Not holding retrospectives.
• Not releasing completed work.

84. REFERENCE
• https://www.scrum.org/resources/scrum-guide
• https://www.scrum.org/resources/scaling-scrum
• https://www.scrum.org/resources/kanban-guide-scrum-teams
• https://www.agilesocks.com/business-agility/
• https://www.scrum.org/resources/blog/best-practices-and-scrum
• https://www.agilesocks.com/5-challenges-creating-done-increment/
• https://www.youtube.com/watch?v=-WgQdHOx_hA
• https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/