This document provides an agenda for a training course on the scrum master role, covering topics such as comparing scrum masters to traditional project managers, facilitating scrum ceremonies like planning, daily standups and retrospectives, and coaching

1. 1
Agile
for
Scrum Masters

2. 2
Working Agreements

3. 3
Course Requirements
Description
• In this course, we will discuss the skills necessary to facilitate agile teams, so that the team members
transition from a sequential work style to a swarming work style.
• Self-organized cross-functional teams are the cornerstone of agile development.
Prerequisite
• Prior to taking this training, you should have completed the following:
• Agile 101 Training
Intended Audience
• Potential Scrum Masters
• Any leadership role involved in Product/Service Planning & Delivery process
• e.g. Technical Leader, QA Leader, Technical Managers, QA Managers, Project Managers, Program Managers

4. 4
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
Coaching Team- Small Team Dynamicsd
1
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh

5. 5
Video #0: Scrum Master Role
Power of Scrum: a funny Scrum Master Movie
with
Jeff Sutherland, co-creator of Scrum Process Framework

6. 6
What are Lean Principles? And How do we implement them in Agile
Lean Principles Implementation in Agile
Eliminate waste Retrospectives, Feedback loops at every iteration
Amplify learning Retrospectives, Feedback loops at every iteration
Decide as late as possible Iteration Planning every 2 weeks
Deliver as fast as possible Short Iterations
Empower the team Servant Leadership, Team Collaboration
Build integrity in Build Quality In: Continuous Testing & integration
See the whole Cross functional teams, breaking down Silos
Principles
Values
Process
Practices
(kata)

7. 7
Scrum Framework: Process, Artifacts and Events
24h
SPRINT
POTENTIALLY
SHIPPABLE
INCREMENT
SERVICE & PRODUCT
ADOPTION BACKLOG
SPRINT BACKLOG
SPRINT DEMO
SPRINT RETROSPECTIVE

8. 8
In Summary: Scrum is most common Agile Framework
• Each sprint has a fixed duration “time-box”
• Each sprint delivers working, fully tested code
• Only the team can do a pull from backlog
• Team cannot plan to exceed their capacity
• Team sync up on sprint goals during daily standup
• Core team size cannot be dynamic
• Team stays together for extended duration Scrum is lightweight yet, like rugby, needs rules to ensure
correct flow.
It is the responsibility of the Scrum Master to ensure
adherence to the agreed rules.
Scrum Values
Commitment, courage, focus, openness and respect

9. 9
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
1
Coaching Team- Small Team Dynamicsd
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh

10. 10
SCRUM - Team
SERVICE OWNER
A person responsible for
maximizing the value of the
Service and the work of the
Scrum Team (Service Backlog
and determination of
priorities)
SCRUM TEAM
Professionals who do the work for
delivering a potentially releasable
Increment of “Done“ software at the
end of each Sprint. The software is
coded and tested. Self-organizing,
cross-functional
SCRUM MASTER
A person ensuring that Scrum is understood
and enacted. Expert in the Scrum Process and
monitors the Scrum Team progress
PRODUCT OWNER
A person responsible for
ensuring Product adoption of
the Service and maximizing
the value of the Product
(Product-specific Backlog and
determination of priorities)
SUPPORTING SMEs
Professionals who work on the
enabling elements of a Service
and/or Product Adoption
SERVICE ANALYST
A person who defines Service
Level Requirements, Use Cases
and User Stories.
Supports UAT.
BUSINESS ANALYST
A person who defines Product
Adoption Level Requirements,
Use Cases and User Stories.
Supports UAT.
AGILE COACH
A person leading and coaching the
organization in its Agile and Scrum
adoption.
PROGRAM MANAGER
(SERVICE AND PRODUCT)
A person who manages and resolve
Interdependencies and aligns
enabling activities to support team.
Also involved in monitoring and
tracking of velocity and other health
indicators

11. 11
Scrum Master Role
Scrum
Advocate
Servant
Leader
Coach
Problem
Solver
Protector
Process
Owner
Responsible
for making sure
that team lives by
values & principles of
Scrum process
Leads team by serving the best interests of team, not one-self
Does anything
to help team
become high
performing
Creating balance
with team’s key
stakeholder:
product/service
owner
Protects team from over-commitment & complacency
Helping
team do the
best work it
possibly can
• 1 Person!
• Accountable for guiding,
coaching, teaching and
assisting team
• Creates and maintains an
environment favorable to
applying Scrum process
• This involves:
• Bulldozing (removing)
any impediments to
team’s progress
• facilitating meetings,
and working with
product/service owner

