CSM Work Book Madhavi Ledalla 2022-23

CERTIFIED SCRUMMASTER
WORKBOOK (CSM®)
MADHAVI LEDALLA
https://lmadhavi.wordpress.com/
Certified Scrum Master (CSM®) Copyright @ 2022 Madhavi Ledalla
AGILE MANIFESTO .................................................................................................................... 3

AGILE UMBRELLA ...................................................................................................................... 5
PROCESS CONTROL THEORY ........................................................................................................... 6
PILLARS OF EMPIRICAL PROCESS .................................................................................................... 8
AGILE AND EMPIRICISM ................................................................................................................. 8
SCRUM- ITERATIVE & INCREMENTAL .............................................................................................. 9
SCRUM ORIGINS .......................................................................................................................... 12
SCRUM FRAMEWORK ................................................................................................................... 13
SCRUM VALUES ........................................................................................................................... 15
SCRUM ROLES ............................................................................................................................. 16
PRODUCT OWNER ....................................................................................................................... 17
DEVELOPERS .............................................................................................................................. 20
SCRUM MASTER .......................................................................................................................... 22
ROLE MAPPING ACTIVITY ............................................................................................................ 24
FACILITATION ............................................................................................................................. 25
COACHING .................................................................................................................................. 27
TRUE LEADER ............................................................................................................................. 30
IMPEDIMENT RESOLUTION ........................................................................................................... 32
VALUE OF DEVELOPMENT PRACTICES ........................................................................................... 34
SCRUM EVENTS ........................................................................................................................... 36
SPRINT ....................................................................................................................................... 36
SCRUM ARTIFACTS ...................................................................................................................... 38
PRODUCT BACKLOG ..................................................................................................................... 39
PRODUCT GOAL........................................................................................................................... 40
PRODUCT BACKLOG REFINEMENT ................................................................................................. 42
SPRINT PLANNING ....................................................................................................................... 44
SPRINT BACKLOG ........................................................................................................................ 46
SPRINT GOAL .............................................................................................................................. 48
SPRINT EXECUTION ..................................................................................................................... 49
DAILY SCRUM ............................................................................................................................. 50
SPRINT BURNDOWN .................................................................................................................... 53
DEFINITION OF DONE .................................................................................................................. 54
THE INCREMENT ......................................................................................................................... 55
SPRINT REVIEW .......................................................................................................................... 57
SPRINT RETROSPECTIVE .............................................................................................................. 59
REFERENCES............................................................................................................................... 62
BOOK REFERENCES ..................................................................................................................... 62
AGILE MANIFESTO
In 2001 February, seventeen software professionals gathered at Snowbird ski resort in Utah,
and found that they had a lot in common and agreed on many important aspects of
software development. They captured the commonality in their thoughts and named this
new methodology as “Agile”.
The name “Agile” was actually coined by Martin Fowler. These thought leaders, coming
from different programming methodologies, didn’t agree about much, but they found
consensus around four main values, which together formed the Agile Manifesto. In the late
2001 the team formed the “Agile Alliance” as a non-profit organization to act as a center for
promoting Agile methods where the manifesto guides the process decisions1
Source: http://www.agilemanifesto.org
1
For detailed history of Agile Manifesto, please refer: http://Agile manifesto.org/history.html
and http://martinfowler.com/articles/Agile Story.html
4
Agile Principles
The authors of the Agile Manifesto continued their collaborations following this meeting,
and soon thereafter added additional context and detail through a set of twelve Agile
Principles2.
Map the Agile values to the principles below-
AGILE VALUES AGILE PRINCIPLES

Individuals and interactions Our highest priority is to satisfy the customer through early and continuous
over processes and tools delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes

harness change for the customer's competitive advantage
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
Working software over Business people and developers must work together daily throughout the
comprehensive project.
documentation Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done
The most efficient and effective method of conveying information to and
within the Development team is face-to-face conversation
Working software is the primary measure of progress
Agile processes promote sustainable development. The sponsors, developers,
Customer collaboration over and users should be able to maintain a constant pace indefinitely.
contract negotiation
Continuous attention to technical excellence and good design enhances
agility
Simplicity—the art of maximizing the amount of work not done—is essential
The best architectures, requirements, and designs emerge from self-
organizing teams
At regular intervals, the team reflects on how to become more effective, then
Responding to change over tunes and adjusts its behavior accordingly.
following a plan
Notes:
2
A public declaration of the Agile Manifesto : http://Agile manifesto.org/
AGILE UMBRELLA
PROCESS CONTROL THEORY
Quick-think time: What is the difference between making a coffee and getting coffee
from a vending machine?
Making a coffee Getting coffee from a vending machine
7
Empirical Process
Empirical process is based on experimentation. We start with what is known and then build
incrementally. We rely on frequent feedback loops that are necessary for the evolution of a
product. Steps in the process are adjusted based on the learnings from experimentation.
Defined Process
The defined process requires that every piece of work be completely understood. Given a
well-defined set of inputs, the same outputs are generated every time. A defined process
can be started and allowed to run until completion, with the same results every time.
PILLARS OF EMPIRICAL PROCESS
Transparency- The emergent process and work must be visible to those performing the
work as well as those receiving the work. With Scrum, important decisions are based on the
perceived state of its three formal artifacts. Transparency enables inspection.
Inspection- The Scrum artifacts and the progress toward agreed goals must be inspected
frequently and diligently to detect potentially undesirable variances or problems. To help
with inspection, Scrum provides cadence in the form of its five events. Inspection enables
adaptation.
Adaptation- If any aspects of a process deviate outside acceptable limits or if the resulting
product is unacceptable, the process being applied or the materials being produced must be
adjusted. The adjustment must be made as soon as possible to minimize further deviation. \
AGILE AND EMPIRICISM

Agile works with empirical approach while waterfall Principle no. # 2
relies on traditional approach
Assumptions: Welcome changing
q The customer knows what he wants requirements, even
q The developers know how to build it late in development.
q Nothing will change along the way Agile processes
Reality: harness change for
q The customer discovers what he wants the customer's
q The developers discover how to build it competitive
q Things change along the way advantage.
Empiricism is one of the inherent attribute of Agile, and Scrum specifically relies on frequent
inspect and adapt cycles, and uses effective tools such as shorter iterations and
retrospectives which help us take an empirical approach.
SCRUM- ITERATIVE & INCREMENTAL

In Agile, products are created piece by piece i.e. in increments. The built pieces and the total
product are frequently revisited in an iterative manner to assure overall integrity.
In a complex environment, the need for an Iterative-Incremental model is augmented by

