Scrum Master Training at UM DI | 2nd and 3rd of Mar 2016.

1. Scrum Master Training
by Eduardo Ribeiro
V 1.0
Universidade do Minho - Departamento de InformáCca

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
• TradiConal vs. Agile Delivery
• TradiConal vs. Agile Feedback
• Agile Umbrella
• Why we use (or should use) it?
• What is Scrum?
– Incremental != IteraCve
– Scrum Principles
– Scrum Team & Roles
• Ball Point Game
– Scrum Ceremonies
– Scrum Framework
– User Stories Context
– INVEST Acronym
– Why?
• User Story Game
– Why we esCmate?
– Poker Planning
• EsCmaCon Techniques Games
– DoD and DoR
– Visibility of Progress
– Time for the ulCmate game – Lego Game
– Scrum Smells aka AnC-Pa_erns

5. What is Agile
“Agile is an “iteraCve” and “incremental”
sobware development methodology were its
main focus is on client saCsfacCon through
conCnuous 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
sobware.
• Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's compeCCve advantage.
• Deliver working sobware 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 effecCve method of
conveying informaCon 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.
• ConCnuous a_enCon to technical excellence and
good design enhances agility.
• Simplicity the art of maximizing the amount of work
not done is essenCal.
• 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. TradiConal vs. Agile
Delivery

9. TradiConal 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 producCvity
• Reduced waste
• More producCve & happy
teams

12. What is Scrum?

13. Incremental != IteraCve

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 informaCon radiators.
Adapta#on:
• AdaptaCon happens as the Scrum Core Team and Stakeholders learn
through transparency and inspecCon and then adapt by making
improvements in the work they are doing.

16. Self-OrganizaCon

17. CollaboraCon

18. Value Base-PrioriCzaCon

19. Time-Boxing

20. IteraCve 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 &
RetrospecCve

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 EsCmate?

37. Poker Planning

38. EsCmaCon Techniques Games

39. DOD AND DOR
Scrum

40. DefiniCon 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 "oben 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. DefiniCon of Ready aka DoR
• By analogy with the "DefiniCon 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
iteraCon.
• 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
informaCon outwards!
• It also helps reduce interrupCons!
– Scrum and Kanban Physical Boards
– Big visible charts (Ex: CFS’s, Burn
Down, Etc)
– On-line Tools (Ex: Rally Dev)
– Daily reporCng

43. Examples

44. Time for the ulCmate game
Lego Game

45. Scrum Smells aka AnC-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 esCmates for the
team.

46. QuesCons?

47. Thank
You!