12. 12
Agile vs. Traditional Responsibilities- Scrum Master vs. Project Manager
Mindset changes needed- Shift from directive leadership to servant leadership
Coordinating team activities & contributions
Deadlines
Driving towards outcomes
Knowing the answer
Coaching teams to collaborate
Objectives
Being invested in overall performance
Asking the teams for the answer
to
to
to
to
Directing Aiding self-organizationto
Fixing problems Helpto

13. 13
A Day in Life of Scrum Master
•Engage Product/Service Owner so that
s/he is available to provide clarifications
•Ensure Product/Service Owner is not
micromanaging team
•Schedule frequent demos as early as
possible, for course corrections
•Facilitate Product/Service Backlog
Refinement sessions to prepare for next
sprint planning
•Help Product/Service Owner refines
Epic/user stories for future requirementsSprint Planning
During Sprint
Daily Scrum
Sprint Demo Retrospective

14. 14
Facilitating Product/Service Owner and Team Decisions: Which Stories to Prioritize for a Sprint
Sprint 1 Backlog
• Each story is selected by importance
• The sum of the stories should not exceed team velocity
• The team decides how many stories to include
• Commitment is achieved once stories have consensus around estimates
Backlog for future sprints

15. 15
Break #1

16. 16
Scrum Master Facilitates Scrum Ceremonies
• Ensure that:
• Meeting happens on Sprint day 1
• Meeting is time boxed, for example:
2 weeks Sprint should have 4 hours of Sprint Planning
• Product/Service Owner has prioritized work
• Team is engaged and committed to current Sprint
• Team understands work prioritized for the Sprint
• Team considers total team capacity and dependencies
(technical and external) while providing commitment
• All team members jointly agree & arrive at consensus
• All team members commit (“fist of 5”) to Sprint goal
Sprint Planning Example of Agenda for Sprint Planning:
1:00 PM – 5:00 PM
• 1:00 – 1:30 PM
Product/Service Owner states Sprint goal,
summarizes backlog, talks about demo place, date
& time
• 1:30 – 3:00 PM
Team (re)sizes user stories, breaking down work.
Team defines story acceptance criteria as needed.
• 3:00 – 4:00 PM
Team selects stories for the sprint. Scrum Master
does capacity calculations as a reality check.
• 4:00 – 5:00 PM
1-by-1, team breaks down stories into tasks.
Team decides place & time for Daily Scrum.

17. 17
Video #1: Sprint Planning
How to: Improve Sprint Planning

18. 18
Scrum Master Facilitates Scrum Ceremonies (Continued)
• Ensure that:
• Daily Standup time is fixed
• Entire team attends the Daily Standup
• Every one is attentive during Daily Standup
• Daily Standup is focused on the 3 standard questions
• No additional discussion happens
• Daily Standup is complete in 15 minutes
• Team does not deviate from the purpose of the Daily Standup
• Reinforce if team is deviating
Daily Stand-up

19. 19
Facilitating Daily Standup aka Daily Scrum (continued)
• Scrum Master should ensure that the Agile Team reviews Sprint Burn down chart
during Daily Scrum and discuss re-planning, as required:
0
50
100
150
200
250
300
350
400
450
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
Trend line
0
50
100
150
200
250
300
350
400
450
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
-200
-100
0
100
200
300
400
500
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
Trend line
Trend line

20. 20
Video #2: Daily Standup aka Daily Scrum
How to: Improve Daily Scrum

21. 21
Scrum Master Facilitates Scrum Ceremonies (Continued)
• Ensure that:
• Sprint review happens at regular credence at the end of the Sprint
• Time boxing Sprint review session, e.g.:
2 weeks Sprint can have 2 hours of Sprint Demo
• Team has met with “Definition of Done” for all completed stories
• Product/Service Owner accepts or rejects stories based on story acceptance
criteria
• Rejected stories are moved back to Product/Service Backlog and re-
prioritized
• Make note of any course correction on implementation
• Also new stories are created for any additional feedback/changes
Sprint Demo

22. 22
Video #3: Sprint Demo
How to: Improve Sprint Reviews

