A Workshop for Product Owners, Scrum Masters, and Team Members for Improving Team Performance

The Scrum Master and the Product Owner are critical to success of
agile development teams using Scrum. Making changes to the process,
improving team members actions, and empowering members to
perform Scrum activities correctly, to increase the probability of project
success.

Baseline Assumptions
§ Our program is subject to FAS OCIO Earned Value
Management Handbook, Revision 2.0, 1 Feb 2012.
§ The customer progress is in units of measure
meaningful to the decision makers …
• Dollars and Hours for contract deliverables
• Stories and Story Points for software development planning
§ If we’re doing Scrum, then we have three (3) roles
• Product Owner
• The Development Team
• Scrum Master
2

Contents of the Work Shop
§ Root Causes Analysis of Acquisition Gateway
§ Deploying Scrum on Acquisition Gateway
§ The Product Owner
§ The Scrum Master
§ The Development Team
§ Estimating
§ Communities of Practice
§ Artifacts of Large Scrum Programs
§ Kanban
§ Resources
3

Ceremony is the basis of all these
Success Factors
There Are Many Success Factors
for Agile Software Projects
4

12 Practices of a Success Scrum
Team†
5† “A Simple Model of Agile Software Processes – or – Extreme Programming Annealed,” Glenn Vanderburg

Starting with an Assessment
6
Practice Yes? No?
1 Pair Programming
2 40 Hour Work Week
3 On Site Customer
4 Planning Game
5 Coding Standards
6 Acceptance Testing
7 System Metaphor
8 Unit testing
9 Refactoring
9 Simple Design
10 Short Release Cycle
11 Continuous Integration
12 Collective Ownership
13 Refactoring

Starting with Root
Cause Analyses
§ Warning Signs of Agile Project
Problems
§ Project Failure Modes
§ Scrum Master Anti-Patterns
§ Scrum Anti-Patterns
§ Scrum failure Modes
§ Success Requirements
Prior Root Cause Analyses have
performed for the AG project
This workshop will start with that
information, but have a collective
assessment of the current
situation as well
7

Root Cause Assessment Framework
8
Many of these causes are in place on our Program

People
§ Scrum processes not being followed
§ Team appears to not be present in meetings
§ Preparation for engagement appears low
§ Cohesion of team appears low
§ Team not holding each other accountable
§ Committed work not visible to all team members
9

Processes
§ Roles not clear, with overlapping concerns
§ Teams not communicating
§ Teams not meeting their commitments
§ Meeting agenda not visible to all members
10

Tools
§ Rally not being used to its best effectiveness
§ Accountability for items not clear
§ Lack of cohesive tool sets
11

If I could fix
three things,
they would be
Every one take 3
cards and write
one thing on each
card that you
would like to see
fixed.
As a group we’ll
consolidate
everyone's
cards and use
the Top 3 to
guide our
workshop this
week.
12

Detailed
Activities for
Deploying Scrum
on Acquisition
Gateway
§ Product Owner
§ The Scrum Master
§ The Development Team
§ Communities of Practice
§ Training and Deployment Plan
§ Resources
Developing qualified Scrum
Masters, Product Owners, and
Team members for Acquisition
Gateway will remove many of the
gaps in the current assessment of
Agile maturity and how to make
improvements in that maturity.
13

Framing Assumptions†‡
14
Scrum Team Roles
Product Owner
§ Responsible for ROI
§ Constantly re-prioritizing Product Backlog
§ Synthesizes interest of stakeholder, including team
§ Negotiates Sprint Goal and Backlog Items with Team
§ Final arbiter of requirements questions
§ Accepts or reject each product increment
Scrum Master
§ Helps resolve impediments
§ Facilitates Scrum Processes
§ Facilitates Team Self Organization
§ Helps keep team in the zone
§ Helps Product Owner with release planning
§ Shields Team form external interference
§ Enforces timeboxes, separation of roles
§ Keeps Scrum artifacts visible
§ Advocates improved engineering practices
§ Hos no authority
Team
§ Cross functional
§ Autonomous
§ Self organizing
§ Held responsible for commitments of each Sprint
§ Ideally co-located
§ Ideally 7 + 2 members
† Adapted from Danube Technologies ‡ Identifying Acquisition Framing Assumptions Through Structured Deliberation

First Some Words About Teams
§ No team arises without a performance challenge that
is meaningful to those involved.
§ Team success is created by building a strong
performance ethic rather than by establishing a
team‒promoting environment alone.
§ Real teams always find ways for each individual to
contribute and thereby gain distinction.
§ Discipline creates conditions for team performance ‒
by making clear and consistent demands reflecting
needs of the customer, then holding themselves and
organization relentlessly accountable.
15
When we say Team, what do we mean?

Not All Groups are Teams†
§ Strong, clearly focused
leader
§ Individual accountability
§ Purpose is the same as
broader organizational
mission
§ Individual work products
§ Runs efficient meetings
§ Measures effectiveness
indirectly from outcomes
§ Discusses, decides, and
delegates
§ Shared leadership roles
§ Individual and mutual
accountability
§ Specific team purpose that
the Team itself delivers
§ Collective work products
§ Encourages open-ended
discussion and active
problem solving meetings
§ Measures performance
directly by assessing
collective work products
§ Discusses, decides, and
does work together
16
A Working Group A Team
† The Discipline of Teams, Jon Katzenbach

Some Katzenbach Quotes on Teams
17
Teams do not seek consensus; they seek the best
answer to the problem at hand.
‒ Katzenbach
What sets high-performance teams apart, is the
degree of commitment, particularly how deeply
committed the members are to one another. ‒
Katzenbach
A team is a small group of qualified individuals who
hold each other accountable for a shared outcome.
‒ Regan (Katzenbach)
This should be our goal as we proceed with this
workshop and move to producing value for GSA

Product Owner
Styles
§ The Auctioneer
§ Straight Up Project Manager
§ The MBA
§ The Catalyst
§ The Mini CEO
§ The User Advocate
§ The Technologist
After the Scrum Master, the
Product Owner is the next critical
position to be addressed for our
Program
20
7 Product Manager / Product Owner Archetypes, John Cutler,
https://medium.com/@johnpcutler/7-product-manager-product-owner-
archetypes-db4b484e134d

The Product Owner
The Product Owner is …
§ Responsible for maximizing the value of the product
and the work of the Development Team.
§ Is the sole person for managing the Product
Backlog, including:
• 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
• 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
21

Product Owner Roles ‒ Restating
the Obvious
§ Be available for the Team and the Scrum Master
when needed
§ Have sufficient Business knowledge to define the
needed Value
§ Possess Communication skills needed to remove
all impediments to understanding what Done
Means in units of measure meaningful to the
Decision Makers
22

Product Owner Framework
§ Mature organization don’t get stuck on Prodict
Owner Role prescription
• Not getting enough value
• Low impact from the role
• Don’t prefect the role, prefect the product development
process
§ PO needs organizational capabilities, not heroic
efforts
• Educated decision making for business opportunities
instead of technical requirements
23

