Scrum Sprint: Retrospective

The Sprint Retrospective is an opportunity for the development team to reflect on the
previous sprint, determine what went well, and identify opportunities for improvement for the
next sprint. In this course, you'll examine the concepts associated with productive Sprint
Retrospectives. You'll learn about the key elements of a retrospective event, how the team
inspects its performance, common tools and techniques, and the role of the scrum master.

Table of Contents
1. Course Overview
2. Purpose of the Sprint Retrospective
3. Key Elements of the Sprint Retrospective
4. Sprint Retrospective Tools and Techniques
5. Sprint Retrospective and the Product Backlog
6. Sprint Retrospective Participants
7. Team Values and Behaviors
8. Avoiding Common Sprint Retrospective Mistakes
9. Scrum Master Role in the Sprint Retrospective
10. Course Summary

Course Overview
[Video description begins] Topic title: Course Overview [Video description ends]

Hi, I'm Barb Waters, I'm a Certified Scrum Master and PMI Agile Certified Practitioner.

[Video description begins] Your host for this session is Barb Waters. She is a technical
instructor. [Video description ends]

And I have over 20 years of experience managing projects and implementing process
improvements for Fortune 500 companies.

During my career, I've observed and participated in scrum across a range of different
organizations, with the goal of maximizing value to the customer at the end of each sprint. In
this course, we will explore the sprint retrospective, one of the events in the scrum
framework. We'll recognize the key elements of these meetings, who should attend, and what
roles each participant plays. We'll also examine what success looks like for the product and
for the team.

And finally, we'll consider the role of the scrum master and how they can help the team to
avoid common mistakes. This course will provide you the fundamentals of the sprint
retrospective so that you have the tools you need for scrum team success.

Purpose of the Sprint Retrospective

[Video description begins] Topic title: Purpose of the Sprint Retrospective. Your host for this
session is Barb Waters. [Video description ends]

In this topic, we will recognize the purpose of the Sprint Retrospective within the Scrum
framework. Before we jump into the specifics of this event, it may be helpful to revisit the
framework for Scrum product delivery and focus on the purpose of the Scrum Retrospective
within this larger framework.

Within the Scrum framework, the product owner serves as the voice of the customer and key
stakeholders and prioritizes requirements based on value. This becomes the product backlog.
Once the backlog has been prioritized, the Scrum team will participate in the Sprint planning
meeting. The purpose of planning is to agree upon the goals for the upcoming Sprint.
The Scrum team will decide which features or functionality will make up the next product
increment. Then the Sprint will begin.

Sprints are usually about two weeks in duration. During the Sprint, there is a daily Scrum or
stand-up meeting, where the team can identify the work that was accomplished the previous
day and look ahead to the work they plan to complete today. They will also revisit the Sprint
goal to make sure they're on track to meet it. At the end of the Sprint or iteration, the latest
increment of finished work will be demonstrated to key stakeholders in order to get feedback
and determine if the increment of work meets requirements and is considered done based on
criteria established during Sprint planning.

This brings us to the Sprint Retrospective, which is an event specifically for the Scrum team.
They will reflect on what went well in the previous Sprint and identify opportunities for
improvement when working together during the next Sprint. After the Sprint Retrospective,
Sprint planning for the next iteration will begin. Now that we've reviewed the Scrum
framework and where the Sprint Retrospective sits, we'll recognize the key elements of this
event and examine what success looks like for the team.

Key Elements of the Sprint Retrospective

[Video description begins] Topic title: Key Elements of the Sprint Retrospective. Your host
for this session is Barb Waters. [Video description ends]

During the Sprint Retrospective, the scrum team, including the development team, the scrum
master and the product owner, will inspect their own performance during the most recent
sprint.
When creating a new product, of course, it's important to inspect the product increment and
that's what the sprint review accomplishes.

But we also have to look at how we performed the work and determine how we might
improve in that area as well. During the Sprint Retrospective, the scrum team can evaluate
and discuss which parts of the previous sprint went well. This can be used to establish and
confirm best practices for the team. They will also discuss what could have gone better as a
way of focusing on areas of improvement, even if a sprint went very well, there are always
opportunities to make it even better next time.