23. 23
Scrum Master Facilitates Scrum Ceremonies (Continued)
• Ensure that:
• Teams are doing retrospective at the end of every Sprint
• Team looks back and considers how the work was done during Sprint, how well it
was developed and delivered, and also is there way for further improvement
• During Sprint, make your own observations about how team is working. Unless it
is very critical, don’t provide any immediate feedback during Sprint. But discuss
these observations during retrospective
• Team uses Sprint retrospective to identify further improvements to become high
performance team
• Action items are tracked and closed (i.e. do not repeat in subsequent sprints)
Sprint Retrospective

24. 24
Video #4: Sprint Retrospective
How to: Improve Sprint Retrospectives

25. 25
Coaching Team- Small Team Dynamics
Enabling Team to
set Clear and
Realistic Goals
Encourage team
to build Cross-
Functional
Capabilities
Motivate team to
adopt
Engineering
Practices as Team
matures
Drive Team towards
“High Performance”
through focus on
Continuous
Improvements
Ensure
Transparency
through Open
Communication
within the Team
Enabling Team to
be Self-Organized
Elevate the “One
Team“ Spirit
through various
Team building
Activities

26. 26
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
1
Coaching Team- Small Team Dynamicsd
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh

27. 27
User Story Map: Begin With End In Mind
• Release Planning
starts with User Story
Mapping
• Align stories as per
user activity (2nd line)–
helps with grouping
the features (1st line)
toward the activity
• High value items at
the top and low value
items at the bottom
• Stories
(Product/Service
Backlog) categorized
by Releases
(Release Backlog)
• Incrementally realize
the Product Goals
optionality
necessary
less
optional
more
optional
Release 1
Release 2
Release 3

28. 28
User Story map Exercise
• Identify an Epic from your current engagement (1 per group)
• Create a user story map for 1 or 2 personas, similar to one below: What stories can we tell?

29. 29
User Stories creation
“As a <role>, I want <goal>, so that <benefit>”
User stories provide a different communication strategy than
traditional requirements, telling us WHO wants WHAT and WHY:

30. 30
I N V E S T
Independent Negotiable Valuable Estimable Small Testable
- Make
stories as
independent
as possible
from each
other
- Start with a
brief
description
- Details
emerge in
discussion &
negotiations
- Users and
customers
perceive
value in the
deliverables
- Domain and
technical
knowledge
allow the
team to
provide
estimates
- A team can
finish one
story in a few
days, and
several in
every sprint
- Acceptance
(testing)
criteria and
technique are
specified
clearly
Summary: Invest in Writing Good User stories

31. 31
Life Cycle of a User Story
Product/Service Owner PO + ARCH + LEAD PO + QA + LEAD PO + Team
Product/Service Owner
writes epics that are
negotiable and has
relevant business value
Architect and Team Lead
negotiate with PO/ SO to
create vertical slices of
epics to shape small and
independent stories
QA ensures stories are
testable and estimable
with scenarios for each
user story
Additional story split along
scenarios and acceptance
criteria may occur
Team receives well
packaged user stories
Team negotiates user
stories with the
Product/Service Owner
Team sizes story for
understanding and
provides estimate
Negotiable
Valuable
Independent
Small
Estimable
Testable

32. 32
Break #2

33. 33
Exercise #2: Decompose Epic into User Stories from Story Map (Template)
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
Participate in user story grooming session to write 5 user stories from your Story Map
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
As A:
I want:
So That:

34. 34
Exercise #2: Decompose Epic “Send Money Using Mobile Devices” (Example)
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Teams Participated in user story grooming session to come up with something like this:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff

35. 35
Exercise #2: Refining User Stories with BDD template (Example)
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. GIVEN Apple as gateway
WHEN user enters payment
THEN Process payment
2. GIVEN card WHEN Pay THEN hold
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. GIVEN Square as gateway
WHEN user enters payment
THEN Process payment
2. GIVEN card WHEN Pay THEN hold
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. GIVEN PayPal as gateway
WHEN user enters payment
THEN Process payment
2. GIVEN card WHEN Pay THEN hold
Dependencies
Risks
Non-functional Requirements
Teams Participated in user story grooming session to come up with something like this:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff

36. 36
Team-Based Estimation: Overview
Can we Estimate Size of cars?
Pretend you and your team are looking out a
window at a parking lot and are tasked with
estimating the size of the cars.
Relative Easier than Absolute
•Toyota Corolla in the foreground is a small car
•The Ford Excursion is neither small nor large,
yet looks smaller to team based on distance
Team Eliminates any Bias
Team can discuss and eliminate the bias that the
distance causes to come up with a more correct
way by doing relative sizing of the two vehicles.
Ford Excursion
Toyota Corolla

37. 37
Why Team-Based Estimation: With Sizing Board
• Increases accuracy by including all perspectives
• Builds a shared understanding of what needs to be
done and what items may potentially affect completion
• Creates shared commitment to achieving the sprint
goals and will give everyone – from analyst to developer
to tester – a vision for how complex the work will be
• Use modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20)
to size user stories
• Always triangulate with other stories, e.g. an 8 point
story should take 4 times longer than a 2 point story
• Avoid Outliers- ensure that stories have similar sizes,
e.g. stories having sizes 3,5,8 instead of sizes 1,5,13
• This increases predictability, reduces variability

38. 38
Sprint Backlog Estimation (Using “Planning Poker”)
Each estimator gets a
deck of cards
Product/Service
Owner reads a
story
Estimators
privately select
cards
Cards are turned
over
Discuss
Differences
Re-estimate
Each estimator is given a
deck of cards with the
values listed above.
For each backlog item to
be estimated,
Product/Service Owner
reads description.
Each estimator privately
selects a card
representing their
estimate.
All cards are
simultaneously turned
over so that everyone
can see each estimate.
High and low estimators
explain their differences..
Re-estimate until
estimates converge. Use
timer if process takes too
long.
Adapted from Mike Cohn. Agile Estimating and Planning, 2005.
Using “Planning Poker” in a Sprint Planning Session combines expert opinion, analogy, and
disaggregation for quick but reliable estimates

39. 39
Exercise #3: Planning Poker for User Stories (Template)
Domain
Banking
Title Priority
High
Story
Points
<?>
Description
Acceptance Criteria
Participate in Planning Poker session to size user stories from story map. Use Sizing Board.
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<?>
Description
Acceptance Criteria
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<?>
Description
Acceptance Criteria
As A:
I want:
So That:

40. 40
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Teams Participated in Planning Poker session and used Sizing Board for sizes like these:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff
Exercise #3: Planning Poker for Epic “Send Money Using Mobile Devices” (Example)
3 5 8

41. 41
Backlog Management - Priority Drives the Planning
Iteration / Sprint
Release
Priority
High
Low
Roadmap
Value
Risk
Cost
Knowledge

42. 42
How to Prioritize Stories: MoSCoW Principle as an option
MoSCoW
– Prioritizes stories in four categories
Must Have - Stories that must be included in the project delivery time-box for the project success
Should Have - Stories not critical but should be included if at all possible
Could Have - Less critical but nice to have stories
Won’t Have - Least critical and lowest payback items
• Appropriate mix of stories in each category can be implemented for a release/sprint
• Example 50% can be Must have, 30% Should have, 15% Could have and 5% Wont have

43. 43
How to Prioritize Stories: Risk Analysis as the other option
High Risk
Low Value
High Risk
High Value
Low Risk
Low Value
Low Risk
High Value
Value
Risk
Low
High
High
Avoid Do first
Do Last Do second
Value
Risk
Low
High
High
To optimally prioritize feature it is important to consider both risk and value
Business Dimensions
 The desirability of the story to a broad base of users or customers
 The desirability of the story to a small number of important users or
customers
 The cohesiveness and ordering of the stories in order to deliver the
release end-goals
 Business seeks for advice from the technical team but if there is
disagreement, Business might still push for the feature
Technical Dimensions
 Technical Complexity
 Technical Feasibility
 The technical risk that the story cannot be completed as
desired
 The impact the story will have on other stories if
deferred (consider high risk story first)

44. 44
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
1
Coaching Team- Small Team Dynamicsd
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh

45. 45
Metrics
• Burndown
• Team Velocity
• # of Stories planned vs accepted
• Unit test coverage
• Open defects
Team Metrics

46. 46
Burndown Chart
Visible indicator of progress, allows the
team to self-correct
Helps you measure how much work is
left to do vs how much time is left
Automatically generated by Jira by
team members updating their tasks
Ideal Sprint Work
Actual Sprint Work
completed