Product Owner Anti‒Patterns (1)[4,5]
1. No Single Product
Owner for One
Team
2. Interference in Daily
Work
3. Stories Built around
Product Layers
4. No Projection of the
Product Backlog
5. Using Estimates to Set
Deadlines
6. Too busy for the Team
7. Send in a Proxy
8. Sacrifices quality for
shipment date
9. Confusing PO with SM
roles
10. Expects a stretched
commitment
11. PO because they’re a
department lead
12. Not their role to maintain
Product backlog
13. Thinks SM is just a PM
14. Refuses to choose
between top 5 priorities
15. Insists on architect the
solution
16. Does not regard self as a
team member
24

Product Owner Anti‒Patterns (2)[4,5]
17. Not collaborating with Team
on why Product backlog
items makes sense
18. Running the team from
Rally instead of interacting
with rich media
19. Pursuing functionality as-is
in terms of requirements,
instead of questioning the
reason in front of customer
20. Treating Product Backlog as
an endless list of
requirements, instead of a
pool of optional ideas
21. Requesting requirements
without valid understanding
of business needs and risks
22. Having no clear acceptance
criteria per Use Story
23. Focusing on the technical
aspects of a User Story,
rather than the Business
aspects
24. Not understanding the
Team’s capacity for work
25. Focusing on the “As a … I
want to ... So that.” rather
than the actual purpose,
objectives, and narrative of
the story
26. Not providing early
feedback for ongoing
work
25

Product Owner Anti‒Patterns (3)[4]
27. Not considering clarity of
Product Backlog from
business perspective before
involving team ‒ Definition
of Ready
28. Not letting team Members
talk directly with
stakeholder regarding
solution
29. Relying on a Scrum Master
only to get blockers from
definition or
implementation of Product
backlog items out of their
way
30. Having no clear acceptance
criteria per Use Story
31. Focusing on the technical
aspects of a User Story,
rather than the Business
aspects
32. Not understanding the
Team’s capacity for work
33. Focusing on the “As a … I
want to ... So that.” rather
than the actual purpose,
objectives, and narrative of
the story
34. Not providing early
feedback for ongoing work
26

Product Owner Styles
The Good, The bad, and The ugly
27
Style The Good The Bad The Ugly
The Auctioneer Collect needs
No connection
between Team and
Customer
VOC hidden
Straight Up Project
Manager
Good planning of
features to deliver
value
Team because labor
Agility reduced from
lack of Team
feedback to
customer
The MBA
Direct connection to
business value
Commits too early to
value proposition
Technology impacts
lost to customer
The Catalyst
Direct interaction
with customer
Team not protected
from changing
customer needs
No central location
for PBI management
The Mini CEO
High visible to all
participants
Multiple user
interaction
Command and
control of team
The User Advocate
Missing feedback
from Team
Project Manager like
interactions
The Technologist
Another set of eyes
on the technology
Centralized
directives for
architecture and
technology
Team just labor to
PO’s guidance

The Auctioneer
28
Stakeholders
Team
PO
Feature RequestsCapability Outputs

The Auctioneer
§ The Product Owner arbitrates the Features that
will be produced by the Team through some sort
of auctioning of the Value produced in exchange
for the Cost of that Value.
§ The skilled auctioneer creates a market for
valuable engineering resources, and figures out
how to get the various stakeholders to play the
game.
§ The skilled auctioneer fosters a shared
understanding of the trade offs between "value"
and "cost".
29

Straight Up Project Manager
30
Stakeholders
Team
PO
Feature RequestsStatus of Capabilities

Straight Up Project Manager
§ The Product Owner manages which Features will
be produced by the Team in the same way a
Project Manager does.
§ A planned order of which Features are produced
to meet the planned Value stream negotiated
with the Customer during the Project Planning
session early in the project.
§ The status of the delivery of Features is used to
plan future work on the project.
31

The MBA
32
Team
Biz
Goals
PO
Technology Org
User
Customer

The MBA
§ Lays out the Business Case for the developed
software
§ Facilitates the technology organization’s
interaction with the team
§ Does the analysis of the alternatives from the
Business to the technology organization for
products produced by the Team
§ A business assessment of the Product Manager
aspects of the Product
33

The Catalyst
34
Team
Goals
PO
User Market Business
Data and
Feedback
Experiments
and
Functionally

The Catalyst
§ A facilitator between the interested parties
§ Team needs to make the connection, Product
Owner only sets up the connection
35

The Mini CEO
36
Team
Goals
User Market
BusinessPO
Results

The Mini CEO
§ Represents more than the User
§ Has skills and experience to represent Marketing
direction and the business as a whole in that
market
§ This role is considered more of a Leader.
§ A hierarchy exists, but the team accepts it.
§ The team is outwardly and inwardly focused.
37

The User Advocate
38
Team
User
PO
User Experience Design
Technology Organization

The User Advocate
§ Lobby’s on behalf of the user for the Features
and Stories in the Product Backlog.
§ Assumes the User has all the knowledge,
experience, and skills needed to define the
contents of the Product Backlog.
§ A surrogate for the user in the users absence
39

The Technologist
40
TeamBusiness
User
Experience Design
Goals
Results
PO

The Technologist
§ The Product Owner is the intellectual owner of
the Technological solution.
§ This is the Chief Engineer or Chief Architect
paradigm.
41

Which Role(s) Do We Want Our
Product Owner(s) to Play?
42
Role?
Auctioneer
Project Manager
MBA
Catalyst
Mini CEO
User Advocate
Technologist

Characteristics of Good PO
43
C ollaborative
R esponsible
A uthorized
C ommitted
K nowledgeable
No Matter the Role, the PO Must Be …

Scrum Master
Overview
§ Scrum Master services to the
project
§ Tasks performed by the Scrum
Master
§ Time allocation of roles
§ Evidence of Role being
performed
§ Training plan for Scrum
Masters
Developing qualified Scrum
Masters for each project will
remove many of the gaps in the
current assessment of Agile
maturity and how to make
improvements in that maturity
44

The Scrum Master Serves Three
Project Participants
45
Scrum Master
The Product
Owner
The
Organization
The
Development
Team
§ Technique to Effectively manage product Backlog
§ Help team understand product planning
§ Ensure Product Owner knows how to arrange
Product backlog to maximize value
§ Facilitate Scrum events
§ Coach the Development Team in self-organization
and cross-functionality activities
§ Help create high value products
§ Remove impediments
§ Lead and coach organization in Scrum adaptation
§ Plan Scrum implementation within the organization
§ Help enact Scrum and empirical product
development
§ Work with other Scrum masters to increase
effectiveness of Scrum