finding that the requirements and implementation, no matter how much time, energy and
funding are spent on predicting are prone to change. Markets and competitors evolve, users
only know when they get to see it. Thus, such environments call for an extreme awareness
and openness for change.
Agile approach slices time into time-boxed iterations, periods having a fixed start and end
date. The iterative and incremental approach comes with many advantages for example,
- focusing on important ones,
- absorption of pivots or disruptive changes, and
- to ensure regular checks so that lessons learned can be incorporated from each
iteration to another.
The core objective of each iteration is to create versions of valuable, working versions of
product no later than the end of it to gather feedback and enable learning.
Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge
comes from experience and making decisions based on what is observed. Lean thinking
reduces waste and focuses on the essentials. The short time-boxes and the events in Scrum
help inspect and adapt, and build the product incrementally and iteratively. This is a
manifestation of Edward Deming continuous improvement model.
10
The Deming Cycle proposed by W. Edwards Deming is a continuous improvement model
made up of 4-steps [Plan-Do-Act-Check] which you repeat over and over, bringing
incremental improvement each time, and thus large improvements over time.
WHERE CAN SCRUM BE USED?
Source: Modeled from Stacey, Ralph D. (1999). Strategic Management & Organizational Dynamics: The Challenge of
Complexity. Third Edition. New York: Financial Times Prentice Hall.
The Stacey Matrix is commonly used to explain where agile is most appropriate, it maps the
domain of projects according to their requirements and technology.
If a project has all requirements defined and the technology is also very well clear and
understood, (Simple Project), traditional methodologies will usually suffice.
For complicated and complex projects, predicting the outcome almost always turns out to
be incorrect. Since predictability is low, an Agile (adaptable) approach is usually preferred.
Agile works extremely well in the projects that are complicated and complex.
Scrum is suitable to deal with Complex problems where there is lot of ambiguity and would
need inspect, adapt cycles to shape the product. Scrum can be used in Simple, Complicated
problems as well. However, Scrum may not be effective while dealing with anarchy systems.
None of the well-known methodologies will work when requirements are unknown and
people are struggling with technologies and processes (a state of anarchy. It is best to stop
everything and take a deep look at what the Team is trying to achieve.
Even though Traditional approaches will work in the simple areas, as long as people and
process are involved Scrum will work great.
11
Quick-think time: Which problem space (Simple, Complex, Complicated,

Anarchy) do the given scenarios fall into?
1. Manufacturing -
2. Cleaning the coffee machine–
3. Production Server crash –
4. Accidents –
5. Support and maintenance work –
6. Bringing up children –
7. Building a road-
Notes:
12
SCRUM ORIGINS
When Jeff Sutherland created the Scrum process in 1993, he borrowed the term "Scrum”
from an analogy put forth in 1986 study by Takeuchi and Nonaka that is published in the
Harvard Business Review. In that study, Takeuchi and Nonaka compared high-performing,
cross-functional teams to the Scrum formation used by Rugby teams.
In the findings from their study, they drew comparisons between two approaches to
Product development.
The old, less effective way they refer to is a “Relay Race” approach, where each team
member was a specialist and the work progressed sequentially.
The athletes in a Relay Race take turns to pass on the baton to the next player in a sequence
to win the game. Takeuchi and Nonaka suggest a more effective “Rugby-Style” approach, in
which a cross-functional team with self-managed roles work together to create a Product.
Rugby requires the team as a whole to work together to win the game.
13
SCRUM FRAMEWORK
Scrum is a framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value.
Scrum is a lightweight framework that helps people, teams and organizations generate
value through adaptive solutions for complex problems.
q 5 Values ____________________________________
q 3 Roles ____________________________________
q 5 Events ____________________________________
q 3 Artifacts ____________________________________
q 1 Activity ___________________________________
In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a
Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat
Scrum is not a process, technique, or definitive method. Scrum is simple. Scrum is not a
methodology. Methodologies are generally prescriptive and have very strictly defined et of
14
processes. Frameworks are lightweight with minimal prescription and guidance that leave
room for other practices and tools to be included but provide the bare minimal processes
required. Scrum is a framework based on agile values and principles, through which small
cross-functional teams frequently deliver valuable potential releasable product increments.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts,
and rules. Each component within the framework serves a specific purpose and is essential
to Scrum’s success and usage. The rules of Scrum bind together the roles, events, and
artifacts, governing the relationships and interaction between them.
Various processes, techniques and methods can be employed within the framework. Scrum
wraps around existing practices or renders them unnecessary.
Any lapse in dedication and discipline in using Scrum will seize the opportunity from the
team to inspect and adapt, reduce transparency and ultimately team may not be able to
meet the Sprint Goal, it may lead to risk of incurring technical debt and reducing quality
goals.
15
SCRUM VALUES
Describe how the Scrum Roles support each of the five Scrum Values?
ROLES
FOCUS
OPENNESS
COURAGE
COMMITMENT
RESPECT
16
SCRUM ROLES
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Scrum
Teams are self-managing and cross-functional. It is a cohesive unit of professionals focused
on one objective at a time, the Product Goal. Scrum Teams are cross-functional, meaning
the members have all the skills necessary to create value each Sprint. They are also self-
managing, meaning they internally decide who does what, when, and how.
Team Size
The Scrum Team is small enough to remain nimble and large enough to complete significant
work within a Sprint, typically 10 or fewer people. In general, we have found that smaller
teams communicate better and are more productive. If Scrum Teams become too large,
they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the
same product.
q Product Owner: Is responsible for maximizing the value of the product resulting
from the work done by the Developers.
q Scrum Master: Is responsible for promoting and supporting Scrum as defined in the
Scrum guide.
q Developers: Are committed to creating any aspect of a usable Increment each

Sprint.
17
PRODUCT OWNER
The Product Owner is responsible for maximizing the value of the product resulting from
work of the Developers. The Product Owner is the sole person responsible for managing the
Product Backlog.
The Product Owner has to balance the time between the customers to understand the
priority requirements and the teams to enable them understand the requirements for
implementation.
The Product Owner understands the business needs and translates them to a prioritized list
called as the Product Backlog, and orders them to optimize the value delivered.
Product Owner is a single person and design by committee is problematic at best.

18
It is the prerogative of the product owner

• to cancel sprints,
• make any changes to ensure that the Developers are working only on the most
valuable user stories at any given time,
• to adjust the order of the stories in the current sprint if it appears that a critical slice
of functionality is in danger of not being completed soon enough,
• deciding the release timelines, and
• to accept and reject the work done
Responsibilities/Accountabilities -
- Accountable for maximizing the value of the product

- Owns the Product Backlog – the “WHAT” and “WHY”
- Optimizes the value of the work done by Developers
- Own the Product Backlog
- Manages the Product Backlog
o Developing and explicitly communicating the Product Goal
o Creating and clearly communicating Product Backlog items
o Ordering Product Backlog items and
o Ensuring that the Product Backlog is transparent, visible and understood
- Works with Developers and guides them throughout the sprint for any clarifications on
the requirements
- Manages stakeholder’s expectations, and their priorities
- Has authority to cancel the sprint
19
- Participates in Sprint events
- Makes decisions with respect to release plans, scope and time lines
- Tracks the progress of the release
- Participates in the Sprint Retrospective and provides feedback to the Developers on
thoughts of how the sprint went, understands and listens to the challenges the
Developers are going through, and together strengthen the relationship to improve the
collaboration within the Scrum Team
Discuss at least two reasons why the Product Owner is a single person and not a group or a
committee?
1._____________________________________________________
2._____________________________________________________
Notes:
________________________________________________________________
20
DEVELOPERS
The Developers consists of professionals who do the work of delivering a potentially
releasable Increment of “Done” product at the end of each Sprint.
Developers have the following characteristics:

- They are self-managing. They are empowered to manage, organize their own work
and decide how to turn Product Backlog into Increments of potentially usable
functionality
- Developers are cross-functional, with all the skills as a team necessary to create a
product Increment
- Scrum recognizes no titles for Developers, regardless of the work being performed
by the person
- The specific skills needed by the Developers are often broad and will vary with the
domain of work
Developers are always accountable for:

- Creating a plan for the Sprint, the Sprint Backlog;
- Instilling quality by adhering to a Definition of Done;
- Adapting their plan each day toward the Sprint Goal; and,
- Holding each other accountable as professionals.
Cross-functional team- The Developers are cross-functional with all the skills required to
build the product increment without depending on others. They do all the work necessary
to guarantee that the increment of product is in a usable state no later than by the end of
the sprint and is in a releasable state. Cross-functionality encourages teams to overcome
silos of traditional disciplines, learn more and be more robust to handle unexpected
changes.
It is the team’s prerogative to define their own commitments, individual task assignment,
produce quality work, provide their own estimates, sign up for work rather than be assigned
work.
21
The Product owner is the appropriate role to offer work to the Developers because this
person is a business-facing person is empowered to fill the role and understand the market,
product, business priorities and any constraints involved.
Accountabilities/ Responsibilities -
o Collaborate with the product owner to understand the functionality
o Determine how to build the increment
o Deliver a potentially releasable and a usable increment
o Work with the Product Owner in refining the Product Backlog
o Own the Sprint Backlog and keep it transparent
o Plan, execute and deliver the work of the Sprint
o Be transparent about the state of the work
o Track and manage progress during the sprint
o Apply good technical practices
o Relentless improvement through inspect and adapt cycles
o Identify and eliminate technical debt
Discuss the challenges for teams to self-manage and what can be done to overcome the
challenge?
Challenge Strategy to overcome the challenge

22
SCRUM MASTER
The Scrum Master is accountable for ensuring Scrum is understood and enacted. Scrum
Master does this by ensuring that the Scrum Team adheres to Scrum theory, practices, and
rules. Scrum Masters are true leaders who serve the Scrum Team and the larger
organization. They have no direct authority, lead through influence.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by
enabling the Scrum Team to improve its practices, within the Scrum framework.
The Scrum Master helps those outside the Scrum Team understand which of their
interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps
every one change these interactions to maximize the value created by the Scrum Team.
23
The Scrum Master is omnipresent throughout the Scrum, works with all involved, the
Product Owner, the Developers and the Organization closely to ensure that Scrum is
understood well and implemented.
It is the Scrum Master’s prerogative to experiment with new ideas, have access to
stakeholders and decision makers, address issues openly.
The Scrum Master is a constantly evolving role, which metamorphoses from a coach,
facilitator, and servant leader to a change enabler/influential cheerleader and an evangelist.
The Scrum Master continually switches these hats, and many others, based on the need of
the hour.
Accountabilities/Responsibilities -
o Oversees the Scrum process, Process coach and has process authority
o Coaching the team members in self-management and cross-functionality
o Faciliates Scrum implementation
o Protects, shields and safeguards team from external and internal impediments
o Helping the Scrum Team focus on creating high-value Increments that meet the
Definition of Done
o Motivates and encourages the team to own success and failures equally
o Influencer who influences the Organization,Stakeholders and team members to
steer them in the right direction.
o Come up with creative and innovative ideas to engage the team in fruitful
conversations to make the teams think out of box and express their thoughts
o Help teams reflect on themselves by asking powerful questions, acts like a mirror for
the teams to drive them through the self-realization process
o Fosters an environment where team efforts are rightfully rewarded, thereby
ensuring the team stays focused and motivated throughout
o Facilitates all Scrum events to ensure they are positive, productive, and kept within
the timebox
o Encourage team in adopting engineering practices
24
o Coach Product owner on Scrum Process, and on techniques that include but not
limited to engaging the team in the shared purpose of their work, providing
transparency of priorities, ensuring a shared understanding of Product Backlog
items.
o Scrum Master is a true leader who coaches the Scrum teams and the larger
organizations in Scrum implementations and organizational design changes.
ROLE MAPPING ACTIVITY

Each team has a stack of cards that list the responsibilities of a Scrum Team. Based on the
understanding of the Scrum Framework, map out and assign these responsibilities to one of
the roles in Scrum i.e Scrum Master, Developers and the Product Owner.
There could be some cards that do not fall in any of the three Scrum roles.
What happens to the Project Manager role in Scrum? Who does the Project
management activities?
-What happens to specialists like UX, Architects, Front End, Back End developers?
What happens if Scrum roles are shared, what are the implications?
25
FACILITATION
Overview
A facilitator enables groups and organizations to work more effectively and helps guide
events to a successful outcome through constructive and sustainable decisions.
Facilitation is an art that can be acquired through practice and it is a journey.

A facilitator is not a person who lectures. A facilitator is a person who has a neutral mind set
and can listen to the different perspectives of the people without any bias and help them
achieve their goals.
“Someone who helps a group of people understands their common objectives and assists
them to plan how to achieve these objectives; in doing so, the facilitator remains ‘neutral,’
meaning he/she doesn’t take a particular position in the discussion 3.”
Facilitator facilitates/conducts the process of holding the event/meeting/discussion without

getting involved in the content! It is about holding that impartial stance.
Myth: As a facilitator, the Scrum Events is the only thing a Scrum Master can facilitate!
“A Scrum Master should facilitate by creating a ‘container’ for the team to fill up with their
ideas and innovations. The container, often a set of agenda questions or some other
lightweight (and flexible) structure, gives the team just enough of a frame to stay on their
purpose and promotes an environment for richer interaction, a place where fantastic ideas
can be heard. The coach creates the container; the team creates the content.”- Lyssa Adkins
As a facilitator, the Scrum Master facilities
• The relationships and collaboration both within the team and the teams
environment
• The Scrum process and the continuous improvement of the process
• The integration of the Scrum Team into the entire organization
• The Scrum events to be purposeful and effective
3
http://en.wikipedia.org/wiki/Facilitator
26
Core practices of facilitation

1. Have a non-judgmental mind-set
2. Focus on the agenda.
3. Time boxing the discussions.
4. Paraphrasing continuously.
5. Engaging the participants through group activities to help them collaborate and
continuously improve.
6. Visualizing the discussions using visual radiators like flip charts.
7. Assist the group in brainstorming ideas.
8. Balance the group dynamics and ensure that everyone speaks and voices their
opinion.
9. Create fun to boost the energy level of the participants
10. Can use collaboration frameworks wherever possible to make the discussions
effective and interactive.
What are some common techniques that can be used for facilitating group
events?
1. ________________________________________________
2. ________________________________________________
3._________________________________________________
Notes:
27
COACHING
“Coaching is a form of development in which a person called a coach supports a learner or
client in achieving a specific personal or professional goal, by providing training, advice, and
guidance.” - Wikipedia
A coach helps people make the best use of their own resources.
When you decide to call yourself a “coach,” you become a partner in building people’s
capabilities.
Whether you’re coaching one person or working with a team, within an organization or on
your own, your role as a coach is to help them achieve things themselves.
Sir John Whitmore, author of Coaching for Performance defines coaching as:
“Unlocking a person’s potential to maximize their own performance.”
COACHES LEAD PEPOLE TO DISCOVER THEIR OWN INSIGHTS- This is the most important
aspect of coaching. It’s the key to the coach mindset, often known as the “coaching stance.”
• Mentoring- It is about transferring your agile knowledge and experience to the team
as that specific knowledge becomes relevant to what’s happening with them. The
context of agile makes you a mentor; the focus on team performance makes you a
coach.
• Teaching- According to the Scrum Guide, the Scrum Master is responsible for
ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring the
Scrum Team adheres to Scrum theory, practices and rules. The Scrum Master can
teach the team the concepts around the core of Scrum, self-managing, scrum roles
and rules of the framework depending on the need.
Coach needs to be expertise in three key areas: - asking questions, listening and
observing/sharing observations.
28
Role of an agile coach:

“I think coaches are an integral part to helping teams get to astonishing results because it’s
all in the interactions of human beings where that happens. There is no piece of it in the
Agile framework that’s going to help you with that. Having Agile framework there and
working well, it’s certainly going to provide the structure and the container within which that
can happen, the boundaries. But there are so much more to do within those boundaries, so
many more things to bring to the team, so many more ideas and things from different
disciplines - things from conflict management and facilitation and teaching and mentoring
and professional coaching and a few more.” – Lyssa Adkins, author of Coaching Agile Teams
There could be many challenges a self-managing team come across that include
• a bad forecast,
• technical debt or
• someone is leaving the team
and the Scrum Master plays a vital role in coaching teams in such situations.
A coaching session will typically take place as a conversation between the coach and the
coachee and focusses on helping the coachee discover answers for themselves.
The Scrum Master thrives on the famous quote - “Don’t catch me a fish, but teach me to
catch one”.
Scrum Master as a coach

To describe the Scrum Master as a coach three different perspectives can be used
• The individual
• The Scrum Team and
• The organization.
Tips for Scrum Master to become a good agile coach

• Positive attitude towards the team and patience.
• Believe in yourself as the change you wish to bring in begins with you.
• Practice how to be agile for yourself first (Lead by example)
• Balancing yourself when team critics or confronts (Keep up the balance)
• Give enough the time to the team to experience the change! (Realistic pace)
• Let the team experiment and let them learn from their failures and success (Open to
learn)
• Be open to receive feedback as and when it comes through. (Accept feedback)
The Scrum Master Scrum Team and organization, listed below are a few ways in which the
Scrum master does this
Scrum Team
- Coaching the team members in self-management and cross-functionality
- Helping the Scrum Team focus on creating high-value Increments that meet the
Definition of Done
- Causing the removal of impediments to the Scrum Team’s progress
29
- Ensuring that all Scrum events take place and are positive, productive, and kept
within the timebox.
Product owner
- Helping find techniques for effective Product Goal definition and Product Backlog
management
- Helping the Scrum Team understand the need for clear and concise Product Backlog
items
- Helping establish empirical product planning for a complex environment; and,
- Facilitating stakeholder collaboration as requested or needed.
Organization
- Leading, training, and coaching the organization in its Scrum adoption
- Planning and advising Scrum implementations within the organization
- Helping employees and stakeholders understand and enact an empirical approach
for complex work and,
- Removing barriers between stakeholders and Scrum Teams.
Assume that the Product Owner is adding scope in between the sprint, how
would you as a Scrum Master coach the Product Owner? What techniques would you use
and how?
______________________________________________________________
______________________________________________________________
_______________________________________________________________
Assume that the Developers are not able to meet the Sprint Goal consistently, use “Sail
boat” retrospective technique to discuss this challenge and come up with possible
options.
30
TRUE LEADER
Scrum Master is called as a True Leader/Servant Leader. Servant-Leadership is a philosophy
and a set of practices that enrich the lives of individuals, to build better organizations, and
ultimately create a more just and caring world. Servant-leadership focuses on collaboration,
building a foundation of trust, empathy, putting others need first and the usage of power
ethically.
Robert K. Greenleaf, originator of the term servant-leadership, describes servant-leader as:

-"The servant-leader is servant first. It begins with the natural feeling that one wants
to serve. Then conscious choice brings one to aspire to lead. The best test is: do those served
grow as persons: do they, while being served, become healthier, wiser, freer, more
autonomous, more likely themselves to become servants? And, what is the effect on the
least privileged in society; will they benefit, or, at least, not be further deprived?
Scrum Master - The Scrum Guide describes the Scrum Master as the servant-leader for the
Scrum Team. A Scrum Master is not master of the team, but a master at encouraging,
enabling, and energizing people to gel as a team and realize their full potential4.
A Scrum Master is a servant-leader whose focus is on the needs of the team members and
those they serve (the customer), with the goal of achieving results in line with the
organization’s values, principles, and business objectives5
The Scrum Master has no authority but leads through influence because-
- effectively leading people does not happen by enforcing authority, it ultimately leads
to many problems
- If solution is enforced then SM becomes the greatest impediment as teams stop
thinking and look upon to SM for solving everything
- The value that the team members bring to the company is diminished, since their
knowledge is not utilized
4
Watts, Geoff. Scrum Mastery: From Good to Great Servant Leadership
5
http://www.infoq.com/articles/leadership-challenge
31
All these problems lead to the emergence of a new type of leadership. A leadership that is
focused on empowering, delegating, coaching your “followers” and providing the right
environment for them to work in. Leaders that inspire, help, influence, serve the needs of
their fellow workers – the servant leaders.
Characteristics of Servant Leader

Listening Servant leaders must listen to verbal and non-verbal signals and interpret hat others are saying.
They must also listen to their inner thoughts and feelings and interpret them.
Empathy The servant-leader strives to understand and empathize with others. People need to be
accepted and recognized for their special and unique spirits. One assumes the good intentions
of coworkers and does not reject them as people
Healing Servant leaders recognize that they have an opportunity to help make whole those with whom
they come in contact.
Awareness Servant Leaders view most situations from a more integrated, holistic position. As Greenleaf
observed: "Awareness is not a giver of solace--it is just the opposite. It is a disturber and an
awakener. Able leaders are usually sharply awake and reasonably disturbed”
Persuasion Another characteristic of servant-leaders is a primary reliance on persuasion rather than
positional authority in making decisions within an organization. The servant leader seeks to
convince others rather than force compliance.
Conceptualization Servant-leaders seek to nurture their abilities to "dream great dreams." The ability to look at a
problem (or an organization) from a conceptualizing perspective means that one must think
beyond day-to-day realities.
Foresight Enables the servant-leader to understand the lessons from the past, the realities of the present,
and the likely consequence of a decision for the future.
Stewardship A commitment to serve the needs of others. Also empathizes the use of openness and
persuasion rather than control.
Commitment to Deeply committed to the growth of each and every individual within his or her organization. An
growth of people example is “taking personal interest in the ideas and suggestions from everyone, encouraging
worker involvement in decision making”
Building Community A servant leader should seek to identify some means for building community among those who
want to work within a given institution.
List down few scenarios where a Scrum Master can serve the Development Team
as a Servant/True Leader.
1.
2.
3.
32
IMPEDIMENT RESOLUTION
One of the responsibilities of the Scrum Master is to - Removing impediments to the
Developers progress.
An impediment in Scrum is a factor that blocks the Developers in its creation of a product
increment, or that resists the team in achieving its Sprint Goal. “An impediment is an event
that impedes any of the Developers members from working to their anticipated Sprint
capacity!” 6
An Impediment is anything that keeps the team from getting work done and being
productive, and that slows them down.
Examples of impediments
(Anything that is blocking the teams work is an impediment)
- a sick team member,
- a missing team member,
- lack of management support,
- attrition,
- unmanageable technical debt,
- infrastructure limitations for teams to develop and test their code,
- lack of collaborative team space.
Tips for impediment resolution:

1. Provide a platform where impediments can be made transparent and visible to
everyone in the organization.
2. Figure out if the impediment raised is really an impediment.
3. Check if the issue is stopping the team from meeting its sprint goal, if yes, the it is
truly an impediment.
4. Watch out if the impediment is a team level problem that the team can resolve by
themselves.
5. Keep track of all open and resolved impediments.
6. Educate the teams to self-manage and solve team level impediments.
7. Time-box the impediment resolution.
8. Raise impediments as soon as they occur.
9. Use courage and creativity to remove the impediments.
10. Watch out for the root cause of the impediment and fix it once for all.
6
Goldstein, Ilan. Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools & Tips
33
Discuss at least three common organizational impediments outside the scope of

a team that may affect the Scrum Team and how can they be resolved?
1.
2.
3.
Notes:
34
VALUE OF DEVELOPMENT PRACTICES

While Scrum does not prescribe specific engineering practices, Scrum Masters are
responsible for promoting increased rigor in the definition of done. Items that are called
“Done” should stay done. Automated regression testing prevents vampire stories that leap
out of the grave. Design, architecture, and infrastructure must emerge over time, subject to
continuous reconsideration and refinement, instead of being “finalized” at the beginning,
when we know nothing.
Extreme Programming Engineering Practices (XP)

Extreme Programming is a discipline of software development based on values of simplicity,
communication, feedback, courage, and respect. It works by bringing the whole team
together in the presence of simple practices as shown below, with enough feedback to
enable the team to see where they are and to tune the practices to their unique situation.
• Test-Driven Development: Think about how you will test it before you start coding.
• Refactoring: Refactor mercilessly. Refactoring is changing the structure of code
without changing its behavior.
• Simple Design: As a strategy, always do the simplest thing that could possibly work.
• Pair Programming: Two people working together will create as much functionality as
two people working separately except that people working together will produce
much higher quality.
• Coding Standards: Coding standards keep the code consistent and easy for the entire
team to read and refactor.
• Sustainable Pace: Set a sustainable, measurable and predictable pace.
• Metaphor: Explain something using a figure of speech in order to imply a
resemblance.
• Continuous Integration: Integrate components early and often to make sure
problems are visible asap.
35
• Collective Ownership: Everyone owns everything, to make sure there are no
bottlenecks.
• Whole Team: The customer should always be available.
• Planning Game: Have a plan for the next months.
• Small Releases: Release often to gather feedback fast.
• Customer Tests: The customer is actively involved in deciding what tests need to be
performed.
The Scrum Master can inspire the team to learn engineering practices associated with XP
that include Continuous Integration (continuous automated testing), Test-Driven
Development (TDD), Constant merciless refactoring, pair programming, Frequent check-ins,
etc. Informed application of these practices prevents technical debt.
While Scrum at the project management level focuses on prioritizing work and getting
feedback, XP focuses on software development good practices. Thus, Scrum and XP
complement each other. Scrum Teams practicing XP will find the XP technical practices to
be useful because XP technical practices can be used as a starting point for Scrum team
definition of "Done" to increase the quality of the software and to increase agility.
These technical practices have a positive impact on the team’s ability to deliver a potentially
releasable Increment each Sprint. For example, continuous integration helps to detect
integration errors earlier and speed up releasing, refactoring improves product quality and
thus minimizes adjustments for new features, collective code ownership reduces island
knowledge and bottlenecks due to unnecessary specialization.
Known issues that remain in the backlog in the form of unfinished work are generally
called technical debt. In simpler words, technical debt is the difference between what was
initially envisioned and what was actually delivered. Technical Debt comes from various
sources, some of which can be good and some bad as described below by martin fowler.7
A weak DOD gives an illusion of a “quick win” as the user story is marked as complete.
However, there might work in the form of automated testing, documentation, or other
elements missing that may lead to accumulation of technical debt.
7
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
36
SCRUM EVENTS
Events are used in Scrum to create regularity and to minimize the need for meetings not
defined in Scrum. All events are time-boxed events, such that every event has a maximum
duration.
Other than the Sprint itself, which is a container for all other events, each event in Scrum is
a formal opportunity to inspect and adapt something. These events are specifically designed
to enable critical transparency and inspection. Failure to include any of these events results
in reduced transparency and is a lost opportunity to inspect and adapt.
SPRINT
Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length
events of one month or less to create consistency. A new Sprint starts immediately after the
conclusion of the previous Sprint.
All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums,
Sprint Review, and Sprint Retrospective, happen within Sprints.
Sprint is container of all other events. The events in Scrum set the frequency of the
inspection and adaption where the artifacts contain the information to be inspected and
adapted as described below.
Event Inspect Adapt
Sprint Planning Product Backlog Sprint Backlog
Daily Scrum Sprint progress and Sprint Sprint Backlog and the daily
Backlog plan
Sprint Review Increment Product Backlog
Sprint Retrospective Sprint Actionable improvements
The Sprints are of fixed duration, the sprint ends when the time box expires irrespective of
the Sprint Backlog completion. The remaining events may end whenever the purpose of the
event is achieved. During Sprint, Scrum Team works together to create a potentially
releasable product increment.
The fixed scope and duration of a sprint promote successful delivery of the Sprint Goal and
supports the Scrum Team to learn how to deliver valuable increments iteratively.
Time boxing offers a couple of benefits that include forces prioritization, increases focus,
improves predictability and gives an opportunity to inspect and adapt
Sprint cancellation- A product Owner has the authority to cancel a sprint and start a new
sprint instead. An abnormal termination is most frequently the result of a dramatic shift in
business priorities-something previously considered important is no longer important, or
something even more important is discovered.
37
Other options to sprint cancellation could be if the work turns out to be different than the
Developers expected, they collaborate with the Product Owner to negotiate scope of Sprint
Backlog within the Sprint. Or if the priority changes, the work can be reprioritized within
sprint and Product Owner can accept what was done so far.
The outcome of every sprint is a potentially releasable product increment that adheres to
the Definition of Done.
During the Sprint

o No changes are made that would endanger the Sprint Goal
o The Product Backlog is refined as needed
o Scope may be clarified and re-negotiated between the Product Owner as
more is learned.
o Quality does not decrease.
Which of the following factors are used to determine the sprint length?
Factors True/False
The frequency at which the requirements change
The team size
The frequency at which the Scrum Team needs feedback from the product Owner and
customers
Team structure
Stakeholders availability give feedback and review work the Developers do
Advantage of having a consistent sprint length-

38
SCRUM ARTIFACTS
Scrum’s artifacts represent work or value to provide transparency and opportunities for
inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize
transparency of key information so that everybody has the same understanding of the
artifact.
Commitments - Each artifact contains a commitment to ensure it provides information that

enhances transparency and focus against which progress can be measured:
- For the Product Backlog it is the Product Goal.
- For the Sprint Backlog it is the Sprint Goal.
- For the Increment it is the Definition of Done.
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team
and their stakeholders.
Key Artifacts
1. Product Backlog: The Product Backlog is an ordered list of everything that
might be needed in the product and is the single source of requirements for
any changes to be made to the product.
2. Sprint Backlog: The Sprint Backlog is a plan by and for the Developers. It is a
highly visible, real-time picture of the work that the Developers plan to
accomplish during the Sprint in order to achieve the Sprint Goal.
3. Increment: An Increment is a concrete stepping stone toward the Product

Goal. Each Increment is additive to all prior Increments and thoroughly
verified, ensuring that all Increments work together.
39
PRODUCT BACKLOG
The Product Backlog is a living artifact, an ordered list of everything that needs to get done
for a Product. It is a single source of requirements for the product. The Product Owner is
responsible for the Product Backlog including its content, availability and ordering. The
Product Owner keeps it up to date to reflect the emerging requirements, market demand,
customers and stakeholder’s feedback. Anyone can add items to the Product Backlog;
however, the Product Owner prioritizes and orders the Product Backlog.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in future releases.
40
A Product Backlog is never complete. The earliest development of it lays out the initially
known and best-understood requirements. The Product Backlog evolves as the product and
the environment in which it will be used evolves. The Product Backlog is dynamic, it
constantly changes to identify what the product needs to be appropriate, competitive, and
useful. If a product exists, its Product Backlog also exists.
Each item in a Product Backlog is called as a Product Backlog item (PBI). Each PBI should be
described in just enough detail.
Each Product Backlog item has attributes of

- description,
- order,
- value and
- estimate.
Guiding Principles of a Product Backlog:

Mike Cohn’s acronym DEEP
Detailed Appropriately -
-
Estimated -
-
Emergent -
-
Prioritized -
-
PRODUCT GOAL
The Product Goal describes a future state of the product which can serve as a target for the
Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the
Product Backlog emerges to define “what” will fulfill the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-
defined users or customers. A product could be a service, a physical product, or something
more abstract.
The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or
abandon) one objective before taking on the next.
41
Which of the following can be the consequences of a Product Owner applying excessive
time pressure on the Developers (True or False)? After this exercise ask the team to discuss how to
resolve the situation?
Consequences True or False

