What led me to think that each retrospective should be different? Well, it was the candid feedback from my team during one of the trainings we had in the office.
At our training, we were divided into multiple groups for activities. After each activity, instructors conducted feedback sessions, similar to the retrospectives that we conduct on the last day of the sprint. Initially, I found the feedback sessions interesting, but by the end of the fourth session, I was complaining to my colleagues that I was bored by them. Some of their replies were real shockers: "We come for your
retrospectives every two weeks; why are you complaining now?"
Oops! They were definitely not meant to be "your retrospective." They were "our retrospectives" -- or so I had believed. My first thought was, "I am not doing them justice as a ScrumMaster." I was sticking to the conventional routine of what went well
and what could have been better
. At that moment, I decided to try out different formats so that people wouldn't yawn during the retrospectives.
From then on, I scratched my head trying to think of innovative ideas for the retrospectives for the two Scrum teams I managed. I have seen the passion and energy most team members bring to the retrospectives, so I knew it could be done. You can Google different ways to conduct retrospectives, but it's not that easy: You will always need an enthusiastic team to make the retrospectives successful. You might also need to tweak the retrospectives according to each team.
As ScrumMasters, it's our job to figure out how to better customize each retrospective and determine whether the team would gain benefits from these minor improvements. All the methods below were attempted multiple times with different teams, and I always received positive results, with wonderful action items as outputs.
I have also provided references at the end of this article, so you can further explore this subject.
Following are the major outcomes from my improved retrospectives:
- Developers lend a hand to quality assurance whenever needed while training to be a cross-functional and multiskilled team.
- Backlog groomings are more effective.
- The product owner provides user stories that adhere to the INVEST (independent, negotiable, valuable, estimable, small, and testable) model.
- UI automation uses Protractor.
- There are more technical talks among the teams.
- We hold a midsprint review of completed stories.
- Turnaround time for code reviews has been reduced.
- We have applied the concept of "mini-grooming" -- every day, one story is refined before backlog grooming.
- We have a more self-organized, multiskilled, and cross-functional team whose skills grow daily.
Innovative ways to conduct retrospectives
Below are creative ways to conduct retrospectives to keep them fun and engaging.
New Year Retrospective
It's that time of the year when we make resolutions; we talk about what happened last year and think about our resolutions for the coming year. For this year (2015), the team started with a recap of last year. We were a relatively new team that was in its eleventh sprint.
Design a questionnaire that is customized for your team. Because the theme is the New Year, it need not focus on the first sprint only. Also, make sure that the ScrumMaster is involved while discussing the questions.
You will understand which areas the team or individuals will focus on in the upcoming sprint (and others). It casts a light on the personal views of each team member.
The theme for this retrospective was adopted from a concept called Lean Coffee
. This is a structured but agenda-less way of meeting.
The meeting involves four steps.
- Set up a table with three columns: Topics, Discussed, and Discussing.
- Collect feedback (the team writes one topic per sticky note).
- Vote on each topic.
- Discuss topics with the highest and second-highest votes, with related action items.
Each team member strives to come up with the most relevant topic so that it gets the highest vote. The topic is then taken to next level for further discussion.
Use this retrospective for those sprints that are smooth and uneventful.
Job or Joy
You might have a sprint that has no major deliverables, only a couple of spike stories and data migration activities. Doing a retrospective for that sprint might not result in any major action items. In our case, I decided to focus on the personal side of the team. Job or Joy is a retrospective in which the focus is more personal.
Quadrant 1: Things that you love at work.
Quadrant 2: Things that you love outside of work.
Quadrant 3: Things that you don't like outside of work.
Quadrant 4: Things that you don't like at work.
You understand the personal traits of your team. Make sure that the ScrumMaster is also in this game. If the team is close, it can keep the retrospective lighthearted, and team members can laugh at themselves.
To avoid monotony, allow another team member to assume the role of ScrumMaster and facilitate this retrospective. In our case, the retrospective venue was also changed to the cafeteria.
It begins on a positive note, with a team member passing a chocolate (token of appreciation) to the person sitting next to him or her and describing the positive qualities that the person possesses. We came up with a funny name for each person, based on his or her characteristics. These names are still being referenced in our backlog grooming or retrospectives to lighten up the sprints.
Also, team members were asked to come up with one change that they would like to see in the next sprint.
This retrospective asks that the team observe periods of silence (mute) during a Pointing Poker
session, followed by discussion and explanation of each individual's thoughts (self). Here it is fine to focus on "self" rather than thinking as a "team."
We accomplished this goal by using Pointing Poker, which we were already using for sprint planning. We used a four-point system (0, 1, 2, 3) to rate the topics; zero meant that we were not doing it at present, and 3 indicated that we were following it meticulously.
The Y-axis in the following chart represents the number of people involved in the retrospective. The X-axis lists the topics for discussion. Team members play Pointing Poker to cast their points on the first topic (here, "Work Satisfaction"). During this time, we do not talk. Once the voting is over and points are displayed, we do not add them up; rather, each person discusses why they voted as they did. Then we move on to the next topic and repeat the process.
Draw the Iteration
If you want a good laugh, try this retrospective. The team is given a set of five questions to answer in pictures rather than words. The person who draws the picture isn't allowed to explain the answer; other team members try to explain what he or she means.
Try to figure out what the team member meant by the following diagram:
Think Outside the Sprint
By always focusing on the sprint, you might miss the high-level issues that really burn. Here is a way to think outside the sprint and at the same time focus on the four pillars of the team.
Our team used four different-colored Post-It notes. The four colors were used to classify the following areas:
The team was asked to think through the four groups and come up with "Repeat" and "Avoid" activity for each.
Do you want to focus only on the improvements? This retrospective is an easy way to do that.
Pass around Post-It notes. Team members rate the sprint on a scale of 1 to 10. If the rating is less than 10, the team writes what they should do to make it a perfect 10.
The following is a picture that illustrates this type of sprint:
Circle of Questions
The ScrumMaster need not facilitate this retrospective; instead, the entire team conducts it as a group.
One person asks a question, then the team discusses its views on that topic. When the discussion (timeboxed, of course!) is over, the next person asks the second question, and so on. This process helps get to the underlying problems that each person must focus on.
Revisiting Team Principles and Processes
After our 25th sprint, the team wanted to refine our existing process further. We jotted down all the processes, ceremonies, and engineering practices. The team then pointed out the good things and the items to be improved for each point.
- Backlog refinement
- Sprint planning
- Daily stand-up
- Sprint review
- Sprint retrospective
- Test-driven development
- Quality assurance automation
- Code reviews
- Team UI
- Tech talks
RCA (Root-Cause Analysis)
The team had a sprint review in which we discovered one bug was not fixed; this was later caught by the product owner. We did a root-cause analysis retrospective, asking the five "Whys" as the base format.
You can use this retrospective when the sprint has any serious issues for which you need to find the root cause.
Retrospective Dialogue Sheet
Dialogue sheets helps us be more creative and open about the existing issues and aid us in finding the root causes.
Note: This one can go over schedule, because providing a good explanation to the team on its use and answering any questions can take time. Make sure that you set clear expectations during this retrospective.
- Future considerations: List all considerations that had been planned for the project, from the team's perspective.
- Lessons learned: As a team, record all key lessons and takeaways from the sprint.
- Accomplishments/acknowledgments: Acknowledge and thank people for their accomplishments.
- Problem areas: List the problem areas experienced throughout the previous sprint.
What? Who? Due!
This retrospective focuses on the team's long wish list. Make sure that each team member identifies at least one wish to pursue by a set date.
Draw three columns with the headings What
, and Due
. Ask each member to come up with a wish-list item. The wish can be something that he or she wants to do or wants other team members to help him or her out with. The Due column will have a date assigned to each wish.
Retrospectives similar to traditional retrospectives
The methods above are innovative ways to conduct retrospectives. The following methods are similar to the traditional approach, but they're called by various other names.
This retrospective forces the team to think of the push-and-pull factors they face in the sprint.
Draw a speed car with a parachute attached to the back. The engine of the car pushes it forward (i.e., things that help you) and the parachute pulls the car back (i.e., things that hinder you).
The team focuses on negative factors that pull them back in a sprint.
The boat represents the things we are good at and want to continue doing. The shore represents the ideal world we all want to be in. The rock depicts the issues that we want to defer or fix when we proceed with the next sprint.
This retrospective can be tried on relatively new teams so that underlying problems are quickly exposed.
This retrospective is similar to the Boat-Shore-Rock retrospective. Capture those things that the team is really happy about and those that cause concern. "Mad" things represent areas of the process that require alteration. Again, this is a traditional approach, but giving smiley (and frowny) faces to the team for them to vote with might generate a momentary laugh.
- How: Ideas that are good but difficult to implement.
- Now: Ideas that are not creative but can be implemented soon. Ideas already discussed and/or followed up on can fall into this category.
- Wow: Creative ideas that can be implemented soon.
The DAKI (Drop, Add, Keep, and Improve) idea focuses on what we can improve and what more we can do to make the work more interesting. It is also a great data-gathering method that fosters thinking around practices and the value the team gets from those practices.
WWW (not World Wide Web!)
WWW means it worked, kind of worked, and didn't work at all. As the words suggest, the team is focused on the items that worked well for them in the last sprint, and on items that worked but still need a few tweaks in the next sprint. Also, the team focuses on items that didn't work well or couldn't be implemented in this sprint but could be improved or implemented in upcoming sprints.
You can use this retrospective when the sprint has undergone many challenges with respect to processes and people. It focuses on improvement. I used this at a time when our sprint had undergone challenges from new people coming in and new processes that were introduced.
The "starfish" board or poster is split into five quadrants, and team members add their thoughts to each. We chose the following quadrants:
3H (Helped, Hindered, Hypotheses)
A traditional approach called by any other name would be this retrospective. As the name clearly suggests, Helped
look into things that went well versus those that were blockers.
are implementable suggestions that team members make. The top two suggestions can be tried out in the next sprint.
This retrospective focuses on the positives and the gaps that the team has between the current situation and the continuous improvement it's striving for.
Hopes and Concerns
The team talks about the hopes that they have for the next sprint. They also cover the concerns they have for the current sprint.
This retrospective is close to the traditional one; the only difference is that we conducted it by using the online tool Pointing Poker
. This is a great place to collaborate if you have distributed Scrum teams.
As a facilitator, you create a session and then invite others to join. The tool has three different sections: start doing, stop doing, and continue doing. When everyone on the team is done, we read through every comment.
Easy to conduct.
There are many more types of retrospectives, too many to fully describe here, such as:
- I Like, I Wish, What If?
- SaMoLe ( Same as, More of, Less of)
- Retrospect the Retrospective