The Scrum Master Serves Three
Project Participants
46
Scrum Master
GSA Project
Manager
The
Organization
The
Development
Team
§ Status of the Project Lifecycle
§ Identify impediments out of SM control
§ Provide cross team dependences
§ Improve cohesion across multiple teams
§ Provide technology integration support
§ Coach the Development Team in self-organization
and cross-functionality activities
§ Help create high value products
§ Remove impediments
§ Lead and coach organization in Scrum adaptation
§ Plan Scrum implementation within the organization
§ Help enact Scrum and empirical product
development
§ Work with other Scrum masters to increase
effectiveness of Scrum

42 Tasks of the Scrum Master [1]
Meetings
1. Prepare for meeting
2. Moderate meeting
3. Post processing of meeting outcomes
4. Hold Retrospective meeting
47
Team Dynamics
5. Coaching team members
6. Mediating through conflicts.
7. Helping the team to make decisions.
8. Fostering the developer team’s self-organization.
9. Mediate general conflict of goals between development team (high technical quality) and product
owner (more features).
Learning
10. Continuing learning of everything Agile
11. Consulting on everything Agile.
12. Help create information radiators.
13. Giving feedback to team.
14. Encouraging the use of Agile Engineering Practices
15. Challenge team with Agile management innovations.
16. Exchanging constantly with other Scrum masters
17. Doing Gemba Walks.

48
Product
18. Helping to write or split user stories.
19. Helping to write or adapt product visions.
20. Helping to order product backlog items.
21. Helping with the release planning.
22. Being familiar with the team’s work (i.e. the product).
Big Picture
23. Bringing people together who should talk to each other.
24. Keep in touch with every stakeholder regularly.
25. Help the team to report to management.
26. Help further the Agile community within the organization.
27. Organize exchange events.
28. Share insights throughout the company.
29. Be the contact person for everyone regarding Agile.
30. Give learning opportunities to people in the organization
Change
31. Help the team to get rid of impediments.
32. Suggest new metrics for the team as catalysts for change.

49
Mirror
33. Reflecting Agile and Scrum values to the team.
34. Reminding the team of their arrangements (e.g. policies).
35. Helping the team to continuously improve their process.
36. Reflecting issues to the team through observation from outside of the team.
37. Asking open questions.
38. Checking all the models the team uses (e.g. Sprint backlog, metrics, etc.) and show them
differences between the model and the real world.
Miscellaneous
39. Help team stay focused
40. Help team maintain their Scrum tools
41. Help team and Product Owner find a suitable Definition Of Done
42. Help team and Product Owner find a suitable Definition Of Ready

Scrum Master is a Full Time Job [2]
50
Scrum Master Activities during a 2 Week Sprint Hours
Ceremonies and Meetings ‒ daily scrum, scrum of scrums,
Sprint review
21
Team Activities ‒ 1 on 1 coaching, removing impediments,
collecting and reporting metrics, organizing team
16
Learning ‒ reading, preparing hot topics, coaching technical
processes, Gemba walks
21
Product Owner support ‒ reviews, coaching, grooming,
planning
9
Organization ‒ Practice, sharing, and exchanging with other
SM’s, coaching management
17
84

Scrum Master Training Plan
§ Identify candidates for Scrum Master on each
portfolio
• 20 to 25 people
§ Take Self training and get PSM certification at
www.scrum.org
• Scrum Master Training Manual: A Guide for the Professional
Scrum Master at
http://www.capeprojectmanagement.com/agile_exams.html
• Scrum Master Certification: PSM Exam: Preparation Guide
and Handbook
• https://capeprojectmanagement.learnupon.com/store/52455
-on-demand-scrum-master-certification-training-90-days-
access
51

The Scrum Master
The Scrum Master is responsible
for ensuring the Scrum practices
are understood and enacted, by
ensuring the Development Team
adheres to Scrum Theory,
Practices, and Rules.
The Scrum Master focuses on the
How not on the What of the
outcomes from the Development
Team
52
Scrum Master role is
crucial, as it acts as the
buffer between the
Development Team, the
Product Owner, and the
process overhead created
by Scrum.

53
The Scrum Master is the Leader of the Band†
The Art of
conduction consists
in knowing when to
stop conduction to
let the orchestra play
‒ Herbert von
Karajan
† ”Leader of the Band – Six Attributes of a Good Scrum Master” ‒ Mike Cohn

Three Roles of the Scrum Master
on the Agile Team
§ Development Team ‒ builds and demonstrates
the working software
§ Product Owner ‒ identifies what needs to be built
for each sprint.
§ Scrum Master ‒ coaches the team in
understanding and executing the Scrum process.
54

What is a Scrum Master?
The Scrum Master …
§ is responsible for making sure the Development
Team lives by the values and practices of Scrum.
§ is a coach for the Development Team, helping
the team do the best work it possibly can, using
the values and practices of Scrum.
§ is the process owner for the team, creating a
balance between the Development Team and the
project's key stakeholder, the Product Owner.
55

Roles of the Scrum Master (1)
§ does anything possible to help the team perform
at their highest level.
§ removes any impediments to progress,
facilitating meetings, working with the product
owner to make sure the Product Backlog is in
good shape and ready for the next Sprint.
§ role is commonly filled by a former project
manager or a technical team leader but can be
anyone.
56

Roles of the Scrum Master (2)
§ is often viewed as a protector of the team.
§ protects the team by making sure they do not
over-commit themselves to what they can
achieve during a sprint due to pressure from an
overly aggressive product owner.
§ and also protects the team from complacency.
57

Scrum Master
Assessment†
§ Artifacts
§ Serve as a Mirror
§ Engineering Practices
§ Nurture Team Dynamics
§ Product Owner
§ Learning Organization
For the Scrum Master to mature
in the role, here’s a check list to
serve as a guide.
58
† Scrum Master Growth, Luis Gonçalves
The Team must understand,
support, and acknowledge the
roles and responsibilities of the
Scrum Master

Responsible for Scrum Artifacts
§ Use different exercises for Agile Retrospectives to help the
team express their problems/victories in the best way
§ Act as a buffer between external distractions and the team
§ Help team to maintain the Story Board
§ Help team to maintain the Burndown chart
§ Help team to visualize the work in progress (WIP)
§ Help team to constantly improve the DoD (Definition of Done)
§ Help team to constantly improve their collaboration with the
Product Owner to not be necessary a DoR (Definition of
Ready)
§ Help team members to create information radiators
§ Read about Scrum in order to get better in what I do
§ Help team to keep good Scrum Ceremonies
§ Help team identify positive and negative changes during
retrospectives
60

Responsible to Serve as a Mirror
to the Team
§ Reflect Agile and Scrum values to the team
§ Remind the team of their arrangements and their commitments
§ Help team to continuously improve their process
§ Reflect issues to the team through observation from outside of the
team
§ Ask open questions
§ Check all the modules the team uses (Spring backlog, metrics, etc.)
and show them differences between the model and the real world
§ Facilitate team's decision making rather than making decisions for
the team
§ Ask questions that encourages the team to look at decisions from
new perspectives
§ Articulate facts, Help the team to see things they may have
overlooked, and helps them to rethink
61