47. 47
Team Capacity
Determining the team’s capacity is critical to a successful planning session and should be the first
activity in the planning meeting. Plan for 80% allocation for dedicated team members.
Team Member PTO/Holiday Allocation
(Max 80%)
(in days)
Michael 0 80% 10 x .8 = 8
Randy 3 80% 7 x .8 = 5.6
Tito 0 80% 10 x .8 = 8
Jermaine 0 80% 10 x .8 = 8
Janet 2 40% 8 x .4 = 3.2
Peter 1 25% 9 x .25 = 2.25
35 days (Total Team Capacity)
Assume 10 day sprints

48. 48
Team Velocity
Velocity is the average number of story points completed by a team in an iteration, and is used to
understand team limits while defining the amount of scope that can be committed to in a sprint.
Exercise:
Assume the following team data:
Sprint 1: 35 story points
Sprint 2: 38 story points
Sprint 3: 42 story points
Sprint 4: 40 story points
What is team’s average velocity (based on trend line)?
If team has 210 story points worth of pending work,
how many sprints will be needed to complete work?

49. 49
Stories planned vs. accepted
Used to show how
well a team is
implementing
story-level
acceptance criteria
0
1
2
3
4
5
6
7
8
Sprint 1 Sprint 2 Sprint 3
Stories Planned vs Accepted
Stories Planned Stories Accepted

50. 50
Unit test code coverage
Visible indicator of code risk that helps a team
measure and characterize potential bugs in the code
Helps track improvements in unit test coverage

51. 51
Outstanding defects
Visible indicator of quality issues, that helps a team measure bugs and track quality changes over time.