Finally, the team will make commitments about what to improve for the upcoming sprint.
The scrum team's purpose in the Sprint Retrospective is to constantly improve its own
processes for the next sprint. Because the Sprint Retrospective is an event in the scrum
framework, time and space is purposely carved out for this quality time between team
members. During a sprint, it's normal that teams will face challenges, whether it's learning
how to properly document a definition of done or holding effective meetings or respecting
roles and responsibilities. There will be lessons learned with each sprint.

And by making the most of these opportunities, scrum teams can incrementally improve their
performance with each sprint. One of the benefits of the Sprint Retrospective is that this
meeting is already on the calendar by the start of each sprint. If a team member encounters an
issue that could have been better, they may be reassured that there will be an opportunity to
talk about it later. This allows team members to focus on development and hopefully not be
preoccupied with other concerns. This sprint retrospective serves as an opportunity to inspect
the team's own processes and adapt their procedures and behaviors accordingly.

Sprint Retrospective Tools and Techniques

[Video description begins] Topic title: Sprint Retrospective Tools and Techniques. Your host
for this session is Barb Waters. [Video description ends]

Since one of the core Agile values is individuals and interactions over processes and tools,
meetings such as the sprint retrospective use light weight techniques and exercises to help
identify what working well and what can be improved. One popular exercise is called the
4Ls. During this exercise, individual team members write down, what they liked, what they
learned, what they lacked, and what they longed for in the past iteration. There are four
posters or sections of a whiteboard, one for each of the letters.

One statement is written per sticky note and then placed on the appropriate category. This
part of the exercise should take less than five minutes so team members aren't encouraged to
think too much about their statements. These should be the items that were significant enough
that they are still top of mind. After the team has finished writing their statements and placing
them under the corresponding letters, the team will examine the statements and identify any
themes among them.

Then the team can determine the next steps and how to proceed. One variation on the 4Ls
technique is called KALM, or K-A-L-M. With the KALM technique, participants choose
something the team has been doing well that they should keep doing exactly the same. A new
idea that the team should add or start doing. Something the team has been doing that they
should probably do less of. And finally, something the team has been doing that is working
well and that they would benefit from doing more of. Another exercise that teams can use
during the sprint retrospective is the mad, sad, glad exercise.

During this exercise, team members can write down one statement per sticky note that
indicates something that made them mad, sad or glad during the last sprint. The notes can be
organized on posters or sections of a whiteboard. Sometimes teams struggle with the
difference between mad and sad. Clearly, they're both things the team would want to change
for the future, but how can they be distinguished from one another? I like to use probability
as the deciding factor. What is the likelihood that it will happen again? If it's over and in the
past, maybe we don't put too much effort into solving it for the future.

I once worked with a Scrum team that was displaced from their office space for a week
because the neighboring office in their building had a flood and it affected the wall that they
shared. The Scrum team didn't lose any equipment but development was delayed because
they had to temporarily relocate their desks so that repairs could be made. The team team lost
productivity and it made them sad, but the event was resolved. It was in the past, and they
didn't need to change their way of doing business going forward.

On another team I worked with, during sprints the development team was constantly being
pulled into mandatory training classes that were required by the human resources department.
The meetings were added to the calendar after the sprint was scheduled. And this made the
team members mad because they were held to productivity standards that they couldn't meet
if they were pulled away from development.

The team agreed that something would have to be done about this in the future so that it
didn't keep happening again. By creating this list of mad items, the team could create actions
to correct those items going forward. The sad items give the team an opportunity to vent and
complain a little to acknowledge that, wow, that was really annoying, and then put it behind
them. And the glad items give the team an opportunity to appreciate the things that are going
well that they should keep doing.

A force field analysis can also be used by teams to look at the forces that are helping them to
achieve their goals or hindering them. This principle was developed by social psychologist
Kurt Lewin, and it can be useful during the sprint retrospectives. The team can use an
analogy such as mountain climbing. If you're climbing a mountain, they're going to be things
that impede your progress. It could be loose rocks that fall from above, a slippery ledge or a
heavy pack that you're carrying. There are also forces working for you.