Responsible for Engineering
Practices (1)
§ Articulate facts, Help the team to see things they may
have overlooked, and helps them to rethink
§ Help the team to figure out the right balance between
automated end-to-end tests system tests and automated Unit
Tests?
§ Help the team to write both system “functional” tests and unit
tests in the same language as the system they are developing
so that everyone in the team knows how to maintain the test
setup?
§ Help the team to discover the useful gray area between
system tests and unit tests?
§ Help the team to move towards continuous delivery?
§ Help the team to measure how long the release process takes
§ Help the team to make all metrics transparent to everyone in
the organization
62

Practices (2)
§ Help team members to do Pair / MOB programming in
order to get knowledge exchange during the sprint?
§ Reflect and see if the sprint board reflect what the team is
actually doing? Or are they working on something that is not
related to Sprint Goal?
§ Encourage rotation in technical areas of concern: functionality,
component/layers, roles aspects, etc.
§ Reflect about what is missing in order to make the
environment better for everyone, prioritizes improvement
activities and makes them happen
§ Help team to find access to external sources of information
§ Help team create transparency and urgency around
continuous system integration
§ Help team by encouraging them to create small automated
acceptance tests at the beginning and evolving from there
63

Practices (3)
§ Help team by encouraging them to coach each other in TDD,
refactoring, simple design
§ Help team by encouraging them to use human-readable
acceptance tests
§ Help team by encouraging them to adopt a "thinking
backwards" approach: what is the expected behavior of the
functionality what we area bout to code
§ Help team by encouraging them to do pair and peer review
§ Raise the bar in order to help the team to continuously
improve
§ Help team to identify possible improvements on Engineering
practices
64

Responsible to Develop and
Nurture Team Dynamics (1)
§ Learn about System Coaching and apply it to my daily job
§ Learn about Mediating through conflicts and apply it to my
daily job
§ Learn about group decision techniques and apply it to my
daily job
§ Learn about how to fostering the developer team´s self
organization
§ Learn how to mediate the general conflict of goals between
development team and product owner
§ Help team members to hold each other to high standards
§ Improve our team environment in order to have a trustful
setting where people speak freely without problems
65

§ Reflect and find ways to help team reach the state of “flow”?
§ Need to tell people what to do? Am I Helping team
members to volunteer for tasks? Or do you have a more
“command and control” approach with someone telling
people what to do?
§ Help team members leave their titles outside of the office
room? Everyone should help to accomplish something,
Titles are not important.
§ Help team members finding their role within the team
§ Help team to find their own purpose
§ Help team to stablish effective team communication
66

§ Act as a spontaneous leader and encourages self
organization
§ Get aware of the 5 dysfunctions of a team and creates
exercises to improve that
§ Coach the whole team to collaborate
§ Ask team for the answer
§ Let team find their own way
§ Behave as a good facilitator encouraging everyone to
express their opinions
§ Show appreciation for team members who raise serious
issues, even when delivery is at jeopardy
§ Encourage healthy conflict during team meetings
§ Help team to act as a team and not just a collection of
individuals 67

Responsible to Help Product
Owner (1)
§ Help Product Owner prioritize the backlog based on the
value that stories will bring to the customer?
§ Help Product Owner create INVEST stories?
§ Help Product Owner make the backlog visible to everyone?
§ Help Product Owner make the backlog an information
radiator instead of refrigerator?
§ Help Product Owner print out the stories so that everyone
knows what the team is working on?
§ Help Product Owner create release burnups, so everyone
knows where the team stands?
68

Responsible to Help Product
Owner (2)
§ Help the Product Owner with adjusting the Release scope
based on what was delivered?
§ Help write or split user stories together with the team?
§ Help to write or adapt product visions?
§ Help the Product Owner on Impact Mapping or Story
Mapping?
§ Educate the Product Owner about technical debt and how
to avoid it?
§ Focus on business value delivery
69

Responsible to Create a Learning
Organization
§ Invite external speakers to share knowledge internally
§ Organize internal meetups to bring fresh ideas into the
company
§ Share articles from external conferences
§ Create lunch talks to share new ideas
§ Organize Hackathons
§ Organize Innovation Sprints
§ Organize Open Spaces
§ Organize Book Clubs within the organization
§ Consult team members and organization on Agile
§ Do Gemba walks to see what others are doing
70

42 Tasks of the
Scrum Master†
§ Meetings
§ Team Dynamics
§ Learnings
§ Product
§ Big Picture
§ Change
§ Mirror
§ Miscellaneous
There are many tasks for the
Scrum Master. Here are 41 critical
activities that must be performed
during the Sprint, Product
backlog Grooming, and other
Scrum processes
71
† Bernd Schiffer

Meetings
1. Prepare for meeting ‒ agenda, for Team needs
2. Moderate meeting ‒ provide guidance for the
ceremonies of the meetings
3. Post processing of meeting outcomes ‒ collect action
items
4. Hold Retrospective meeting ‒ guide the retrospective
from a topic coverage point of view
72

Team Dynamics
5. Coaching team members ‒ in their role on the Scrum
team
6. Mediating through conflicts ‒ intervention with team to
maintain communication and mutual accountability
7. Helping the team to make decisions – facilitate but don’t
lead, team must be self directed
8. Fostering the developer team’s self-organization –
provide framework for self-organization
9. Mediate general conflict of goals between development
team (high technical quality) and product owner (more
features).
73

Learning
10. Continuing learning of Agile ‒ be source of learning
11. Consulting on Agile ‒
12. Help create information radiators ‒ move Rally small
screen to Big Visible Charts
13. Giving feedback to team ‒ provide constant feedback on
Scrum processes
14. Encouraging the use of Agile Engineering Practices
15. Challenge team with Agile management innovations.
16. Exchanging constantly with other Scrum masters
17. Doing Gemba Walks.
74

Product
18. Helping to write or split user stories ‒ facilitate team
consensus on story decomposition
19. Helping to write or adapt product visions.
20. Helping to order product backlog items.
21. Helping with the release planning.
22. Being familiar with the team’s work (i.e. the product).
75

Big Picture
23. Bringing people together who should talk to each other.
24. Keep in touch with every stakeholder regularly.
25. Help team report to management.
26. Help further the Agile community within the
organization.
27. Organize exchange events.
28. Share insights throughout the company.
29. Be the contact person for everyone regarding Agile.
30. Give learning opportunities to people in the organization
76

Change
31. Help team to get rid of impediments.
32. Suggest new metrics for the team as catalysts for
change.
77

Mirror
33. Reflecting Agile and Scrum values to the team.
34. Reminding team of their arrangements (e.g. policies).
35. Helping team continuously improve their process.
36. Reflecting issues to team through observation from
outside of the team.
37. Asking open questions.
38. Checking all the models the team uses (e.g. Sprint
backlog, metrics, etc.) and show them differences
between the model and the real world.
78