Quality is compromised
Productivity increases
Developers morale decreases
Definition of Done may not be met
Developers can focus on Sprint Goal
Notes:
42
PRODUCT BACKLOG REFINEMENT

Product Backlog refinement is the act of breaking down, adding detail, estimates, and
ordering items in the Product Backlog. The Product Backlog refinement is an ongoing
activity during which the Product Owner and the Developers collaborate on the details of
Product Backlog items to add details, such as a description, order, and size. Attributes often
vary with the domain of work. The Scrum Team decides how and when refinement is done.
This activity might include:

43
Refinement helps the Product Owner to focus on the priority items and not create waste by
hoarding issues that might never materialize. It is a good practice to collaboratively manage
the Product Backlog and the backlog items acquire a high degree of transparency through
refinement activities. It helps the Developers more easily forecast the work of the sprint
during Sprint Planning.
If Backlog refinement is not done well, it may lead to some negative impacts that may
include
- Sprint Planning will involve a significant number of questions, discovery
and/or confusion.
- The quality of the Product Backlog takes a hit since it is not refined on a
regular basis
- Teams may end up in working on features that do not deliver any business
value since they are not prioritized
- Team and PO do not have a share understanding of WHAT to build.
The more meticulously the Product Backlog refinement is done, simpler the Sprint Planning
becomes because most of the backlog is clear, already analyzed and sized.
With stories marked ready during the refinement meeting, the Product Owner can make
sure that the team can pull these stories to their current Sprint and can begin working upon
immediately.
Notes:
44
SPRINT PLANNING
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint.
The purpose of the Sprint Planning meeting is to plan the work for the current Sprint. This
plan is created by the collaborative work of the entire Scrum Team. This is the first event
that happens in the Sprint.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For
shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes
place and that participants understand its purpose. The Scrum Master teaches the Scrum
Team to keep it within the time-box.
There could be some negative impacts that arise when the Scrum Team disregards one or
more of the elements of Sprint Planning that include-
o Scrum Team loses the opportunity to inspect the Product Backlog and adapt the
Sprint Backlog
o Scrum Team lose their ability to forecast the Sprint Goal
o Product Owner would not be able to get insights into the progress made on the
Sprint Goal
45
Sprint Planning addresses the following topics:
1. Topic One: Why is this Sprint valuable?

