This document provides an overview of a Scrum Master training. It discusses key concepts of Agile and Scrum including the Agile Manifesto and 12 principles, Scrum roles, ceremonies, and frameworks. It also describes exercises that will be used in the training such as the ball point game, user story game, poker planning, and Lego game to teach principles of Scrum in an engaging way.

1. Scrum Master Training
by Eduardo Ribeiro
V 1.0

2. edu.f.ribeiro@gmail.com
@edu_f_ribeiro

3. Not
Again!!!
Same
jokes, ugly
draws and
slides!

4. Overview
• What is Agile?
• Agile Manifesto
• 12 Principles behind the Agile
Manifesto
• TradiMonal vs. Agile Delivery
• TradiMonal vs. Agile Feedback
• Agile Umbrella
• Why we use (or should use) it?
• What is Scrum?
– Incremental != IteraMve
– Scrum Principles
– Scrum Team & Roles
• Ball Point Game
– Scrum Ceremonies
– Scrum Framework
– User Stories Context
– INVEST Acronym
– Why?
• User Story Game
– Why we esMmate?
– Poker Planning
• EsMmaMon Techniques Games
– DoD and DoR
– Visibility of Progress
– Time for the ulMmate game – Lego Game
– Scrum Smells aka AnM-Pa^erns

5. What is Agile
“Agile is an “iteraMve” and “incremental”
soaware development methodology were its
main focus is on client saMsfacMon through
conMnuous delivery.”

6. Agile Manifesto

7. 12 Principles behind the Agile
Manifesto
• Our highest priority is to sa#sfy the customer
through early and con#nuous delivery of valuable
soaware.
• Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's compeMMve advantage.
• Deliver working soaware frequently, from a couple
of weeks to a couple of months, with a preference
to the shorter #mescale.
• Business people and developers must work
together daily throughout the project.
• Build projects around mo#vated individuals. Give
them the environment and support they need, and
trust them to get the job done.
• The most efficient and effecMve method of
conveying informaMon to and within a development
team is face-to-face conversa#on.
• Working so:ware is the primary measure of
progress.
• Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
• ConMnuous a^enMon to technical excellence and
good design enhances agility.
• Simplicity the art of maximizing the amount of work
not done is essenMal.
• The best architectures, requirements, and designs
emerge from self-organizing teams.
• At regular intervals, the team reflects on how to
become more effec#ve, then tunes and adjusts its
behavior accordingly.

8. TradiMonal vs. Agile
Delivery

9. TradiMonal vs. Agile
Feedback

10. Agile Umbrella
Crystal Clear
Feature Driven Development (FDD)
Dynamic System Development Method (DSDM)
Lean So:ware Development
Kanban
Scrum
Extreme Programming (XP)
Adap#ve So:ware Development (ASD)
Behavior Driven Development (BDD)

11. Why we use (or should use) it?
• Reduced risk
• Earlier ROI/ value
• Increased visibility of progress
• Increased predictability
• Increased producMvity
• Reduced waste
• More producMve & happy
teams

12. What is Scrum?

13. Incremental != IteraMve

14. PRINCIPLES
Scrum

15. Empirical Process Control
Transparency:
• Transparency allows all facets of any Scrum process to be observed by
anyone.
Inspec#on:
• Use of a common Scrum Board and other informaMon radiators.
Adapta#on:
• AdaptaMon happens as the Scrum Core Team and Stakeholders learn
through transparency and inspecMon and then adapt by making
improvements in the work they are doing.

16. Self-OrganizaMon

17. CollaboraMon

18. Value Base-PrioriMzaMon

19. Time-Boxing

20. IteraMve Development

21. TEAM & ROLES
Scrum

22. Scrum Team & Roles

23. Scrum Master

24. Ball Point Game

25. Product Owner

26. CEREMONIES
Scrum

27. Grooming the Product Backlog

28. Sprint Planning

29. Daily Stand Up

30. Sprint Review or Demo &
RetrospecMve

31. Scrum Framework

32. User Stories Context
As a … (user of the system)
I want … (feature or problem to
be solved)
So that … (benefit of story being
completed)
The “so that” part is incredibly
valuable as it focuses people on
the real reason behind this story.

33. INVEST Acronym

34. Why?

35. User Story Game

36. Why we EsMmate?

37. Poker Planning

38. EsMmaMon Techniques Games

39. DOD AND DOR
Scrum

40. DefiniMon of Done aka DoD
• The team agrees on, and displays
prominently somewhere in the
team room, a list of criteria which
must be met before a product
increment "oaen a user story" is
considered "done".
• On a feature level, the acceptance
criteria should be agreed up front
BEFORE the User Story is
submi^ed to acceptance.

41. DefiniMon of Ready aka DoR
• By analogy with the "DefiniMon of
Done", the team makes explicit
and visible the criteria (generally
based on the INVEST matrix) that
a user story must meet prior to
being accepted into the upcoming
iteraMon.
• On a feature level, the acceptance
criteria should be agreed up front
BEFORE code is wri^en.

42. Visibility of Progress
• Team has a duty to radiate
informaMon outwards!
• It also helps reduce interrupMons!
– Scrum and Kanban Physical Boards
– Big visible charts (Ex: CFS’s, Burn
Down, Etc)
– On-line Tools (Ex: Rally Dev)
– Daily reporMng

43. Examples

44. Time for the ulMmate game
Lego Game

45. Scrum Smells aka AnM-Pa^erns
• Scrum Master or any other team member assigning work.
• Daily Scrum is for the Scrum Master or any other specify
person.
• Sprint work being carried over.
• Test sprints.
• Everything “In-progress”.
• SM/ DM/ PO or anyone else providing esMmates for the
team.

46. QuesMons?

47. Thank
You!