Miscellaneous
39. Help team stay focused
40. Help team maintain their Scrum tools
41. Help team and Product Owner find a suitable Definition
Of Done
42. Help team and Product Owner find a suitable Definition
Of Ready
79

Evidence of the 42 Tasks
80
Meetings Evidence
Prepare for meetings
§ Agenda prepared ahead of time
§ Items collected from team
§ Consensus on priorities of items
Moderate meetings
§ Agenda guides meeting
processes
§ Unplanned items captured and
acknowledged
Post processing of meetings
outcomes
§ Outcomes published
§ Commitments confirmed
§ Unplanned items scheduled for
next meeting
§ Accountability recognized
Hold Retrospective Meetings
§ Follow a formal retrospective
check list
§ Publish meeting minutes

81
Team Dynamics Evidence
Coaching team members § Named members coaching on
each Sprint
Mediating through conflicts. § Keep a diary of activities
Helping team to make decisions. § Keep a diary of activities
Fostering the developer team’s
self-organization.
§ Evolving organization charts
with evolving roles
Mediate general conflict of goals
between development team (high
technical quality) and product
owner (more features).
§ Keep a diary of activities

82
Learning Evidence
Continuing learning of everything
Agile
Increased understanding of Scrum
processes ‒ spreading the word
Consulting on everything Agile
Help create information radiators Posters, cards, check lists
Giving feedback to team
Regularly schedule round table
discussions
Encouraging the use of Agile
Engineering Practices
Be the initiator of “best practices”
Challenge team with Agile
management innovations
Introduce new process
innovations regularly
Exchanging constantly with other
Scrum masters
WIKI content updated regularly
Doing Gemba Walk
(Go see, ask why, show respect)
Using the 10 Gemba Walk
questions

83
Product Evidence
Helping to write or split user
stories
Before and after stories from the
Product Backlog
Helping to write or adapt product
visions
Participate in the product
visioning with process support
Helping to order product backlog
items
Participate in the Product Backlog
grooming with process support
Helping with the release planning
Interact with Release Train
Engineer for process improvement
Being familiar with team’s work
(i.e. the product)
Have an understanding of the
technical work, to provide advice
for process improvement

84
Big Change Evidence
Bringing people together who should
talk to each other.
List of connections
Keep in touch with every
stakeholder regularly.
Scheduled connections
Help team to report to
management.
Record of management meetings
Help further the Agile community
within the organization.
Schedule meetings and reports of
outcomes
Organize exchange events. Agenda of events
Share insights throughout the
company.
Record of information exchange
Be the contact person for everyone
regarding Agile.
Mailing list
Give learning opportunities to
people in the organization
Produce material and distribute
them

85
Change Evidence
Help team remove impediments
to progress and success.
§ Log of impediments, their
removal, corrective actions, and
lessons learned for future
opportunities
Suggest new metrics for the team
as catalysts for change.
§ Processes require metrics to be
tested with a measure and a
counter measure.
§ Keep track of both and show
measurable improvement in
processes and how that
impacts measureable
improvement in the production
of value to the customer

86
Mirror Evidence
Reflecting Agile and Scrum values to
the team.
§ Traceable values of Agile
into actions of the team
Reminding the team of their
arrangements (e.g. policies).
§ Process confirmation
Helping team to continuously improve
their process.
§ Showing current and
improvement of processes
with metrics
Reflecting issues to team through
observation from outside of the team.
§ Continuous improvement
using metrics
Asking open questions.
§ Record of questions and
answers
Checking all the models the team uses
(e.g. Sprint backlog, metrics, etc.) and
show them differences between the
model and the real world.
§ Big Visible Chart of team
performance with metrics

87
Miscellaneous Evidence
Help Team stay focused
§ Assess process efficacy every
day
Help Team maintain their Scrum
tools
§ Assess tools efficacy every day
Help Team and Product Owner
find a suitable Definition Of Done
§ Facilitate DoD in units of
measure meaningful to the
decision makers
§ MOE, MOP, TPM KPP
Help Team and Product Owner
find a suitable Definition Of Ready
§ Facilitate DoR in units of
measure meaningful to the
decision makers

Scrum Master
Time Allocation
§ Ceremonies and Meetings ‒
Scrum is a process framework
with specific ceremonies and
meeting conducted during the
execution of that process.
§ Team Activities – the Scrum
Master looks after the team in a
coaching manner
§ Learning – Scrum success
dependents on continuous
learning, lead by the Scrum
Master
§ Product Owner Interactions ‒
the Scrum Master is the primary
interface with the Product Owner
for the Development Team
§ Organization ‒ a Community of
Practice is the basis for success
of the Scrum Master
During the Sprint, the Scrum
Master performs specific duties.
These duties have allocations of
time as a framework
89

90
1 ‒ Ceremonies and Meetings Hours
Daily Scrum (15 Minute time boxed for 2 weeks) 2.5
Follow Up on Daily Scrum 2.5
Ceremonies 6
Preparing for Ceremonies 3
Follow Up from Ceremonies 3
Scrum of Scrums 2
Sprint Review (for 2 week Sprint) 2
21

91
2 ‒ Team Activities Hours
1 on 1 Coaching 4
Removing Impediments 8
Collecting and Updating Metrics 1
Organizing Team Celebrations 1
Team Celebrations 2
16

92
3 ‒ Learning Hours
Reading Books, Blogs, Papers, Articles 6
Preparing Hot Topics 6
Teaching Hot Topics 3
Coaching on Technical Practices 4
Gemba Walks to Other Teams 2
21

93
4 ‒ Product Owner Hours
Review Product Backlog 1
Coaching Product Owners on Product backlog 1
Product backlog Grooming Sessions 2
Prepare Release Planning 2
Release Planning 2
Facilitate Meetings with Product Owner 1
9

94
5 ‒ Organization Hours
Contribute to Program Community of Practice 8
Organize Sharing and Exchange Events for Program 2
Share and Exchange Knowledge and Experience on Program 2
Coach Program Management 5
17
Total Hours on Two Week Sprint for Scrum Master 84
The Scrum Master’s job is to work with the Development Team
to increase the Transparency of all artifacts produced by these
activities.

Artifacts From the Performance of
Scrum Activities (1)
95
Ceremonies and Meetings Artifacts
Daily Scrum
§ Ensures development team has
the meeting
§ Enforces the rule that only
Development Team members
participate in the meeting
Follow Up on Daily Scrum § Actions from inspect and adapt
Ceremonies
§ Localized ceremonies beyond
standard Scrum activities
Preparing for Ceremonies
Follow Up from Ceremonies
Scrum of Scrums § Interactions between projects
Sprint Review
§ Assures meeting take place.
§ Collaborate about what was
done during the Sprint
§ Revised Product Backlog