- The Product Owner proposes how the product could increase its value and
utility in the current Sprint.
- The whole Scrum Team then collaborates to define a Sprint Goal that
communicates why the Sprint is valuable to stakeholders.
- The Sprint Goal must be finalized prior to the end of Sprint Planning.
2. Topic Two: What can be Done this Sprint?
- Through discussion with the Product Owner, the Developers select items
from the Product Backlog to include in the current Sprint.
- Selecting how much can be completed within a Sprint may be challenging.
- However, the more the Developers know about their past performance, their
upcoming capacity, and their Definition of Done, the more confident they will
be in their Sprint forecasts.
3. Topic Three: How will the chosen work get done?
- For each selected Product Backlog item, the Developers plan the work
necessary to create an Increment that meets the Definition of Done.
- The Sprint Goal, the Product Backlog items selected for the Sprint , plus the
plan for delivering them are together referred to as the Sprint Backlog
Sample Sprint backlog

46
SPRINT BACKLOG
The Sprint Backlog represents the work the developers do in the current Sprint. It is a highly
visible, real-time picture of the work that the Developers plan to accomplish during the
Sprint in order to achieve the Sprint Goal.
Sprint Backlog is referred to as -

- The Sprint Goal (why),
- The Product Backlog items selected for the Sprint (what),
- The plan for delivering them(how)
The Sprint Backlog has just enough detail, defines the tasks the Developers will do to turn
Product Backlog items into a “Done” Increment by the end of the sprint.
The Sprint Backlog is a plan by and for the Developers , it emerges during the Sprint as the
Developers works through the plan and learns more about the work needed to achieve the
Sprint Goal.
The backlog items that are not completed at the end of the sprint are moved back into the
Product Backlog so that the Product Owner can prioritize them for the next sprint or a
future sprint.
Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a
commitment by the Developers, it provides flexibility in terms of the exact work needed to
achieve it. The Sprint Goal is created during the Sprint Planning event and then added to the
Sprint Backlog
47
Discuss who can change the Sprint Backlog, and the limits of these changes.
1. Who-
2. Limitations-
Which of the following are Myths/Facts?
1. The Sprint Goal provides direction and flexibility on how the Developers want to
implement the functionality during the sprint
2. The Sprint Backlog is highly visible and solely belongs to Developers
3. The Sprint Backlog has just enough detail so that Developers can start working on it
4. The Sprint Backlog represents the real-time snapshot of the Developers work for the
sprint
5. The Sprint Goal cannot change during the sprint
Notes:
48
SPRINT GOAL
The Sprint Goal is the single objective for the Sprint that can be met through the
implementation of Product Backlog. It provides guidance to the Developers on why it is
building the Increment. It is created during the Sprint Planning meeting.
Sprint Goals are the result of a negotiation between the Product Owner and the Developers.
Sprint Goals should be specific and measurable. Some benefits of Sprint Goal are-
o It provides guidance to the Developers on why it is building the Increment