Perhaps it's that power bar that you brought along for you when you get hungry, a climbing
partner who's there for mutual encouragement, or a Sherpa carrying your pack and lending
their expertise and guidance. The car racing analogy uses forces such as the powerful engine
propelling the car forward or a parachute pulling the car back. And the sailboat analogy uses
the wind as a force that can propel the boat forward or an anchor as forces that hold the boat
back. The team can start with the negative forces that held them back in the last sprint, but
they shouldn't forget the positive forces that propelled them forward.

Next, the team can look for ways to remove the negative forces or create a future state goal
for the project. For instance, if the team finds that they're lacking the necessary resources or
skills and that's what's holding them back, they may be able to verbalize this as a need. If we
can receive training on this one particular topic, not only will that remove an anchor, but it
might also serve as wind in our sails for the future. In this video, we'll discover more tools
and techniques for performing the sprint retrospective.

A radar chart is a tool that a Scrum team can use during the sprint retrospective. This radar
chart is an example and can be tailored as your team sees fit. This team has decided to divide
their chart into three main categories, team, product, and process. Within each category, there
are three sub categories. The team should work together to score themselves in each category,
with 10 being the best and 0 being the most opportunity for improvement. If there are
differences of opinion, the team can discuss the topic openly.

A facilitator could also be helpful, and teams may consider using rounds of anonymous
voting and discussion, as happens in the Delphi technique. Once all of the questions have
been answered and scored from 0 to 10, each question is plotted on the radar chart, with
lower scores toward the center, and higher scores toward the outside of the chart. Ratings
toward the center of the chart would indicate more opportunity for improvement, while
readings toward the outer part of the chart would indicate that the team is performing strongly
in this area.

In the example shown, it appears that this Scrum team has a clear definition of done and they
feel that they're pretty good at managing changes and following their processes. However, the
team is rather inexperienced, and it appears that they could use some help with clarifying
roles and building trust. The scrum master may see this as an opportunity to lead some team-
building exercises and possibly set up a team charter and ground rules around meetings.

If you are setting up a team radar, it helps to clarify what each of the topics means and to
work on it together as a team. Once the ratings have been plotted, the team can observe
patterns and determine what actions they can take to strengthen areas and to confirm their
success in other areas.

Sprint Retrospective and the Product Backlog

[Video description begins] Topic title: Sprint Retrospective and the Product Backlog. Your
host for this session is Barb Waters. [Video description ends]

In this video, we'll describe how the sprint retrospective affects the product backlog. When
you first learned the title of this topic, your response might be, wait a minute, sprint reviews
are about the product. And it's a good time to refine the backlog, but why is this coming up as
a topic for the sprint retrospective?

That's a fair question. It is correct, the product backlog consists of the new features and
functionality waiting to be developed next. And how that work is performed is just as
important. This may be debatable, but let me give you an example. Let's say that you've been
happily going to your favorite restaurant for years now, but the last time you visited, you
caught a glimpse of the kitchen.

In addition to being unsanitary, you also saw that the workers looked very tired and the
manager was yelling at one of them in a very cruel way. Will this cause you to think about
their products a little differently now, even if the meals are delicious? What about the way
they're made? The same goes for Scrum teams. The way we approach our work matters. The
team, their dynamic, and their processes all matter.

While the sprint review will help to reprioritize the work that's developed, the retrospective
will change the way it's developed. We'll leave it at that. In order to ensure that Scrum teams
receive lasting value from the retrospectives, there should be some traceability between the
retrospective and the next sprint or action items that the team agrees to take.

In fact, according to the Scrum guide, to ensure continuous improvement, the sprint backlog
includes at least one high priority process improvement identified in the previous
retrospective meeting. The Scrum framework is not prescriptive, so it doesn't tell teams
precisely what to do with opportunities for improvement that are discussed in the sprint
retrospectives.
So let's review one of the 12 principles of Agile that says at regular intervals the team reflects
on how to become more effective, then tunes and adjusts its behavior accordingly. So the
retrospective is not only about reflection or what we would call inspection, it's also about
adaptation. If the Scrum team doesn't develop a plan for process improvement, they'll get
caught up in development as soon as the next sprint begins.