96
Team Activities Artifacts
1 on 1 Coaching
§ Planned interactions during the
Sprint
§ Planned interactions during
external activities
Removing Impediments
§ Keep log of all impediments
§ Keep log of all removal
activities
Collecting and Updating Metrics
§ Define metrics for process
performance
Organizing Team Celebrations
§ Define celebrations for Scrum
processes
Team Celebrations § Host the teams

97
Learning Artifacts
Reading Books, Blogs, Papers,
Articles
§ Maintain library of reading
materials for Teams
Preparing Hot Topics
§ Have a weekly hot topic for
Teams
Teaching Hot Topics
§ Prepared materials and teach
content to Teams
Coaching on Technical Practices
§ Identify gaps and teach
processes needed to close them
Gemba Walks to Other Teams
§ Conduct personal observations
of work where the work is
happening

98
Product Owner Artifacts
Review Product Backlog
§ Refine Product Backlog
§ Monitor progress toward Goal
Coaching Product Owners on
Product Backlog
§ Meeting notes from the
coaching activities
Product Backlog Grooming
Sessions
§ Assure Product Backlog
sessions performed
Prepare Release Planning
§ Release plan derived from
Engineering Estimate for
Features and estimates
Release Planning
§ Features sequenced in the
Release Plan and recorded in
the Product Roadmap
Facilitate Meetings with Product
Owner
§ Confirm Release Plan and
Product Roadmap with Product
Owner

99
Organization Artifacts
Contribute to Program Community
of Practice
§ Provide content as member of
Community of Practice
Organize Sharing and Exchange
Events for Program
§ A shared storage are for
materials
Share and Exchange Knowledge
and Experience on Program
§ A WIKI of so sort for all the
shared materials
§ Use WIKI to communicate
materials
Coach Program Management
§ Provide supporting materials
for management on Scrum
processes and application to
specific project

NEVER Rotate the Role of the
Scrum Master ‒ Mike Cohn
§ Stakeholders don't really understand the duties of the Scrum
Master, and they can start believing that anybody can do it.
§ Someone who has rotated into the role usually has other non-
Scrum Master tasks to perform during the sprint, and these
often take priority.
§ It's hard to train enough people to do the role well,
since particular skills are needed.
§ Some people will use their time as Scrum Master to try to push
through changes to the process.
§ Designating someone as Scrum Master for a sprint or two
does not automatically make someone value the job, which
can lead to Scrum Masters who think Scrum is a mistake.
100
Never have the same person be the Scrum Master and Product
Owner

Scrum Master
Training and
Deployment Plan
§ Training Plan
§ Training Materials
§ Training deployment
§ Surveillance effectiveness of
training
§ Community of practice
facilitation
Training is needed, but
surveillance of trained Scrum
Masters is also needed. As as
facilitation of the Community of
Practice
101

Master Plan to Deploy Scrum
Masters Across the Program
1. Identify candidate Scrum Masters in existing
staff
2. Build training plan for these candidates, using
external processes
3. Build deployment plan for each Portfolio and
projects in the Portfolio
4. Define artifacts needed for Scrum Masters to
start work
5. Define evidence Scrum is being applied with the
Scrum Framework by the Scrum Masters.
102

Training Materials
§ Book assignments
§ Online courses
§ Online certifications
§ Train the Trainer
103

Training Deployment
§ Hands on oversight of processes
• Confirmation that training materials have been read
and understood
• Confirm comprehension of on line training test results
104

Training Assessment
§ Evidence based assessment
§ Artifacts reviewed and assessed weekly
§ Observational assessments
105

Effectiveness Surveillance
§ Agile metrics baseline
§ Agile metrics measurements
106

A Reminder About Teams
§ Teams always outperform working groups of individuals when the teams are properly
understood and supported.
§ Many managers don't understand teams and most don't act on what they do know.
§ To really come together as a team, a group needs a performance challenge.
§ This high-performance team must have a clear, specific purpose that is distinct from
the purpose of its larger organization.
§ Team success depends on having the right mix of skills, not the right personalities.
§ Team achievement requires discipline.
§ Forming teams requires time; driving them to high performance takes enthusiasm.
§ Make team success more likely by sharing work approaches and behaviors, and by
communicating frequently and clearly.
§ Real teams are uncommon in the upper levels of companies due to organizational
structures, demands on executive time and hierarchical assumptions.
§ Teams go through a natural life cycle, from separate individuals, to a coalition, to a
higher performance mode in which members care about one another.
107

Getting Trained
§ Take full on Scrum Master from Cohn
§ Take Cape Project Management course
§ Build our own from all the Books, Papers, and
web site material
108

The Development
Team
§ User Stories are the life blood
of the Scrum Team
Professionals who work together
to deliver potentially releasable
software at the end of each Sprint
109
A team is “a small group of people with
complementary skills who are committed to a common
purpose, performance goals, and approach for which
they are mutually accountable” – Jon Katzenbach

The User Story
§ Describes how a Person interacts with product
and uses some product functionality to
accomplish a business need
§ The User Story communicates the who, what,
and why of this interaction
§ The User Story starts with the User
• If we don’t know the Users, don’t write the User Story
• Do the research needed for writing
• If not, the User Stories will be based on some belief
rather than data and empirical data
111

The Obvious Description of User
Stories …
§ Are Not Scope
§ They capture a description of an element of a
Feature from the User's point of view
• The type of User
• What they want the system to do for them
• Why they want this capability
§ It’s the last part of this statement that is critical
§ Example Driven Development is the way to
remove ambiguity in the User Story
112
As a role, I want capability So I Can reason

A Critical Thought About User
Stories
113
Storytelling reveals meaning without
committing the error of defining it
‒ Hannah Arendt

User Stories Must Be …
§ Testable
§ Describe the deliverables, listed as Tasks in
Rally
§ Some deliverables
• Code ‒ what capabilities to the code provide
• Documents – not just documentation
• Design artifact
§ What’s being touched, so testing can be defined
for the Story
114

Tips for Writing Good User Stories
§ User Stories are the basis of conversation, never
handed to the development team
§ Stories are developed collaboratively between
the Team and the Product Owner
§ If this can’t be done, develop a Use Case
§ Start with Big, Sketchy Coarse-Grained stories
• This is usually called an Epic
§ Move to finer grained Story
• Shared Understanding
• Feasible
• Testable
• Estimable
115

Don’t Write Stories If they …
§ Describe complex user interactions and visual
design.
• Use story maps, story board (just like movies are laid
out), sketches, and mockups.
§ Specify an architectural element ‒ a component
or service.
• Use an modeling language ‒ UML
§ Quickly validate an idea with a throwaway
porotype
• User Stories may not be necessary
116