o Gives the Developers some flexibility regarding the functionality implemented within
the Sprint.
o Helps stakeholders understand why they are being asked to participate in a Sprint
Review
Examples-
o Get feature X ready for release (hereby the Sprint Goal is delivering a feature)
o Check if the architecture enables the desired performance (hereby the Sprint Goal
is addressing a risk)
Write an example Sprint Goal

49
SPRINT EXECUTION
Sprint execution is the work the Scrum Team performs to meet the Sprint Goal. After the
Sprint Planning, the teams start working on the Sprint Backlog and do all that is needed to
deliver potentially releasable “Done” Product increments. During Sprint the Developers
self-manage and determine the best way to meet the Sprint Goal.
The Scrum Master does whatever is needed to help the team be successful. The Scrum
Master doesn’t assign work to the team or tell the team how to do the work. A self-
managing team figures these things out for itself. The members collaboratively work as a
team to achieve the Sprint Goal. They monitor the progress using the visual radiators like
burn-down charts and task board.
Notes:
50
DAILY SCRUM
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the
Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum
optimizes the probability that the Developers will meet the Sprint Goal. Every day, the
Developers understands how it intends to work together as a self-managing team to
accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
The Developers or team members often meet immediately after the Daily Scrum for
detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
Daily Scrum is time boxed so that focus is on the current day, it is not a status report
meeting.
The Daily Scrum differs from a Status Meeting in the following aspects-
- Daily Scrum promotes collaboration. When a Daily Scrum is treated as a status
meeting, the Developers provide a status update to someone else.
- Daily Scrum enables focus on achieving an outcome. In a status meeting, individuals
give updates on the tasks or items they have each worked on, and there is likely not
focus on achieving a valuable business outcome
51
- Daily Scrum promotes collaboration. In my experience with status meetings, there is
not a lot of collaboration. They tend to focus on individual contributions and
coordinating work.
The structure of the meeting is set by the Developers and can be conducted in different
ways provided they focus on progress toward the Sprint Goal. This creates focus and
improves self-management. Some Developers use questions, some will be more discussion
based.
Here is an example of what might be used:
The Developers uses the Daily Scrum to review progress toward the Sprint Goal, update the
Sprint Backlog and inspect how progress is trending toward completing the work in the
Sprint Backlog.
Daily Scrums improve communications, eliminate other meetings, identify impediments to