And on continues the cycle of knowing you have issues but never doing anything about it. It's
usually right after the sprint retrospective that teams have the best opportunity to improve
their processes. But unfortunately, it's usually exactly where teams leave the issue sitting. Just
like any unresolved issues, when they come up again and again, sprint after sprint, they may
be accompanied by bad feelings and conflict. Why haven't we fixed this by now? And then
the entire sprint retrospective becomes the target.

Why do we just sit around and complain? Let's get back to work. And then the sprint
retrospective goes away. This is bad for the team dynamic, and it's not sustainable. By
creating a plan, the team shows its intention to make improvements. Once the Scrum team
identifies opportunities for improvement, the next question should be, how? For instance, let's
say that the team notices that they've not been adhering to their meeting time blocks. They've
been going a bit longer and longer.

And now the daily standup is taking closer to 30 minutes rather than 15 minutes. That might
not seem like a lot, but if there are nine members on the team, that equals more than two
hours of development time lost. Every day, in a two-week sprint, the team would have lost 20
hours of productivity for this minor lack of discipline.

Once an opportunity for improvement is identified, the Scrum team will need to prioritize this
into the next sprint. Some sprint backlog items can be as simple as a checklist, while others
may be actual tasks that need to be prioritized with the development work. In this case, the
task could be procuring a clock or a timer that's visible to all team members for the daily
standup.

But, in other cases, the process improvement task could require more effort and may need to
be estimated along with other development work. In addition to planning and prioritizing
improvements, the team should also track their performance against the new goal to ensure
that quantifiable improvements are being made from one sprint to the next. Measurable data,
such as meeting durations, can be tracked and compared to the goal to ensure that incremental
improvements are really being made.

When the Scrum team identifies areas of improvement and determines that there are actions
to be taken, they can often negotiate and prioritize these right into the backlog. Depending on
the urgency and value of the improvement, the improvements will be prioritized along with
new development. In other cases, the need for improvement may involve decisions that are
outside of the team's control.

At the organizational level, there may be items that could help to improve the team's
performance. In cases such as this, the Scrum master, as the servant-leader to the team, can
serve as a liaison to try to pursue improvements on the team's behalf.

Sprint Retrospective Participants

[Video description begins] Topic title: Sprint Retrospective Participants. Your host for this
session is Barb Waters. [Video description ends]

In this video, we will identify the participants of the Sprint Retrospective. Attendees of the
Sprint Retrospective include the entire Scrum team. This includes the development team, the
product owner and the scrum master. The scrum team may decide to include others in the
retrospective. If they can provide information or a unique perspective, but keep in mind that a
Sprint Retrospective is an environment that must feel safe for all participants to share and
communicate openly. The Sprint Retrospective is about the team itself.

While transparency is one of the scrum pillars, this doesn't mean that stakeholders are invited
to observe the Sprint Retrospective. It means ensuring that the team has an opportunity for
introspection and to arrive at a shared vision. Scrum teams often have their own norms and
ways of doing things.

But one thing that should be consistent for every scrum team is the opportunity for an open
and supportive discussion in a safe environment. Team member should be able to ask for help
and know they'll have the tools and support they need. They should be able to admit mistakes
without being ridiculed or blamed. Team members should be able to share problems whether
those problems are with the work, the environment or something about the team dynamic
itself.

And finally the team should be able to understand that they need to identify and remove their
own barriers to lessons learned. Let's talk about some of those barriers that may inhibit
people from sharing lessons learned. Even the lessons learned are meant to capture successes
as well as where improvements could be made, negative situations can be difficult to talk
about. It might feel like the easier thing to do is to leave the issue in the past, and just move
forward. But conflict resolution strategies, tell us, that this is not the best approach for long
lasting solutions.