52. 52
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Tasks (Sequence#, name, estimate, day#)
1. Implement payment gateway I/F (4h, d2)
2. Create Wireframe for UI (2h, d3)
3. Implement UI for transaction (1h, d4)
4. End-To-End Test for Vertical Slice (3h, d5)
5. …
6. …
Exercise #2: Burndown Chart for Epic “Send Money Using Mobile Devices” (Template)
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Tasks (Sequence#, name, estimate, day#)
1. Implement payment gateway I/F (4h, d2)
2. Create Wireframe for UI (2h, d3)
3. Implement UI for transaction (1h, d4)
4. End-To-End Test for Vertical Slice (3h, d5)
5. …
6. …
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Tasks (Sequence#, name, estimate, day#)
1. Implement payment gateway I/F (4h, d2)
2. Create Wireframe for UI (2h, d3)
3. Implement UI for transaction (1h, d4)
4. End-To-End Test for Vertical Slice (3h, d5)
5. …
6. …
Participate in creating burndown chart using task related data for these user stories:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff
3 5 8

53. 53
Instructions: Compare and Contrast Traditional vs. Agile
1. Designate someone to be Scrum Master
2. Sequence of prioritized tasks will affect the burn down.
3. Scrum Master facilitates plotting of tasks burning down on the chart
4. Scrum Master and Team discuss the chart and analyze the variations
e.g. hockey stick burndown and so on
Exercise #2: Burndown Chart for Epic “Send Money Using Mobile Devices” (Instructions)

54. 54
Exercise #2: Burndown Chart for Epic “Send Money Using Mobile Devices” (Example)
Your burndown charts may look somewhat like this:
Actual Sprint Work
Planned Sprint Work
0
50
100
150
200
250
300
350
400
450
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
0
50
100
150
200
250
300
350
400
450
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual
-200
-100
0
100
200
300
400
500
Day 0 Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
RemainingHours
Sprint Burn Down
Planned Actual

55. 55
How to Track progress using Big Visible Information Radiators?
Scrum Boards & Charts
• Allow to view Product
Progress over time
• Track against
Release/Project Scope
line
• Charts updated at the
end of every sprint
• Allows team to make
course correction if
significant deviation
from Ideal trend line

56. 56
Break #3

57. 57
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
1
Coaching Team- Small Team Dynamicsd
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh

58. 58
Removing Impediments/Obstacles: Overview
• Types of Impediments/Obstacles
• Physical (e.g. server/access for dev/stage env)
• Organizational (People-ware within teams/management)
• Skill (e.g. not enough x in y)
• Example of Levels of impediments/obstacles
Management
• Team level (scrum master)
• Management Level
• Portfolio (Exec Level)
• Obstacle card is like an index card
• Front side:
• Name
• Owner
• Due Date
• Problem Statement
• Vision
• Back side:
• Detailed Log (actions/status)

59. 59
Removing Improvements: Obstacle Moves across (For Example) 3 Levels
• Team-level:
• Scrum Master tries to resolve obstacle with help of team.
• Obstacle is logged on an obstacle board.
• Management-level:
• When the team cannot resolve it, or when it is org-level escalation, SM gets
manager involved.
• For business escalation, Product/Service Owner gets manager involved.
• It shows up on management-level obstacle board.
• Exec-level:
• When manager cannot resolve the obstacle, it shows up on exec-level obstacle
board.
• This board is similar to the team level, except that last column mentions “resolved”,
as it cannot be placed “on hold” at exec level.
• Owner can resolve/dismiss obstacle at regular interval.

60. 60
Removing Impediments/Obstacles: Example of Governance
• Team-level:
• Scrum Master will ensure that each
obstacle is logged on an obstacle
board.
• This can be physical board in team
area or team room, marked with “Do
Not Remove” sign.
• Management-level:
• For org-level escalation, functional
manager will use online obstacle board
(virtual Kanban board)
• For business escalation, PO/manager
will use similar obstacle board.
• Management-level online obstacle
boards:
• This level obstacle board can be a Kanban
board with the following value stream:
• Entire middle-management should have
access to this board.
• Exec-level:
• Exec-level obstacle board
can be physical board
outside exec room.
Alternately execs can
access management level
virtual board for escalations
of obstacle(s) in-progress.

61. 61
Exercise #3:
Top 3 obstacles that your teams generally encounter. Decide which level of escalation those belong to.
In your experience so far, what are the top 3 obstacles a Scrum Master can
help remove, so that the scrum team stays productive?
What are some of the escalation paths available to this Scrum Master?

62. 62
Agenda
Agile and Scrum Flow – A Recap
Agile for Scrum Masters- Scrum Master Role2
Scrum Master vs. (traditional) Project Managera
Facilitating Scrum Ceremoniesb
Sizing, Estimating and Prioritizing Backlogc
1
Coaching Team- Small Team Dynamicsd
Tracking & Reporting Worke
Removing Impedimentsf
Pitfalls Scrum Master needs to Avoidg
Qualities to be an effective Scrum Masterh

63. 63
Pitfalls in Scrum Master Role
Scrum Master as Project Manager
• Tendency to go back
to traditional ‘Command and
Control’ management especially
when in Crisis
• Conducting Daily Standup as
status update meetings
• Allocating tasks during Sprint
planning meeting
Scrum Master as Decision Maker
• Making project decisions instead
facilitating Agile Team to make
appropriate decisions
• Providing Sprint commitment in
Sprint planning meeting
Scrum Master as Communication Channel
• Act as “Single Point of Contact” for any
communication with Product/Service
Owner or other stakeholders
Assuming Delivery Ownership
• Projecting as leader of Agile
Team and assuming product
delivery ownership instead of
facilitating Agile Team to take
ownership of their commitments
Scrum Master
Pitfalls to Avoid
X
X
X
X

64. 64
7 Servant Leadership Traits
Primary Source: Mike Cohn “"Leader of the Band: Six Attributes of the Good Scrum Master"
Empowering
& Developing
Others
Serving
Others
Vulnerability
& Humility
Open,
Participatory
Leadership
Visionary
Leadership
Courageous
Leadership
(integrity &
authenticity)
Inspiring
Leadership

65. 65
10 Principles of Servant Leadership
Primary Source: Mike Cohn “"Leader of the Band: Six Attributes of the Good Scrum Master"
Persuasion – (building consensus)
Awareness – (of self and of others)
Healing – (search for wholeness of self &others)
Empathy – (understanding)
Listening – (to self and others)1
2
3
4
5
Building Community – (benevolent,
humane, philanthropic, to benefit others)
Commitment to Growth – (personal,
professional, spiritual of self and others)
Stewardship – (holding institution in trust
for the good of society)
Conceptualization – (dreams and of day-
to-day operations)
Foresight – (ability to learn from past & see
future )6
7
8
9
10

66. 66
Exercise #4:
Apply your knowledge about being Scrum Master to solve the following situation you will encounter a lot.
Scenario:
Faced with pressure from stakeholders, the Program Manager tells the Scrum
Master to tell the teams how much work they need to complete in the next
sprint.
What is the best way to deal with this scenario?

67. Thank You