Which actions could be done in the Retros (- or, how could I guide the Retro) to turn the ceremony more attractive to the Dev Team?
Lately we've been just collecting what should be improved + what went well in the previous sprints, and this seems to easily turn the ceremony boring.

Would you have inputs on what could be done to turn this moment into something that could make the team more open/focused to give deeper/better inputs?


7 Answers 7


Indeed Retromat is very inspirational for spicing up the Retrospectives for your developers. But at some point I faced the same issue of minor effectiveness in my team -after one year of working together, after 20 retros .. - so I started as well to think about some solutions to get higher again the attention level.

Discussion was going not really somewhere so I thought to point out a Retrospective Topic.

Now I prepare the team, before the Retro, with a couple of Topics to discuss, maybe some issues we had, or some improvements that I see that are needed, but also the team can come up with topics. Plus I also leave the total freedom to improvise topics directly during Retro. That helped a lot to give new energies to the people.


I'd look at the 5-stage retrospective approach. Retromat provides a lot of different activities that you can use for each stage. Also, there should be experimental changes (usually limited to 1 or 2) that come out of the retro with a clear idea of what should improve. These should also be reviewed at the beginning of the next retro. As long as they are seeing valuable improvement coming out of the meeting, you should be fine.


Here are few suggestions, which you can bring together or one-by-one.

SUGGESTION 1: Bring awarding best team member of the sprint in your Retro:

  • Ask the team to vote during Retro
  • Collect vote in room by raising hands
  • Use vote box to vote for best developer / tester of the Sprint
  • Before Retro, run a survey to collect
  • Instead of asking for a single rating from each team-member, go with ranking approach. Ask team to rank for everyone's choices as 1.2.3 and mark them with values 5, 3, 1 respectively. Use sum of values of all team members to determine The Developer of the Sprint.

SUGGESTION 2: Things that were identified in previous Retros (whether practices or procedures), try to gauge their improvement paths - Identify maturity level on a scale of 5 and make team to discuss it.

  • This helps to know what they discussed earlier (as a refresher), as well as if they are sticking to it.

SUGGESTION 3: Identify wastes in the previous Sprint - This helps to understand why something is not necessary and make the Team to qualify it.

SUGGESTION 4: Discuss Customer Satisfaction Index/Factor from previous deliverables.

SUGGESTION 5: Bring innovation - Any change to an existing approach - Determine if there any new way of trying to do something, and implement them - Brainstorm.

SUGGESTION 6: Every 3-4 Sprints, show a 5 minute demo of the product before the 3-4 Sprints' and show the current one. (Maybe record a video of the product every Sprint-end). This actually gives great motivation to the Team as, with the speed in which things are delivered, people get less time to look at the path traveled.


The first step is to talk to the team. This is their time to reflect and improve. It's also an opportunity to look toward the future to find opportunities for change (and hopefully improvement). Make sure that the team understands the purpose and value of having this time, and see how they would like to use it.

Instead of just looking at things that went well and things that didn't go well, you can look at different types of retrospectives. When I facilitate a retrospective, I set aside about an hour. For the first 15-20 minutes, we go over past successes, pain points, and any other thoughts or comments. The last 40-45 minutes is more wide open, and may have a number of different activities.

Instead of just looking at a historical focus (what went well or poorly in the past Sprint), you can look at the future and identify some changes that the team feels comfortable making and introducing something new, or focus on one particular problem or success and try to fully understand it to either avoid or repeat it in the future, or invest the time to learn something new that can help the team's performance in upcoming Sprints.


Which actions could be done in the Retros (- or, how could I guide the Retro) to turn the ceremony more attractive to the Dev Team?

Here are some ideas you can try out:

  • Search online for fun retrospective ideas and pick up things from there
  • Play a game
  • Go to an escape room
  • Go bowling and have some beverages
  • Ask the team what is not attractive to them and stop doing that
  • Keep the retrospective outside, for example in a park
  • Don't even mention "improvement" during the discussion, only focus on what went well and what you want to keep on doing (better/more)
  • Ask people to write their ideas on a whiteboard, so they are not just sitting around
  • Ask the team to draw a road, which describes the Sprint journey from start to finish

Would you have inputs on what could be done to turn this moment into something that could make the team more open/focused to give deeper/better inputs?

One way to approach this is to ask better/deeper questions from them. Instead of "what would you like to improve", one could ask "what causes the most pain". Ask them what is the bottleneck in the current system (from receiving a feature request, for example, until it's used in production). Once they have cast their opinions, ask how you could find it out together and let them figure out how the metrics will be gathered. Ask them what's the most important thing they learned during the Sprint (not only at work) and request them explain it to the team. Draw some smileys on a whiteboard (e.g. sad, uninterested, and jolly faces) and first ask everyone to put their feeling of the Sprint there. When that's done, ask them how we could get more faces to the wide smiling direction.


The first question you and the team should ask, "What's the purpose of the Retrospective?" In Scrum, every event has a purpose. If there is no purpose, the event would turn into another boring meeting.

Retrospective need not be fun and surely need not be boring. In general, following are the stages of a Retrospective

  1. Set the stage
  2. Collect the data
  3. Develop an insight
  4. Evolve a plan

From the Scrum Guide,

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.

I recommend for the Scrum Master to read through the Agile Retrospectives Book


Simply, all what you needed to have is the actions to be done.

If you do not have actions associated with time then there is no need to have the retrospective.

Do not forget the time to be bound with the actions and the team members responsible for these actions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.