development for removal, highlight and promote quick decision-making, and improve the
Developers level of knowledge. This is a key inspect and adapt meeting.
There may be some negative impacts that arise when the Scrum Team disregards one or
more of the elements of the Daily Scrum that may include-
52
o It may turn out be a status update meeting.
o Team may not be able to assess their progress towards the Sprint Goal .
o Team may lose one of the opportunities to talk about the risks/impediments, inspect
and synch up every day.
1. The Daily Scrum is for the Scrum Team to inspect the progress towards the Sprint
Goal
2. It is a forum to check team member’s work allocation for the sprint
3. The Developers are responsible for conducting the Daily Scrum, the Scrum Master
needs to ensure that teams do it daily
4. The Scrum Master is responsible for solving ALL impediments
5. Purpose is to inspect and adapt daily so that teams need not again inspect and adapt
at the end of the sprint
Notes:
53
SPRINT BURNDOWN
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows.
The format of visualization can be in any form. While proven useful, these do not replace
the importance of empiricism. In complex environments, what will happen is unknown. Only
what has already happened may be used for forward-looking decision making.
The Sprint Burndown Chart is just one such example to visualize the estimated work
remaining during the sprint. It is used by the team to visualize its progress during the sprint
with regard to the Sprint Goal. It depicts the amount of work remaining or scope yet to be
completed for the current sprint. The remaining work is tracked on y-axis and the time
period on the x-axis. The sprint burndown can plot the remaining working using story
points, hours, number of tasks, ideal days etc.
Notes:
54
DEFINITION OF DONE
The Definition of Done(DOD) is a shared understanding, a common definition of what it