Definition of Ready (1)
§ Is a detailed user story with a narrative and
acceptance criteria.
§ Be clear if there are any story-specific
operational qualities such as performance, and
what user interface design should roughly look
like.
§ Operational Constraints needed before release
§ Pre-Work Design Complete in just enough
design to understand the scope and integation of
a Feature
117

Definition of Ready (2)
§ Business value clearly articulated
§ Details are sufficiently understood by the development
team so it can make an informed decision as to whether
it can complete the PBI.
§ Dependencies are identified and no external
dependencies would block the PBI from being completed.
§ Team is staffed appropriately to complete the PBI.
§ The PBI is estimated and small enough to comfortably be
completed in one sprint.
§ Acceptance criteria are clear and testable.
§ Performance criteria, if any, are defined and testable.
§ Scrum team understands how to demonstrate the PBI at
the sprint review.
118

User Story Checklist
1. After reading the User Story is it obvious what
the User Story is about?
2. Does each element of the User Story add
significant value and therefore avoids
duplication or partial duplication of other
elements?
3. Is it 100% free of How or a Solution?
119

Some more check list items
1. Are there less than 6 questions making up the
acceptance criteria?
2. Is the ROLE specific and does everyone on the project
know what that role does?
3. Is the User Story less than 20 words and is the
acceptance criteria less than 40 words?
4. Do the elements of the User Story clearly correspond to
a WHO, a WHAT and a WHY?
5. Is the User Story annotated to clearly show whether or
not it is small (for working on) or large (in need of further
decomposition)
6. Are all of the acceptance criteria written without any
form of design
7. Has the question why been asked enough times that we
now have the real understand of WHY
8. The WHO is not called out s User but the actual User
120

And some more check list items
§ Considered the high level design change for this story
§ Know the code area which need to be modified / created for
this story
§ Thought and considered the flow changes introduced by this
story
§ Looked at the existing test automation for the current
flow/behavior (as is)
§ Thought and described how I will validate the flow/behavior
changes introduced by this story (to be)
§ Understood all the current acceptance criteria (ACs) for this
Story
§ Happy with the current ACs for this Story
§ Thought about it, and I believe this story should not be split
into smaller pieces
§ Thought about it, and I believe this story should not be merged
with another one
121

Restating the Obvious Again
What is a User Story?
A User Story for a Source Code Control System
§ User Story
• As a developer, I’d like to examine the differences between
my development tree and the main repository in order to
evaluate what integration issues I need to consider.
§ Acceptance Criteria
• The user interface displays a report of the format below (see
picture) that shows the differences between my tree and the
main tree.
§ Exceptional Criteria
• If the main repository is unavailable, the developer should
see a message that says, “The repository server is
unavailable. Please correct the problem and try again.”
122

Right Sizing User Stories Using
Estimating Versus Velocity
123
In order to “right size” we need to accurately assess our
planning horizon – we need to know how large a story is
and to know how much our team can get done in a period
of time.
The most important thing I did in my career was to teach
young leaders that whenever they saw a threat, their
first job was to determine the time box for their
response. Their second job was to hold off making a
decision until the end of the
time box, so that they could make it based on
the best possible data. ‒ Lean Software Development
The former is Estimating
The latter is Capacity for Work

The Problem with Consensus of
Estimates
§ The current consensus apprpach to estimating has
created problems
• No everyone on board
• Without 100% on board when things go wrong, blame is the
result
• I told you that was not the right estimate
§ A polling technique
• Consensus means I can live with that
• Each team member writes down what they think the Story
will take
• Estimates are revealed
• High and Low are defended, with new information
• Story adjusted, and re-vote and repeat until consensus
reached
124

The Problem with Consensus of
Estimates
§ Consensus is Not Concurrence
§ Consensus ‒ general agreement. Judgment
arrived at by most of those concerned
§ Concurrence ‒ agreement in union of plan
125
Concurrence ‒ we All can
live with the decision
Concurrence ‒ The majority can
live with the decision

Good, Bad, and Ugly User Stories
§ Gold Plated
§ Too Small
§ Too Big
§ Interdependent
§ Including UI too soon
§ Planned too far ahead
§ Sounds like a task
§ Customer can’t prioritize
§ Too much detail
126

Unnecessary Interdependence
130

Customer Can’t Prioritize
134

Estimating
The primary purpose of software
estimation is not to predict a
project’s outcome; it is to
determine whether a project’s
targets are realistic enough to
allow the project to be controlled
to meet them ‒ Steve McConnell
136

The Hard Truth of Estimating
137

Communities of
Practice
§ Just like communities of
developers with interchangeable
skills, Scrum Masters
communities across multiple
projects
§ Mutual support, knowledge
exchange, capacity backup,
collective improvement of the
Scrum processes
Communities of practice can span
more than one project.
Scrum Masters will form their own
Community of Practice for all the
activities performed during the
performance of the Scrum Master
role
138

139
https://www.scrumalliance.org/community/articles/2014/april/a-scrummasters-cop-start-up
A: Actively
G: Gain
I: Improvements by
L: Learning
E: Everyday

Scrum Community of Practice
§ Forms organically ‒ peer group with internally
generated agenda
§ Self-organizing ‒ leadership emerges according
to the changing need
§ Span more than one project ‒ span the program
140

Facilitation†
1. Design for evolution.
2. Open a dialogue between inside and outside
perspectives.
3. Invite different levels of participation.
4. Develop both public and private community
spaces.
5. Focus on value.
6. Combine familiarity and excitement.
7. Create a rhythm for the community.
141
† Cultivating Communities of Practice: A Guide to Managing Knowledge, Harvard Business School Press, 2002.

Design for Evolution
§ Communities are organic
§ Designing the community requires shepherding
than managing the evolution
§ People usually already part of an existing
community
§ Community design is like life long learning,
where reflections and redesign occurs
throughout the life cycle of the community
§ The first goal is to draw in potential members
142

Open Dialogue
§ An insiders perspective is needed to lead the
discovery process
§ Outputs of the community built on the collective
experience of the members.
• Only an insider can appreciate the issues, the
knowledge to be shared, and the challenges at the
heart of the domain ‒ Scrum Masters
§ An outsiders perspective is needed to help
members see the potential of the community
143

Different Levels of Participation
§ Alive communities ‒ planned or spontaneous ‒
have a coordinator
§ Three levels of participation
• Small core group of active participants
• Active group who attend but without the intensity of the
core group
• Peripheral members
§ It’s the first group we want the Scrum team to be
§ Supporting each other, holding each other
mutually accountable for improving the
processes of the team
144

Public and Private Community
Spaces
§ Like a Good Neighbor you’re Community
Members are There (with apologies to State
Farm Insurance)
§ Face to Face or electronic interaction between
Team members many times a day
• A web of interactions across team members
145

Focus on Value
§ The COP members define the value they seek
from the COP
§ Leadership is accountable for serving the
membership ‒ and can emerge, change, evolve
as membership needs
146

Familiarity and Excitement
147

