How to animate Scrum retrospectives differently

I have always been a huge fan of continuous improvements guaranteed by the iterative process of the Scrum framework.

In my team, we are applying agile methodologies for a while now, and after several years, we realized that ceremonies were no longer as exciting as in the early days. Due to their regularity, sprint reviews and retrospectives became more and more boring and the once fast growing learning curve of the team was slowly but surely decreasing.

To overcome this problem, I tried to animate our last sprint review and retrospective differently, with the goal to bring freshness and revival to the team and those monotonic ceremonies. Discover below how I manage to do it.


BEFORE : How did my team organize agile ceremonies?

Before to describe deeply what was going wrong, let me summarize in a few bullet points what were the main components of a sprint review and a retrospective within our team.

Sprint review :

Member of the team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.

Sprint retrospective :

Previously, we had two distincts parts during our scrum retrospectives.

  • Team morale measurement (happiness metrics : allow individual retrospection and emphasize the human aspect of software development)
    • Each team member should answer orally to the following questions :
      • Which major emotions did you fell during this sprint ?
      • What felt best?
      • What felt worst?
      • What would increase your satisfaction?


  • Definition of team’s continuous improvement actions :
    • Did our actions from the last cycle worked?
    • What went well during this sprint?
    • What went wrong during this sprint?
    • What could we do differently to improve next time?


AFTER : What we improved in our ceremonies?

“Global assessment : Lassitude and lack of energy during ceremonies.”

It is well known that after a too long period of times, recurrent meetings in general tend to become tedious and sometimes even annoying. In my team, as our sprint length was 3 weeks, this unfortunate truth about boring meetings was mostly applying to my beloved sprint ceremonies.

Sprint review :

During reviews, each developer shows (demo format) what new features or bug fixes were developed during the sprint.

Problem :

Not all stories were showcased in a demo. (Often, developers skipped technical stories that are, for me, essential.)

Demo were performed poorly.

Difficulty for the audience (stakeholders) to understand the context behind a bug fix or other things.


Solution :

We created a template which, in one slide, help developers to easily describe and explain hidden context surrounding their story before starting their demo.

This simple template offers quality and clear separation between each demos. But most of all, it helped developers to be more pedagogue.

sprint review method

Sprint retrospective :

Measuring people moods is a really good habits that we took. It added more humanity to « professional » relationships. We understood more each other. And, from my point of view, being empathetic is also a true quality of a good manager in general.


Problem 1 :

Over years, new members didn’t systematically had enough confidence to orally express how they felt or what they thought. For example, instead of mentioning the main emotion that first came to their mind, instead of saying “I’m exhausted” or “I’m enthusiastic”, they said “Not bad” or “Fine stories”.

Solution 1 :

To overcome this problem during our latest retrospective, I displayed in fullscreen the Facebook Reactions icons that forces us to think about emotions and feelings instantly. Each one played his part.

facebook reactions

Problem 2 : Our « continuous improvement » ideas were always argued and actions were defined but there was not always an efficient follow-up after the retrospective. Therefore, at the following retrospective, nothing changed since the previous one.

Not to mention that we often kept a written record of the actions/solutions but not always of what the initial problem, resolved by the action was.

After some retrospectives, sometimes, we were unable to remember why we wrote this action in the first place…

Solution 2 : To overcome this issue, we systematically attributed a responsible in charge of the actions with a deadline. And of course, we decided to always summarize the definition of problems that we encountered. We ended up with a four columns report template for actions.


Problem definition/Improving Solution/ Responsible/Date

problem solving



From time to time, it is also good to simply remind everybody why sprint reviews and retrospectives are important and also their definition. The term retrospective is not always obvious and clear for everybody. The notion of continuous improvement is, of course, the most important.

My next article will be about ice breaking methods during meetings. How to animate less boring, collaborative and efficient meetings in general.

As always, I wish you all my best for your digital projects.