means to be done. The Definition of Done is a formal description of the state of the
Increment when it meets the quality measures required for the product.
The Definition of Done creates transparency by providing everyone a shared understanding

of what work was completed as part of the Increment. If a Product Backlog item does not
meet the Definition of Done, it cannot be released or even presented at the Sprint Review.
Instead, it returns to the Product Backlog for future consideration.
The Scrum Team creates the definition of done, ideal state of Done that means that the
backlog item is releasable, can be deployed in production and usable by customers. One
way to we create the DOD is to start with this ideal state and list out all the activities that
need to be completed to achieve it. We then decide how many of these activities can be
completed within the same sprint. DOD evolves, as the team gets closer and closer to being
able to produce an integrated tested Increment in every Sprint.
When forming a Definition of Done, the team must consider the "conventions, standards, or
guidelines of the development organization". Also, "If there are multiple Scrum Teams
working on the system or product release, the developer teams on all of the Scrum Teams
must mutually define the definition of 'Done'."
The retrospectives is one of the event that leads to an adapted D0D. However the team
can update it whenever they have new insights that should be on the DOD. This could also
be during Sprint planning, Daily Scrum or Sprint Review events.
Symptoms of weak definition of done-

- Technical Debt, Undone work, Rework
55
Discuss which of these are examples of a strong DOD?
Discuss and write down what happens if the Definition of Done is weak?
1.
2.
3.
Discuss atleast three reasons why multiple teams working on the same Product Backlog
must have a shared and consistent Definition of Done.
1.
2.
3.
THE INCREMENT
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is
additive to all prior Increments and thoroughly verified, ensuring that all Increments work
together. In order to provide value, the Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of the Increments is presented
at the Sprint Review thus supporting empiricism.
However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The
Sprint Review should never be considered a gate to releasing value. Work cannot be
considered part of an Increment unless it meets the Definition of Done.
56
The increment is inspected at every Sprint Review and the Product Backlog is adapted based
on the stakeholder feedback. It supports empiricism at the end of the Sprint and it indicates
progress towards the Product Goal , represents the current state of the Product Backlog and
the product.
Commitment: The Definition of Done is a formal description of the state of the Increment
when it meets the quality measures required for the product. Work cannot be considered
part of an Increment unless it meets the DOD
Discuss why the increment must be brought to the current Definition of Done
regardless of whether the Product Owner chooses to release the increment.
1.
2.
3.
Notes:
57
SPRINT REVIEW
A Sprint Review is held at the end of the Sprint to inspect the outcome of the Sprint i.e. the
Increment and adapt the Product Backlog if needed. During the Sprint Review the Scrum
Team and the stakeholders review the Product increment developed during the Sprint.
Team gains trust of the stakeholders by showing them the working Product increment. This
is an informal meeting, not a status meeting or a sales presentation.
Goal is to elicit feedback and foster collaboration. Product Owner and other stakeholders
review the work done and give feedback. The stakeholders can suggest new enhancements,
58
changes to existing functionality, and any other observations as they watch the Sprint
demo. The result of the Sprint Review is a revised Product Backlog that defines the probable
Product Backlog items for the next Sprint.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum
of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
There may be some negative impacts that arise when the Scrum Team disregards one or
more of the elements of the Sprint Review that may include-
- The team misses on the opportunity to inspect and adapt the Product Increment
- The stakeholders los the opportunity to take meaningful decisions w.r.t to the
product
- It may cause a communication gap between the team and stakeholders
1. The Sprint Review is not just about product demonstration, it is an inspection of the
completed Sprint, the Product Backlog and the marketplace.
2. The primary goal of sprint Review is to check what work has been completed during
the sprint.
3. Sprint Review has to have a good power point presentation
4. During Sprint Review the Product Backlog may also be adjusted to meet new
opportunities.
5. Each Sprint is an important risk mitigation opportunity for the Product Owner to
review the overall Scrum team progress
Notes:
59
SPRINT RETROSPECTIVE
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan
for improvements to be enacted during the next Sprint. The purpose of the Sprint Retrospective
is to plan ways to increase quality and effectiveness.
During the retrospective, the developers generally