There may also be a fear that revealing embarrassing situations, may expose or reflect poorly
on individuals. Team members may worry that what is being discussed in the sprint
retrospective, could be shared outside of the meeting and could become public. This is
especially problematic where the culture of the organization is perceived to punish rather than
learn from mistakes. If there appears to be no solution to the problem encountered, it may be
difficult to capture just the problem without providing a potential solution.

For some team members, this could feel like complaining, but it is important to identify
problems and brainstorm them as a first step to exploring solutions. A strong facilitator is
often needed to draw out and capture many of these negative items. This is where the scrum
master comes in. As the facilitator the scrum master can help the team to identify and
leverage lessons learned. During a Sprint Retrospective, scrum teams may want to
acknowledge that there are some natural human characteristics that can contribute to failure.
When the team's culture includes these modes, it can be a problem.

In his book Agile Software Development, Alistair Cockburn introduced these failure modes.
He said that the human factors that contribute to failure are, we are too careful, we don't like
to fail spectacularly so we embrace what we know. We ignore history, we don't like to study
history to learn what has worked or hasn't worked in the past. We make mistakes, we dislike
change and finally we are inconsistent.
The good news is that there are success modes too. The human factors that contribute to
success are that we are observant. We continue to learn, we're able to adapt in spite of not
wanting to change and we do want to do things the right way.

Team Values and Behaviors

[Video description begins] Topic title: Team Values and Behaviors. Your host for this session
is Barb Waters. [Video description ends]

In this video, we will identify team values and behaviors. One idea that some Scrum teams
have embraced is holding of values-based retrospective. The purpose of this exercise is to
recall the five Scrum values, and determine how the team can align their behaviors to the
values. So it isn't something they just talk about, a Scrum team should aspire to be agile, not
just do agile. So understanding the meaning behind each of the values is an important part of
the exercise.

The five Scrum values are commitment, openness, courage, respect, and focus. Commitment
means dedicating yourself to the team and to the Sprint goal. It means living up to your
promises that were made to colleagues and to the customer. It means giving 100% to see your
coworkers and the team improve and succeed. Openness is a value that must be embraced
during the Sprint retrospective.

Team members must be able to talk through issues and impediments, explore solutions, and
share disagreements professionally. So that the team has transparency and everyone can
orient themselves around problem solving. Courage means being willing to change, even if
that means accepting that you are wrong, or that your opinion is not the direction that the
team is going. It means being able to walk away from an opportunity if it doesn't meet your
ethical standards, or if the business relationship isn't good for both parties.

Respect means supporting one another and helping people with the things you're good at, and
not judging others for the things they don't know. It also means realizing that you can learn
from everyone. And that everyone should be treated fairly and given opportunities to
contribute based on their strengths and unique perspectives.

Focus means giving your full attention to the Sprint and its goal, not working on many things
at once, and preventing distractions. It also means choosing an appropriate amount of work
and dedicating your efforts to getting it done. One values-based exercise that Scrum teams
can perform is to place the five Scrum values on posters or sections of a whiteboard. The
Scrum Master starts by reminding the team of the meaning of each value.

Team members should work together to identify actions they took that supported specific
team values. And actions they may have taken that violated the values. The discussion should
be focused on actions, not individuals, so that the discussion remains functional and solution-
focused. Then the team will select one Scrum value that they can commit to strengthen
through thoughtful actions in the upcoming Sprint.

Since teams spend the vast majority of their time and focus throughout the Scrum framework
on developing the product, it's natural that they may get caught up in processes, procedures,
and functionality. However, at the core of Scrum, there are some basic values that must be
shared by all team members. And those values must be honored through their actions and
practices.

Avoiding Common Sprint Retrospective Mistakes

[Video description begins] Topic title: Avoiding Common Sprint Retrospective Mistakes.
Your host for this session is Barb Waters. [Video description ends]

In this video, we will discuss common mistakes of sprint retrospectives, and how the scrum
master can help the team to avoid them. Since the sprint retrospective is an opportunity for
the team to identify areas for improvement, this may be confused for an opportunity to fix
everything. One of the fundamental characteristics of Agile is that it is incremental. And
improvement should be introduced incrementally as well. The retrospective is a great
opportunity for the team to make a commitment to improve itself a little bit at a time. Not
holding a retrospective at all is probably the biggest mistake a team can make.