Rhythm of the Community
§ Vibrant communities of practice also have a
rhythm
§ Community is a web of enduring relationships
among members
§ Rhythm of the community is the strongest
indicator of its aliveness.
148

Characteristics of Successful
Communities of Practice†
149
Successful
COP
Passionate
Leader
Proper Agenda
Decision
making
authority
Supporting
Tools to Create
Transparency
Suitable
Rhythm
Cross Site
Participation
Interesting
Topic
† “Communities of practice in a large distributed agile software development organization – Case Ericsson,”
Maria Paasivaara, Casper Lassenius, Information and Software Technology, Volume 56, Issue 12, December
2014, Pages 1556–1577

Artifacts of Large
Scrum Programs
§ Governance
§ Product Artifacts
§ Release Artifacts
§ Sprint Artifacts
§ Feature Artifacts
Artifacts are one piece of
evidence Scrum is being
performed.
They are not the only evidence,
but without the artifacts the other
evidence will not be sufficient for
success of the team
150

Governance
§ Risk Assessment
§ Architecture Standards
§ Test Plan
§ Contracts And Their Management
§ Reference Architecture
151

Product Artifacts
§ Product Backlog
§ Product Architecture Implementation
§ User Acceptance Testing
§ Product Release Plan
152

Release Artifacts
§ Regression Testing
§ Released Code
§ Release Plan
§ Integration Tests
153

Sprint Artifacts
§ Sprint Backlog
§ User Story Estimates
§ Burn Down Charts
§ Status Board
154

Feature Artifacts
§ Code Development
§ Feature Enhancements
§ Defects
§ User Stories
§ Detailed Design
§ Test Criteria
§ Units Tests
155

Kanban
According to Taiichi Ohno, Kanban
is one of the means through
which JIT is achieved.
It is a pull system, because it
uses the rate of demand to
control the rate of production,
passing demand from the end
customer up through the chain of
customer-store processes.
156

Kanban Should:
§ Have ticket sizes uniform with a median of 20 hrs
• Must be standalone and not dependent on other tickets
§ Management of workflow
• Clear concise view of process and workflow
§ Use productivity measures to identify issues and
address them
• Know team capacity, arrival rate of tickets, throughput, %
complete of backlog, and defect rate after completion
§ Have accurate hours estimates on tickets
§ Work on a single ticket until complete
§ All changes to the Kanban board require PM
approval
157

Kanban Should Not:
§ Have largely varying sizes of tickets
§ Have tickets started but never completed
• Reduced tix size should allow this
§ Have tickets over 200 hours
• Should be managed through Scrum Agile
§ Require breakdown of tickets in uniform size to
move across the Kanban board (est. parent child
relationship to tix in Trac)
• Should be independent and identically distributed (IID)
§ Create situation with multi tasking and high WIP
158

Issues?
§ Blocking
§ WIP too high?
§ Cross Discipline interactions?
§ Low fidelity specifications?
§ Defect backlogs?
§ Customer engagement?
159

Checklist Process Flow
162
Story
Time
Tasking Planning Execution
Check
List
Check
List
Check
List
Check
List
§ Our stories or too big
§ What’s the Check List to break down the stories?
§ What’s the entry criteria? Readiness to breakdown
§ What’s the exit criteria? We know it’s the right size

Developing the Checklist
§ What’s the problem?
§ What’s does Done look like?
§ What are the steps to reaching Done?
§ What are the impediments along the way?
§ What do we need on the check to avoid these
impediments?
§ Who owns the check list
163

164
We must Remember Development of Strong
Scrum Teams Takes Time and Effort
Taking the road to Rushville, is
a one-way street to a Dead End

Resources
Knowledge is of two kinds.
We know a subject ourselves, or
we know where we can find
information upon it.
– Samuel Johnson
165
Samuel Johnson 1709 ‒ 1784

Resources (1)
§ Practices for Scaling Lean and Agile Development, Craig Larman, Addison
Wesley
§ Agile Software Requirements, Dean Leffingwell, Addison Wesley
§ Succeed With Agile, Mike Cohn, Addison Wesley
§ The Scrum Guide, July 2016
§ Essential Scrum: A Practical Guide to the Most Popular Agile Process,
Kenneth Rubin
§ Agile Project Management with Scrum, Ken Schwaber
§ The Scrum Field Guide: Practical Advice for Your First Year, Mitch Lacey
§ Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips, Ilan
Goldstein
§ Scrum Mastery: From Good to Great Servant-Leadership, Geoff Watts
§ Agile project management : Agile Product Owner Secrets Valuable Proven
Results for Agile Management Revealed, Michael Nir, Sapir Consulting; 3rd
Edition (January 6, 2014
166

Resources (2)
§ Facilitator’s Guide to Participatory Decision-Making, Sam Kaner
§ Agile Retrospectives: Making Good Teams Great, Derby and Larsen
§ Coaching Agile Teams, Lyssa Adkins
§ The Wisdom of Teams Creating the High-Performance Organization,
Jon R. Katzenbach and Douglas K. Smith, Harvard Business School
Press
§ Scrum Liner training,
https://www.objectbay.com/eu/en/article/scrumliner_simulation_game
§ Communities of Practice http://hbswk.hbs.edu/archive/2855.html
§ Scrum Masters Checklist http://blogs.collab.net/agile/a-
scrummasters-checklist
§ “Communities of practice in a large distributed agile software
development organization – Case Ericsson,” Maria Paasivaara,
Casper Lassenius, Information and Software Technology, Volume 56,
Issue 12, December 2014, Pages 1556–1577
§ Agile Product Owner Secrets, Michael Nir, 2014
167

Resources (3)
§ Sprint Planning worksheet,
https://platinumedge.com/sites/default/files/public/Sprint-Planning-Checklist-
Platinum-Edge.pdf
168

References
[1] “42 Tasks for a Scrum Master’s Job,” Bernd Schiffer, Agile Trail, 2011
[2] “Planning the Scrum Master Role,” Francesco Attanasio, Scrum Alliance,
2013.
[3] “What Are Communities Of Practice? A Critical Review Of Four Seminal
Works,” Andrew Cox,
http://www2.warwick.ac.uk/fac/soc/wbs/conf/olkc/archive/oklc5/papers/e-
4_cox.pdf
[4] Product Owner Anti‒Patterns, Monica Yap, Scrum Gathering Shanghai, 19-
20 April 2011
[5] Product Owner Anti-Patterns, Mike Leber, Medium, 3 August 2016
169

A Workshop for Product Owners, Scrum Masters, and Team Members for Improving Team Performance

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a A Workshop for Product Owners, Scrum Masters, and Team Members for Improving Team Performance

Similar a A Workshop for Product Owners, Scrum Masters, and Team Members for Improving Team Performance (20)

Más de Glen Alleman

Más de Glen Alleman (20)

Último

Último (20)

A Workshop for Product Owners, Scrum Masters, and Team Members for Improving Team Performance