Based on the Ken Schwaber and Jeff Sutherland definition of Sprint Retrospective, in this document you will find some common gaps and how we can avoid it

1. Sad 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.
Scrum teams conduct a Sprint Retrospective at the end of every Sprint to find ways to improve the way they
work together. It turns out; having really effective retrospectives requires some specific conditions to exist to
allow improvement to happen. All too often, the team’s environment doesn’t support them expending effort
to make real, substantial improvement because when the team thinks that they have too much work in the
sprint to make improvements, or they found in every retrospective the same impediments and the actions to
solve those impediments are still pending to start, even to assign, the meetings have become useless, boring
and repetitive.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is a
three-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The
Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum
Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member
in the meeting from the accountability over the Scrum process.
The purpose of the Sprint Retrospective is to:
 Inspect how the last Sprint went with regards to people, relationships, process, and tools;
 Identify and order the major items that went well and potential improvements; and,
 Create a plan for implementing improvements to the way the Scrum Team does its work.
Three topics: quiet easy, isn’t it? But we can found a high level of frustration with retrospectives from teams
who regularly do them. Let us see the pattern that they usually use: They are using the following 2 questions:
 What went well?
 What do we want to improve?
After a while, these retrospectives become sad and boring. Usually, the team find the same gaps again and
again … Other teams learn a few basic activities like Sailboat, 6 Thinking Hats, Top 5 , PMI… and then repeat
them, over and over again, every retrospective and they fall again into the same sadness and boring
meeting. Furthermore, where is the first topic? Inside those two questions nobody inspect how the last
Sprint went, we are talking about only about what went well and want to improve, nobody is talking about if
anyone was sick, or if the system was broke …
The basic “two-question” approach is lacking in effectiveness because they are not covering the purpose of
the Sprint Retrospective. Instead this two questions we can follow the following pattern:
 What went well?
 What do we want to improve?
 What have I learned?
 What still puzzles me?
What have I learned? is a powerful question and reflecting on it tends to open our minds to things we might
not otherwise take notice of. It encourages us to look at what we’ve learned about the way we’re
working.This question brings to our attention, and thus reinforces, what we’ve learned. It also opens up the
potential for others to make use of that learning, either by identifying an action to engrain the learning in the
way that the team works or by simply voicing it, allowing others to decide if they’d like to individually try it
out.

2. What still puzzles me? is added to liberate us to express things we wish we had the answers for, but
don’t.These puzzles express a question we have - a gap in our knowledge. This is also a fantastic opportunity
to express concerns, misgivings, doubts or other sensitive topics because you can draw attention to your
worry without making a statement. Some examples could be “Why we are fewer stakeholders during the
review meetings?”, “Why the main objective is changing?”
Other way to manage the Retrospective Meeting is using The5 Stages OfAgile Retrospective pattern:
 Setting the stage
It helps people focus on the work and get the team ready to engage in the agile retrospective. Try to
have a comfortable atmosphere where people feel relax to discuss the issues.
 Gathering data
It creates a shared picture of what happened during the agile retrospective and expands the perspective
of the team. This is where the team answers the What question. In other words, What happened in the
previous Sprint? Not What do we think about what happened? or What do we want to do about it?, just
the facts, the events, the good, the bad, and the indifferent. Some examples might be: lot of HotFix, the
environment broke in the first week, bug counts went up, Mark had training … Data gathering includes
facts and feelings and that guides the team to better think and take action.
 Generating insights
This is the place where the two-question approach should be asked: What went well? and What do we
want to improve?. But don’t play the blame game: the team should adopt a positive attitude at all times
and avoid doing this. The goal is to get better, together.
This is the time for the team to consider and discuss what was successful and identify any roadblocks to
their success. This stage allows the team to step back, review the big picture and find the causes and
therefore think together the best way to improve.
 Deciding what to do
The team needs to pick the most important items from the list of improvements that was done in the
previous stage and fix measurable goals to each of them so they can be completed. The facilitator makes
sure that each person signs up and commits to a specific task. This is to avoid misunderstandings as if it
was a task assigned to the whole team and therefore avoid that no one does it.Might be a good idea
create/review a Retrospective Kanban to keep in track all the pending actions.
 Closing the scrum retrospective
End the Retrospective Meeting with an appreciation to each member’s contribution. Make sure that
what was discussed has value for the team to move forward.
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.
But improvement is not only related to the product that the Development Team is creating for its customer.
A good Scrum Master will seek out training and other resources for retrospective activities to continuously
improve their retrospective facilitation, and every Retrospective meeting, could be different: different
owner, different way to manage it . As with all things agile, we continuously seek ways to improve our
implementation of agile methods. A good starting place is the Agile Retrospectives book but there are other
resources you can draw on such as Retr-O-Mat, Tasty Cupcakes, Retrospective Wiki,, and many others.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will
implement in the next Sprint.

3. But, if not, the team will continue to play the blame game again and again until the end of the times and the
Retrospective's goal becomes to be a place where the team understands what is going wrong even though
they won't do nothing to change it.
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.