Teams may do this if they don't hold the retrospective with purpose and really use it as an
opportunity to workshop and come up with meaningful action items for the next sprint. If the
sprint retrospective isn't facilitated by a strong scrum master, it could end up being an
informal complaint session, or worse, the team may see it as an available time block to get
back to work and do more development.

A lack of participation can also be problematic. If all scrum team members don't show up or
show up and don't participate, the team won't get much out of the meeting. And finally, if
teams still create action items to address during the upcoming sprint, they'll likely find
themselves back in the next sprint retrospective, disappointed because nothing ever changes.
When a team tries to improve too many things at once, they don't invest enough time or focus
on any one thing in enough depth in order to fix it.

Teams must choose what to focus on first and they should set reasonable expectations about
how much improvement can be accomplished. It's not about overnight transformation. Kaizen
is the Japanese philosophy of continuous improvement. It supports small steps as a way of
achieving change. The team should work together to identify the top one or two items that
may be impeding their success and attempt to address them first. This may require the
assistance of the management team.

And if so they might invite a representative to join them during the retrospective, or the
scrum master may serve as a liaison. Once the team identifies a few items that they can do
better during the next sprint, it's necessary to decide what success will look like and how it
will be measured. The team can use SMART goals so that the performance is specific,
measurable, achievable, realistic, or relevant, and time-based. While the scrum team is
deciding which items to address, they must make sure that they are, in fact, addressing the
root causes of the problems, and not just the symptoms.

A root cause analysis tool can help to dig below the surface, and figure out what is really
going on. A Fishbone or Ishikawa diagram is a popular cause and effect tool. The head of the
fish is considered the problem, and the bones are the possible causes. I like to use a restaurant
analogy to explain the Fishbone diagram. Let's say that a customer in the dining room of a
restaurant points out to the waiter or waitress that they've been given a dirty plate.
The manager of the restaurant will likely visit the guest, apologize for the problem, replace
the meal, and probably give them the meal for free or provide a complimentary dessert. But
what if we stopped there? The symptoms have been addressed, but nobody bothered to ask,
why was the dish dirty? The Ishikawa diagram would send the manager back into the kitchen
where the causes may be identified. Is the dishwashing machine malfunctioning? Did we
recently change to a new brand of detergent? Or is there a new untrained kitchen staff
member?

Once we identify the issue, we're more likely to resolve it. You could apply the Fishbone
diagram to any industry and tailor the potential causes to fit your own organization. Another
technique is called the 5 Whys. In this exercise, we keep asking why until we get to the root
cause of the problem. If I'm late for work, I could make an excuse that traffic was bad. But if
my tardiness is a chronic problem, we may have to dig deeper.

Why was traffic bad? Well, traffic is always bad at that time of day. Why didn't I give myself
enough time to account for the traffic? Because I woke up late. Why did I wake up late?
Because I stayed up too late watching my favorite show. Aha, now we figured it out. If we
ask why up to five times, generally it will help us to make lasting changes by determining
which of our actions actually led to the problems.

Scrum Master Role in the Sprint Retrospective

[Video description begins] Topic title: Scrum Master Role in the Sprint Retrospective. Your
host for this session is Barb Waters. [Video description ends]

In this video, we will discuss the scrum master's role in sprint retrospectives. The scrum
master serves as the facilitator for this meeting. They generally start by setting the stage. This
may include a reminder of the time block and some basic ground rules for the team. The
scrum master is not in charge, so they won't necessarily do most of the talking. They are there
to make sure that the team stays on track and follows scrum best practices. After setting the
stage, the scrum master may introduce an exercise to help facilitate the discussion. This helps
to provide some structure to the meeting.

It is fine if teams just talk during their retrospectives as long as they're identifying
opportunities for improvement and problem solving. While the sprint retrospective is an
important time to talk about how they felt during the past sprint, it's useful for the team to
quantify a problem or associate solutions with SMART goals. So instead of saying, we are
interrupted too much while we're developing, they might say, we lost two hours due to that
emergency meeting and let's address development downtime with the management team to
see if we can cut it by half.

