A small Format that can help you to get better Retro Improvements.

Team “Rocket” Retrospective — 10:30

Ash is the scrum master of this team, and as expected from him, he brought cookies and soft drink to this meeting. He is getting a bit nervous as he starts to realize that he will not be able to hold his timebox again, but at the same time, he doesn’t want to interrupt the deep discussion that Misty, the team’s PO, and Pierre, their senior developer, are currently having. It goes a bit off topic, but it seems that Pierre has a lot to say and that he is letting a lot of steam out. Misty is taking his point into consideration, which means that they collaboration could get better from now on.

After having extended the time dedicated to this exercise by another ten minutes, he finally gathers his courage and push the team to get to the next step… Now the team is finally getting to the last part of the retrospective and it is time to define action items. It should be quite easy now that the team discussed the topic through and through.

Ash is repeating the definition of SMART and the importance of having actionable improvements that can be tackled during the next sprint: “Incremental and Iterative improvements to our working environment will help to deliver the highest customer value possible, and that’s good, right?”

Ten minutes later, the team members are showing the action items that they identified:

As usual, Ash is disappointed, and the Team is frustrated. Each of these points are neither Specific, Measurable, Achievable, Reasonable nor Time Bound … and even worst, they are almost the same that last retro’s action items. They are creeping since months in our improvement backlog and even though we are tracking their status carefully, no one seems to take care of getting them tackled once and for all. Maybe next sprint we’ll be better.

Sounds familiar?

It does to me.

I am certain that every Scrum Master already experienced a similar situation and a similar frustration. The terrible realization that the Sprint Retrospective was only used to discuss a couple of topics again and again, and that no meaningful improvements were defined and agreed upon.

Surely the discussions were very interesting and hopefully the team managed to empty their bag in order to start the next Sprint with a better feeling … but was it helpful? Maybe it was, but that is not the point of a Sprint Retrospective — and not having a plan for improvement to be put in place during the next Sprint is a recurring and deadly anti-pattern.

Credits: Zombie Scrum (Art by Thea Schukken. Created for The Liberators)

What is happening then?

The most important learning that you can extract from this situation, is that the Scrum Team, so including the Scrum Master, has not understood the goal or the importance of the 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.”

The Scrum Guide is actually crystal clear on the topic and put a heavy emphasis on defining improvements to be put in place during the following Sprint. The defined and selected action items must be actionable right away, and they should not be placed into a virtual improvement backlog to be reviewed and assessed regularly.

In my opinion, the Scrum Retrospective is the most misunderstood events in the Scrum Framework and it is often considered like a casual chat with cake and soda, to discuss what we should keep, drop or add. Instead, it should be a critical moment for the Scrum Team to inspect and adapt the way it works and to create a plan on how to improve it. By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that will be implemented in the next Sprint. This cycle repeats sprint after sprint endlessly, and each improvement builds on top of the others.

How to improve the outcome of your Scrum Retrospective?

There is one point above all others that need to be addressed, and it is to ensure that the Scrum Team truly and fully understands what the Scrum Retrospective is. For a Scrum Master, a way to observe this will be the quality of the agreed-upon improvements and whether these improvements were implemented during the following Sprint or not.

In order to support the definition of clear and actionable Sprint Retrospective Improvements, I have slowly developed the following format, and I would now like you to try it over and give me some feedback.

Before the end of next sprint, we + <improvement>

The word “Before” expresses urgency and importance.

The sentence “the end of next sprint” is a clear timebound component.

The word “We” expresses common ownership for the improvement.

The <improvement> should express the desired improved state.

Altogether, this format pushes the Scrum Team to only thinks about the scope of the next improvements, as its timeframe and its owners are already given. By reducing the complexity of the improvements, it should be easier for the Scrum Team to precise what they want to improved. The sense of common ownership should help the Scrum team to defined achievable and reasonable improvements. The actual improvement should not be expressed as an endless process but as a clear and fixed wished state.

By defining the “What” instead of the “How”, the Scrum Team can use its creative power and experiments beyond the initial scope of the improvement.

Before the end of next sprint, we are using this format at the end of our Sprint Retrospective.

I would be extremely thankful if you could give this format a try and if you could share your thoughts and feedback on it. The issues that a Scrum Team is confronted to are complex and always changing, so using different techniques to teach the Team what a Retrospective really should be could prove to be helpful.

I hope if this format can be as helpful for you as it is for me so far.





I’m an Agile Coach that wants to inspire you to seek happiness in your work and your life, by changing the way we do stuff.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Using Petri to simulate cultural interactions with Go

The State of AWS Lambda Supported Languages & Runtimes (Updated November 2019)

Get new podcast episodes faster with Breaker

The Chain of Responsibility pattern is a simple pattern used in object-oriented designs.

A Dive into WSO2 API Manager

How Continuous Delivery (CD) can help us achieve our goals as Software Professionals

A Beginner’s Roadmap to Twilio

Web Workers to the rescue

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Baptiste Grand

Baptiste Grand

I’m an Agile Coach that wants to inspire you to seek happiness in your work and your life, by changing the way we do stuff.

More from Medium

Push 29 to Re-Elect Jack Inacker and 30 to Elect Dave Sunderland

ACC Tournament Preview — Round 2

NAB-Coins Review: Here Are My Two Cents About This Trading Platform

IAT 340 — Modular Synthesis by Kai Hutchful & Justin De Leon