o Inspect how the last Sprint went with regards to with regards to individuals, interactions,
processes, tools, and their Definition of Done.
o Identify and order the major items that went well and potential improvements and
o Create a plan for implementing improvements to the way the Scrum Team does its
work.
The Scrum Master encourages the Scrum Team to improve, within the Scrum process
framework, its development process and practices to make it more effective and enjoyable for
the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase
product quality by adapting the definition of “Done” as appropriate.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most
impactful improvements are addressed as soon as possible. They may even be added to the
Sprint Backlog for the next Sprint.
60
The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for
a one-month Sprint. For shorter Sprints, the event is usually shorter.
The Prime Directive:

Regardless of what we discover, we understand and truly believe that everyone did the best
job they could, given what they knew at the time, their skills and abilities, the resources
available, and the situation at hand.
The Retrospective process goes through five different steps8:
1. Set the stage: This is the step where a safe environment is created to get everyone
participate and involved in the retrospective. In this phase, an agenda for the Retrospective is
prepared and shared with the team so that they will not think of it as an aimless. Some ground
rules around what is acceptable (talking freely about the problem areas) and what is not
acceptable (personal criticism) in the Retrospective is discussed.
2. Gather data: In this step we create a shared vision of what happened in the iteration or
release depending on the focus of Retrospective.
3. Generate Insights: In this step the team tries to evaluate the data gathered in the previous
steps to understand the reasons behind the data gathered. They discuss about the possible
causes for the impediments and discuss on how they can work around them.
4. Decide what to do: In this step the team decides on what are the action items they need to
work based on the conclusions drawn from the Generate Insights step.
5. Close the Retrospective: This is the last step where the team reflects on what happened
during the Retrospective, summarizes and express appreciation to each other.
The book, "Agile Retrospectives: Making Good Teams Great“ by Esther Derby and Diane Larsen
have many retrospective techniques. Here are few of them.
8
Agile Retrospectives: Making Good Teams Great
61
Describe an approach to conducting Sprint Retrospective
Notes:
62
REFERENCES
1. http://www.agilemanifesto.org/
2. http://www.Scrum.org/Scrumguides/
3. http://www.Agile bok.org/index.php?title=Table_of_Contents
4. http://www.mountaingoatsoftware.com/
5. http://www.Agile nutshell.com/user_stories
6. https://www.Scrumalliance.org/why-Scrum/Scrum-guide
7. www.Scrummasterchecklist.org/
8. http://lekman.fi/productownerchecklist/
9. http://agileatlas.org/atlas
10. http://xpprogramming.com/
11. https://lmadhavi.wordpress.com/
BOOK REFERENCES
1. Agile Atlas – Core Scrum – Scrum Alliance
2. Scrum Guide – Jeff Sutherland and Ken Schwaber
3. Agile Project Management with Scrum – Ken Schwaber
4. New New Product Development Game – Hirotaka Takeuchi & Ikujiro Nonaka
5. Essential Scrum: A Practical Guide to the Most Popular Agile Process- Kenneth
S.Rubin
6. Agile Estimating and Planning – Mike Cohn
7. Agile Product Management with Scrum: Creating Products that Customers Love –
Mike Cohn
8. Agile Software Development with Scrum – Ken Schwaber
9. Drive: The Surprising Truth About What Motivates Us - Dan Pink
10. Agile Retrospectives: Making Good Teams Great - Esther Derby, Diana Larsen
11. Retrospectives for Everyone- Madhavi Ledalla
12. Innovation Games: Creating Breakthrough Products Through Collaborative Play –
Luke Hohmann
13. Coaching Agile Teams- Lyssa Adkins
14. Five Dysfunctions of a team: A Leadership Fable by Patric Lencioni
15. Death By meeting: a Leadership Fable by Patric Lencioni
16. Leadership Agility: Five Levels of Mastery for Anticipating ng and Initiating Change
- by William B. Joiner and Stephen A. Joesphs
63

CSM Work Book Madhavi Ledalla 2022-23

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSM Work Book Madhavi Ledalla 2022-23

Uploaded by

Copyright:

Available Formats

CERTIFIED SCRUMMASTER

AGILE MANIFESTO .................................................................................................................... 3

Map the Agile values to the principles below-

AGILE VALUES AGILE PRINCIPLES

Welcome changing requirements, even late in development. Agile processes

PROCESS CONTROL THEORY

PILLARS OF EMPIRICAL PROCESS

AGILE AND EMPIRICISM

SCRUM- ITERATIVE & INCREMENTAL

In a complex environment, the need for an Iterative-Incremental model is augmented by

WHERE CAN SCRUM BE USED?

Quick-think time: Which problem space (Simple, Complex, Complicated,

2. Cleaning the coffee machine–

3. Production Server crash –

5. Support and maintenance work –

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

q Developers: Are committed to creating any aspect of a usable Increment each

Product Owner is a single person and design by committee is problematic at best.

It is the prerogative of the product owner

- Accountable for maximizing the value of the product

Developers have the following characteristics:

Developers are always accountable for:

Challenge Strategy to overcome the challenge

ROLE MAPPING ACTIVITY

Facilitation is an art that can be acquired through practice and it is a journey.

Facilitator facilitates/conducts the process of holding the event/meeting/discussion without

As a facilitator, the Scrum Master facilities

Core practices of facilitation

Role of an agile coach:

Scrum Master as a coach

Tips for Scrum Master to become a good agile coach

Robert K. Greenleaf, originator of the term servant-leadership, describes servant-leader as:

Characteristics of Servant Leader

Tips for impediment resolution:

Discuss at least three common organizational impediments outside the scope of

VALUE OF DEVELOPMENT PRACTICES

Extreme Programming Engineering Practices (XP)

During the Sprint

Advantage of having a consistent sprint length-

Commitments - Each artifact contains a commitment to ensure it provides information that

3. Increment: An Increment is a concrete stepping stone toward the Product

Each Product Backlog item has attributes of

Guiding Principles of a Product Backlog:

Consequences True or False

PRODUCT BACKLOG REFINEMENT

This activity might include:

Sprint Planning addresses the following topics:

1. Topic One: Why is this Sprint valuable?

Sample Sprint backlog

Sprint Backlog is referred to as -

Commitment: Sprint Goal

Which of the following are Myths/Facts?

o It provides guidance to the Developers on why it is building the Increment

Write an example Sprint Goal

Here is an example of what might be used:

Daily Scrums improve communications, eliminate other meetings, identify impediments to

Which of the following are Myths/Facts?

The Definition of Done(DOD) is a shared understanding, a common definition of what it

The Definition of Done creates transparency by providing everyone a shared understanding

Symptoms of weak definition of done-

Discuss which of these are examples of a strong DOD?

Which of the following are Myths/Facts?

During the retrospective, the developers generally

The Prime Directive: