SCRUM

Scrum is a lightweight framework that helps people, teams and organizations deliver value
incrementally through adaptive solutions for complex problems.

Scrum delivers value in iterative & incremental way. Scrum engages groups of people who collectively
have all the skills and expertise to do the work and share or acquire such skills as needed.
Ex: Developers deliver a set of features in each sprint, next sprint they deliver some more features
and so on

Scrum framework consists of below:

3 roles or accountabilities (Product Owner, Scrum Master and Developers)

5 events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective)
3 artifacts (Product Backlog, Sprint Backlog, Increment)

Why it is called Scrum?

It is actually inspired by a scrum in the sport of rugby. In rugby, the team comes together in what
they call a scrum to work together to move the ball forward. In this context, Scrum is where the team
comes together to move the product forward.

Scrum follow Agile Values

Individuals and interactions – Developers deliver the work on their own to complete the goal. They
have all the skills required to complete the goal and have authority to plan how to complete the
work.
Working software – The team gets back together. Developer shows what they are produced and
feedback is gathered from the stakeholders.
Customer collaboration – Scrum team plans together & agrees on the delivery goal
Respond to change – Scrum team starts the next iteration planning based on the feedback from last
iterations.
Scrum is founded on the empiricism & lean thinking.

Scrum is an empirical process, where decisions are based on observation, experience and
experimentation. (In the context of Scrum, empiricism refers to the idea that solving complex
problems, or doing complex work, can only be done using an exploratory process rather than relying
on predetermined plans.)
Ex: Developers estimate for the current sprint based on the average time they took to complete the
work in earlier sprints

Lean thinking reduces waste and focuses on the essentials. In order to Deliver as early as possible,
the Scrum Team will have to remove any kind of wastes in their way of working; their processes, their
tools and other aspects of their product development.
Ex: 1. Defects are a waste. If a Scrum Team with every release adds more bugs than fixing them,
clearly is going to do a lot of reworks which is a waste.
2. A Scrum Team that creates Transparency through usage of automated tools, can avoid
unnecessary status update meetings to a large extent
3. If the right stakeholders are invited to the Sprint Review, then any additional update meetings can
be avoided.

Scrum Pillars

Scrum combines four formal events for inspection and adaptation within a containing event, the
Sprint. These events work because they implement the empirical Scrum pillars of transparency,
inspection, and adaptation.

Transparency: Scrum considers transparency of the three artifacts (product backlog, sprint backlog &
increment) to be very important. The scrum team and everybody involved must have visibility into
these artifacts because decisions are based on them. Transparency enables inspection. This means
presenting the facts as is. Everyone strives and collectively collaborates for the common
organizational objective the product goal & sprint goal, and no one has any hidden agenda.

Ex: In Scrum all requirements are in the Product Backlog, the entire Scrum team should have access
to the same.
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.
Ex:
1. Developers inspect on daily basis in Daily Scrum how the progress is going towards the Sprint goal,
this will also help in controlling risk.
2. Developers openly and transparently shows the product at the end of each Sprint to the customer
in order to gather valuable feedback.

Adaptation: Is about continuous improvement, the ability to adapt based on the results of the
inspection. The adjustment must be made as soon as possible to minimize any further deviation.
Adaptation becomes more difficult when the people involved are not empowered or self-managing.

Ex: Based on the feedback during the Sprint Review developers make required changes and progress
towards delivery of Sprint Goal.

Scrum Values

One critical Scrum Team characteristic that binds all of the elements together is Trust. The Scrum
Values give direction to the Scrum Team with regard to their work, actions, behaviour and drive trust.
The Scrum Values of Commitment, Focus, Openness, Respect, and Courage are all important
elements that Scrum Team members must consider when working together.

Commitment: Scrum Team commits to achieving its goals and supporting each other. This involves
commitment to delivering value, quality, working towards the Product & Sprint goals & using
empiricism.
Ex: developers commit to points in the Sprint Backlog and deliver the value at the end of the Sprint.

Focus: Scrum team focus on the work of the Sprint to make the best possible progress toward these
goals.
Ex: Developers focus on creating value, what’s currently most important and getting to Done.
Openness: Scrum Team and its stakeholders agree to be open about all of the work and the
challenges while performing the work. They should share feedback and learn from each other and
from their stakeholders.
Ex: Developers should discuss openly with stakeholders/PO/SM if they have any challenges

Respect: Scrum Team members respect each other to be capable, independent people, and are
respected as such by the people with whom they work.
Ex: Scrum team encourage team embers of lesser experience to give suggestions whenever they
want to. To overcome differences within the scrum team, Scrum has only 3 accountabilities PO, SM &
Developers.

Courage: Scrum Team members have the courage to do the right thing, to work on tough problems.
Ex: Scrum team should exhibit courage to explore the unknown, to change direction, to share
information and to engage in courteous disagreements.

Scrum Team

The fundamental unit of Scrum is a small team of people, a Scrum Team.

The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.

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.

The Scrum Team should typically consist of 10 or fewer people. In general, we have found that
smaller teams communicate better and are more productive.

They are structured and empowered by the organization to manage their own work. Working in
Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.

Note: If Scrum Teams become too large, they should consider reorganizing into multiple cohesive
Scrum Teams, each focused on the same product. Therefore, they should share the same Product
Goal, Product Backlog, and Product Owner.

Product Owner

A Product Owner is accountable for maximizing the value of the product resulting from the work of
the Scrum Team.

What does a Product Owner do?

The Product Owner is accountable for effective Product Backlog management, which includes:

 Developing and explicitly communicating the Product Goal

 Creating and clearly communicating Product Backlog Items
 Ordering Product Backlog Items
  Ensuring that the Product Backlog is transparent, visible and understood
The Product Owner is one person, not a committee. The Product Owner may represent the needs of
many stakeholders in the Product Backlog.

The Product Owner owns the product vision. They play a crucial role in guiding the rest of the Scrum
Team toward a shared understanding of the product’s value, purpose, goals and direction.

Product Owners use Scrum and the elements of the Scrum framework to deliver on their vision of
the product. For example: applying empiricism and experimentation for product and value discovery;
crafting concrete, actionable and measurable Product Goals to provide focus for the Scrum Team;
and using strong backlog management techniques to help communicate steps toward the Product
Goal.

Developers

Developers are the people in the Scrum Team that are committed to creating a usable Increment
each Sprint.

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.

Developers, and all Scrum Team Members to remember to embrace the Scrum Values. There may be
instances, for example, where they need:
Commitment to the creation of a Done Increment;
Focus on the work they are doing and be careful not to be distracted;
Openness to embrace each other’s ideas;
Respect for all of the members of the Scrum Team and their ideas as well;
Courage to bring up conflicts among the team to work to resolve them together.

Scrum Master

The Scrum Master is accountable for establishing Scrum. They do this by helping everyone
understand Scrum theory and practice, both within the Scrum Team and the organization while
serving the Scrum Team as well as the larger organization.

the Scrum Master is accountable for the Scrum Team’s effectiveness as they help the Scrum Team to
improve how the team works together to create value on an ongoing basis.

What does a Scrum Master do?

Scrum Masters utilize their unique skillset to do a lot of critical work that helps the Scrum Team and
the organization as listed below.
The Scrum Master:

helps the Scrum Team:

 By coaching the team members in self-management and cross-functionality

 Focus on creating high-value Increments that meet the Definition of Done
 Influence the removal of impediments to the Scrum Team’s progress
 Ensure that all Scrum events take place and are positive, productive, and kept within the
timebox.

helps the Product Owner:

 Find techniques for effective Product Goal definition and Product Backlog management
 Provide ways for the Scrum Team to understand the need for clear and concise Product
Backlog items
 Establish empirical product planning for a complex environment
 Facilitate stakeholder collaboration as requested or needed

supports the Organization:

 By Leading, training and coaching them in their Scrum adoption

 Planning and advising Scrum implementations within the organization;
 By helping employees and stakeholders understand and enact an empirical approach for
complex work
 Remove barriers between stakeholders and Scrum Teams

Scrum Events

Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are
specifically designed to enable the transparency required. Failure to operate any events as prescribed
results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and
to minimize the need for meetings not defined in Scrum. Optimally, all events are held at the same
time and place to reduce complexity.
Sprint

Sprint is the container for all of the work that’s done by a Scrum Team to achieve a Sprint Goal. Each
Sprint may be considered a short project.

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 & Sprint Goal including Sprint Planning, Daily
Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.

During the Sprint:

● No changes are made that would endanger the Sprint Goal;
● Quality does not decrease;
● The Product Backlog is refined as needed; and,
● Scope may be clarified and renegotiated with the Product Owner as more is learned.

Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. Only
what has already happened may be used for forward-looking decision making.

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the
authority to cancel the Sprint.

Sprint Planning

Every Sprint starts with Sprint Planning where the Scrum Team determines what they plan to
accomplish during the course of the Sprint.

Sprint Planning is an event for the entire Scrum Team. Scrum Team may invite people from outside
the Scrum Team if they feel their advice would be helpful.
The Product Owner ensures that attendees are prepared to discuss the most important Product
Backlog items and how they map to the Product Goal.

Three topics are addressed during the course of the event:

 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

 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. The Scrum Team may refine these items during this
process, which increases understanding and confidence.

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.

Ex: Developers consider below points while committing to the work they want to accomplish
in the sprint.

 Based on their past performance in the previous sprints

 Whether all the required skillsets to complete the work are present in the team
 Think of schedule time off & holidays

 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. This is often done by decomposing Product
Backlog items into smaller work items of one day or less. How this is done is at the sole
discretion of the Developers. No one else tells them how to turn Product Backlog items into
Increments of value.

Developers estimate effort required to complete each story using estimation techniques.

Note: 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.

Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint.

Role of Scrum Master during Sprint Planning:

 Has specific accountabilities during the Sprint Planning event for helping the team fulfil the
requirements of the event. For example, the Scrum Master guides the team if they see that
PBIs aren’t sufficiently defined, the team doesn’t identify potential impediments, the Sprint
Goal doesn’t support the Product Goal or the team has selected an unattainable amount of
work.
  Often the Scrum Master acts as the facilitator for this event, though this is not required.
Facilitation of Sprint Planning can be done by anyone at the event.

Daily Scrum

The Daily Scrum purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog
as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity,
it is held at the same time and place every working day of the Sprint.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum
focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of
work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and
consequently eliminate the need for other meetings.

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet
throughout the day for more detailed discussions about adapting or re-planning the rest of the
Sprint’s work.

Role of the Scrum Master During the Daily Scrum

 The Scrum Master ensures that the meeting happens, but the Developers are responsible for
conducting the Daily Scrum. The Scrum Master teaches them to keep the Daily Scrum within
the 15-minute time-box.

 The Daily Scrum is an internal meeting for the Scrum Team. If others are present, the Scrum
Master ensures that they do not disrupt the meeting.

Sprint Review

The Sprint Review purpose is to inspect the outcome of the Sprint and determine future
adaptations. The Scrum Team presents the results of their work to key stakeholders and progress
toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and
what has changed in their environment. Based on this information, attendees collaborate on what to
do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a
working session and the Scrum Team should avoid limiting it to a presentation.

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.

The Sprint Review may include the following elements and more:

 Attendees include the Scrum Team and key stakeholders invited by the Product Owner;

 Members of the Scrum Team explain what Product Backlog items have been “Done” and
what has not been “Done”;

 The Developers discuss what went well during the Sprint, what problems it ran into, and how
those problems were solved;

 The Developers demonstrate the work that it has “Done” and answers questions about the
Increment;

 The Product Owner discusses the Product Backlog as it stands. He or she projects likely target
and delivery dates based on progress to date (if needed);

 The entire group collaborates on what to do next, so that the Sprint Review provides
valuable input to subsequent Sprint Planning;

 Review of how the marketplace or potential use of the product might have changed what is
the most valuable thing to do next; and,

 Review of the timeline, budget, potential capabilities, and marketplace for the next
anticipated releases of functionality and capability of the product.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product
Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new
opportunities.

Sprint Retrospective

The Sprint Retrospective purpose of the is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions,
processes, tools, and their Definition of Done. Inspected elements often vary with the domain of
work. Assumptions that led them astray are identified and their origins explored. The Scrum Team
discusses what went well during the Sprint, what problems it encountered, and how those problems
were (or were not) solved.

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.

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.

During the Sprint Retrospective, the team discusses:

 What went well in the Sprint

 What could be improved

 What will we commit to improve in the next Sprint

The Scrum Master encourages the rest of the Scrum Team to improve its 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 improving work processes or adapting the
definition of “Done” if appropriate and not in conflict with product or organizational standards.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that
it will implement in the next Sprint. Implementing these improvements in the next Sprint is the
adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented
at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and
adaptation.

Scrum Artifacts

Scrum’s artifacts represent work or value. They are designed to maximize transparency of key
information. Thus, everyone inspecting them has the same basis for adaptation.

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.

The Definition of Done is the commitment by the Developers for the Increment, much like the Sprint
Goal is the commitment by the Developers for the Sprint Backlog and the Product Goal is the
commitment by the Product Owner for the Product Backlog.