Once the team collects data through their discussion or exercise, they will analyze the data to
determine where there are opportunities for improvement. Then, they'll need to translate the
opportunities into actual tasks and commit to making the improvements during the next
sprint. Finally, the scrum master helps the team to summarize the meeting and bring it to a
close.

If the scrum master anticipates that a sprint retrospective may be particularly difficult for the
team, they may want to block some time for team building activity at the end, so the meeting
ends on a positive or fun note. Conflict resolution is one of the most important techniques a
scrum team should have in its tool belt. And it's also one of the most important exercises that
the scrum master can facilitate.

The scrum master is not supposed to tell the team how to fix their own problems. They are
there to provide guard rails and to make sure that conflict stays functional and doesn't become
personal, and to suggest techniques. Here are four common conflict resolution approaches.
The first is called force or direct. This means pushing one's own viewpoint at the expense of
others, or offering only win-lose solutions.

Force and direct is usually enforced through a power position to resolve an emergency. This
isn't usually the best technique for scrum teams if there is time to select a longer lasting
solution. However, sometimes it makes sense. Consider a fire department showing up to the
scene of a burning building. There's no time to discuss the best approach to putting out the
fire. And for the sake of time, someone generally calls out commands to the team.

This is appropriate in a fire, but not for everyday problem solving. Withdraw or avoid means
retreating from an actual or potential conflict situation, or postponing the issue to be better
prepared or to be resolved by others. It is appropriate for trivial issues or when it buys time,
but it shouldn't be used for difficult or worsening problems. Unresolved problems can
become much bigger if they're ignored. Also, when a team member withdrawals from a
situation in which they are truly unhappy, they may end up leaving when no one else even
knew there was a problem.

Smooth or accommodate means emphasizing areas of agreement rather than areas of

difference, or conceding one's position to the needs of others to maintain harmony and
relationships. It encourages cooperation in the short term, but it's only a temporary fix. Also,
when one person's needs are constantly accommodated at the expense of everyone else, it can
breed resentment among team members.

Collaborating and problem solving means that the team will confront the issue and cooperate
on a solution. It has the potential for the longest lasting resolution because the problem is
solved and not just the symptoms. Emotional intelligence among individual team members
helps to ensure a high performing team.

There are generally four aspects of emotional intelligence. Self awareness is recognizing your
own internal feelings and emotions and why you might be feeling that way. So instead of
saying, I'm just in a bad mood, self awareness can help us to recognize, I started feeling this
way when another driver was rude to me in traffic on the way to work this morning, I don't
like the way they treated me.

Self regulation is the ability to filter our own external behaviors. So when another driver
might rude to us in traffic, we don't immediately react and mark their rudeness with our own
bad behavior. Social awareness means being able to recognize how other people are feeling,
either by their facial expressions or their words. Emotional intelligence extends into showing
empathy for others, and being able to maintain relationships that are mutually respectful.

Teams can benefit from the emotional intelligence of their members, and a strong scrum
master can identify opportunities for training and coaching in this area. Time blocking is a
fundamental part of scrum. When facilitating scrum meetings, the product owner must help
the team to adhere to the time block.
A sprint retrospective should be approximately one and a half hours for every two weeks of
sprint duration, and no longer. The scrum master facilitates the sprint meetings to ensure the
team is adhering to the time block as part of overall good scrum practices.

Course Summary
[Video description begins] Topic title: Course Summary [Video description ends]

In this course, we have explored the sprint retrospective and the key elements involved in this
scrum event. We reviewed tools and techniques, described changes to the backlog. Identified
participants of the event, examined team values and behaviors, and discussed the scrum
master role. The next course is scrum quality and productivity.

This course presents the concept associated with setting sprint goals and planning for the
sprint. You will learn about the definition of done, how to define the product increment, how
to estimate the sprint backlog and how to avoid common mistakes. Commonly used tools and
techniques and ways to conduct effective sprint meetings are also covered.