Product Backlog

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the
single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for
selection in a Sprint Planning event. They usually acquire this degree of transparency after refining
activities.
Product Backlog refinement is the act of breaking down and further defining Product Backlog items
into smaller more precise items. This is an ongoing activity to add details, such as a description,
order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may
influence the Developers by helping them understand and select trade-offs. Multiple Scrum Teams
often work together on the same product. One Product Backlog is used to describe the upcoming
work on the product.

Commitment: 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 fulfil (or abandon) one
objective before taking on the next.

Sprint Backlog

he Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected
for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

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.
Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have
enough detail that they can inspect their progress in the Daily Scrum.
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
also creates coherence and focus, encouraging the Scrum Team to work together rather than on
separate initiatives.

The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog.
As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to
be different than they expected, they collaborate with the Product Owner to negotiate the scope of
the Sprint Backlog within the Sprint without affecting the Sprint Goal.

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.

Commitment Definition of 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. Once the Definition of Done is met, the Increment is
Done and can be delivered.

The Definition of Done creates transparency by providing everyone a shared understanding of what
work was completed and what standards were met 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.

If the Definition of Done for an Increment includes the standards of the organization. In that case, all
Scrum Teams must follow these standards as a minimum. They can elaborate on it with any other
standards or characteristics that need to be met for the product. If there are not specific
organizational standards, the Scrum Team must create a Definition of Done appropriate for the
product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams
working together on a product, they must mutually define and comply with the same Definition of
Done.

Some examples of the items in a Definition of Done for a health-focused software application

 All testing completed

 No known defects
 Code review completed and passed
 Meets HIPAA Compliance standards
 Meets general security requirements

Once all of the items in the Definition of Done are checked off and complete, this Increment is
considered Done.

Difference between Product & Sprint backlog

Product Backlog Sprint Backlog

Managed by Product Owner Maged by Developers
Commitment: Product Goal Commitment: Sprint Goal
Product goal, for greater focus & transparency Sprint Goal (why),
the Product Backlog Items (what) selected for
the Sprint,
the plan (how) for delivering the increment
Single source of work undertaken by Scrum Its highly visible, real-time picture of the work
Team that developers plan to complete in the sprint
Product's long-term strategic plan and evolves short-term plan to accomplish a series of tasks
with the product within the sprint
PO prioritizes the tasks and align them to Development team handles tasks breakdown
goals and execution

Difference between DoD & Acceptance Criteria

Definition of Done (DoD) Acceptance Criteria (AC)

Criteria at the macro level and is applied to all at the micro-level and are unique and
Product Backlog items before they can specific to each Product Backlog item
be considered part of an Increment
Practice Definition of Done is part of Scrum complementary practice to Scrum
Scope usually defined at an organisational or determined at the backlog item level and
team level and remains relatively can vary widely between one and another
stable throughout the consecutive
Sprints
Purpose ensures the product increment meets focus on whether the product increment
the quality standards listed and is fulfills the specific requirements of the
useful and ready for a future release Product Backlog Item.
 Creation Creating DoD is a collaborative process are primarily the product owner's
involving the entire team and responsibility, but can also be delegated to
sometimes even multiple teams or the the Developers, and is often made in
entire product organisation collaboration with stakeholders
Usage is referenced and applied at the end of are used throughout the sprint to guide
the sprint to assess if work is complete development and testing.

Example of DoD for code quality and completeness:

 All code must pass a peer review process with no critical issues.
 Unit tests are written for all code, achieving 80% code coverage.
 All code complies with the team's coding standards.

Example of Acceptance Criteria for user's shopping cart checkout:

 The checkout process should handle multiple items (at least ten unique items) in the
shopping cart.
 The user must have the option to enter a promotional code for a discount before finalizing
the purchase.
 The user should receive a confirmation number and an email order summary upon
successful purchase.

Impediments

Impediments are any obstacles or issues that slow down or block the team from delivering value and
achieving their goals. Impediments can relate to a variety of aspects in product development,
including technological or process issues as well as issues within the team or organization itself, or
external to it.

Scrum Teams will inevitably encounter impediments in a complex environment. They will need to
identify and address them in order to continuously improve their performance and become more
efficient and effective in delivering value to their customers.

Common examples of impediments for a Scrum Team include:

Shortage of relevant skills or knowledge on a team

A lot of technical debt

Adverse team dynamics
Lack of management support
Inability to make decisions because of lack of empowerment
Dependencies on other teams or external sources
Technical issues, like access to tools, networks being down and broken laptops
Bureaucracy, e.g. distractions from legacy processes
Who is responsible for identifying and raising impediments?

Anyone on the team can identify and bring up any obstacles or issues that they believe stop or slow
the team down from making progress and delivering value. As a Scrum Master it is important to
understand if these are real impediments or obstacles that the Developers can resolve themselves.
To promote self-management the Scrum Master should encourage the team to share their concerns
and collaborate on solutions to solve their own problems.

The Scrum Team should regularly inspect and improve upon their processes, tools and interactions so
they can be more effective. The Scrum Master can facilitate this process by encouraging the team to
share their concerns and collaborate on solutions.

When should team members raise impediments?

Impediments that the team faces during the Sprint should be made known as early as possible and at
a minimum they should be raised at the Daily Scrum. However, Developers should not feel the need
to wait for their Daily Scrum if they are blocked or hindered from making progress.

The Sprint Retrospective can be a good opportunity to work through recurring impediments as the
team will have time to reflect more deeply on issues they are facing. As in the case of the Daily
Scrum, Developers should not wait for the Sprint Retrospective to bring up impediments.

It is essential for Scrum Teams to continually identify, discuss and deal with impediments so they can
progress toward their goal in an efficient and effective manner.

How Do I Measure the Success of a Scrum Master?

The purpose of the Scrum Master is to improve the effectiveness of the Scrum team, which can mean
coaching the team and coaching the organization in the use of Scrum.

Delivery of Value Incrementally

One of the primary goals of Scrum is to deliver value to the customer incrementally. An effective
Scrum Master should help the team to understand the value of incremental delivery and help them
understand how best to achieve it in their environment. (See our recent article, Three Steps to Done
in Scrum. You can gauge their effectiveness by examining whether the team consistently delivers
increments of usable Product every Sprint. Are they meeting their Sprint Goal on a regular basis? Is
the Product evolving and improving with each increment? If the answer is yes, it's a positive sign that
the Scrum Master is helping the team deliver value incrementally.

Positive Team Dynamics

Observe the team's interactions and dynamics during meetings and day-to-day work. Are team
members collaborating effectively? Do they openly communicate and share ideas? Is there a sense of
positivity and camaraderie among team members? An effective Scrum Master will actively work on
improving team dynamics and ensuring a healthy work atmosphere. Scrum relies on a set of values
(courage, respect, openness, commitment and focus) as well as the principles in the Agile manifesto.
An effective Scrum Master ensures that the team respects and adheres to these values and
principles, fostering an Agile mindset within the team.

Focus on Continuous Improvement

Continuous improvement is at the heart of Empiricism. If the team is not transparent about their
work and their processes, inspecting their work regularly and adapting their approach, they are not
understanding the ‘why’ behind the Scrum framework. Look for evidence of Retrospectives and the
implementation of action items resulting from them. Is the team actively identifying areas for
improvement and taking steps to address them? An effective Scrum Master will encourage and
facilitate these continuous improvement efforts, driving the team towards greater efficiency and
effectiveness.

Vision and Product Goal

Part of the Scrum Master accountability is coaching the Product Owner to find ways to articulate a
Product Goal and Product Backlog. An effective Scrum Master will work with the Product Owner to
ensure that they are able to articulate a clear vision and product goal that guides the team's work.
The Scrum Master should coach the Product Owner to ensure that this vision/Product Goal is
regularly communicated and understood by all team members.

Empowered and Self-Managing Team

The Scrum Master's role includes empowering the team to be self-managing. An effective Scrum
Master encourages team members to take ownership of their work, make decisions collectively, and
resolve issues independently. A self-managing team is a sign that the Scrum Master has succeeded in
promoting autonomy and responsibility.

Conclusion

Evaluating the effectiveness of a Scrum Master is essential for maintaining a successful Agile
environment. By assessing indicators such as incremental value delivery, positive team dynamics, a
focus on continuous improvement, clarity of vision and product goals, and progress towards those
goals, you can gain valuable insights into the Scrum Master's impact on the team and the
organization as a whole. An effective Scrum Master not only ensures that the Scrum process runs
smoothly but also helps the team evolve and deliver value consistently.

In conclusion, evaluating the effectiveness of a Scrum Master is a multifaceted process. By

considering these additional signs, you can gain a more comprehensive understanding of how well
the Scrum Master is facilitating Agile practices, fostering a productive team environment, and driving
positive outcomes for the organization.