How to ensure you end your retrospectives with something valuable.

I used to hate Sprint retrospectives. I didn’t understand why we had to sit down every second week to discuss the same things. The Scrum Master would religiously ask us the same boring questions, and I wanted to be anywhere but in that room. 

Almost all of our Sprints ended the same way: We had Sprint carry-overs and someone complaining about bugs, yet we knew our next Sprint would be no different, with pressure to deliver more, failure to deliver on expectations, and bugs caused due to rushing everything.

What did we do wrong?

Let me share my learnings from bad Sprint retrospectives. Hopefully, you won’t do what I did :) 

By the end of this post, you will learn how to do it in a valuable way and consistently improve your team’s work.

Bad Sprint Retrospectives

Before we talk about bad experiences, we need to understand why doing Sprint retrospectives matters in the first place. I could point you to the Scrum Guide, but I guess you’re tired of it. So let me give you my fifty cents.

For me, Sprint retrospectives exist to help teams improve their work and strengthen their collaboration. It’s a moment to step back from a busy routine and reflect on opportunities to grow as a team. 

Great Sprint retrospectives can significantly transform teams for the better.

A bad Sprint retrospective won’t contribute to what I just mentioned. I see bad ones as time wasters: You enter the room with empty hands and leave the same way. Probably you leave even feeling helpless and powerless.

To illustrate a bad Sprint retrospective, let me walk you through the example I started this post:

1. The Scrum Master would write two questions on the board and ask everyone to answer them: “What did we do well last Sprint?” and “What could we have done better?”
2. The team would take five minutes to gather thoughts
3. Everyone would share their perspective
4. After that, the Scrum Master would go to the board and write two other questions. What are the opportunities for the next Sprint? Which risks do we see ahead of us?
5. Again, everyone would take five minutes to reflect before sharing
6. Everyone would share their perspective
7. The Scrum Master would ask us what we could do to have a better Sprint.
8. We’d discuss abstractly and end up just talking without any clear actions

All of our Sprint retrospectives were alike. Sometimes the Scrum Master changed the questions or used a dynamic like Sailboat retrospective or something else. Yet, we only talked and committed to no action. We may have learned something and slightly improved, but we never agreed on any action as a team.

Bad Sprint retrospectives end without any explicit action on how to become a better team.

I hated our Sprint retrospectives because I got tired of complaining and taking no action. We fell victim to the circumstances and made ourselves powerless.

Good Sprint Retrospectives

Unlike bad Sprint retrospectives, good ones end up with clear action items. The Scrum Team knows where to improve and commits to actions that enable desired change.

I won’t lie. It took years before I ended up in a good Sprint retrospective. I remember the day when a new Scrum Master came in and asked, “Which actions did you commit during the last Sprint retrospective?” We were embarrassed as we had nothing to say. She looked at us and said, “From today on, Sprint retrospectives start with evaluating actions and finish with committing to new ones.” Everyone got curious about it.

That Scrum Master transformed our team. Looking back it seems obvious to me, but I was clueless about our mistakes. 

The change was simple. We had to agree on a maximum of three actions and commit to it during the upcoming Sprint. That gave meaning to our Sprint retrospectives. Step by step, we evolved as a team, and I understood I used to hate Sprint retrospectives because until then, I had only experienced bad ones.

Setting Valuable Action Items

Defining action items sounds straightforward, but it’s not. I must warn you. It’s easy to set fluffy actions that are easily ignored. You need to be careful about how you craft actions. Otherwise, no one on your team will care about them.

I noticed that teams tend to leave actions abstract or shoot for behavioral change. Let me give you some bad examples:

• We will make our test coverage better
• Whenever a stakeholder interrupts a developer, the Scrum Master will intervene
• We will make our code reviews faster to avoid bottlenecks 

What’s the problem with these actions? They are not measurable. Avoid words that people can interpret differently, e.g., faster, better. Another problem is with conditionals, “If something happens, then we do that.” How do you know if the team got better? You don’t. 

Let me rephrase the same actions in a measurable way:

• Improve the test coverage from 75% to 80%
• The Scrum Master will give feedback to stakeholders A, B, and C about interrupting the team
• Limit code-review time to a day

When you define measurable action items, you gain clarity on whether you reached your goal. Move away as much as possible from imprecise and conditional actions.

To facilitate how you craft actions, you can use the SMART Method. Ensure that your actions are: Specific, Measurable, Assignable, Realistic, and Time-bound. If your action breaks one of these traits, it’s a sign you should hone it.

“Getting feasible actions out of a retrospective and getting them done helps teams to learn and improve.” ― Ben Linders, Getting Value out of Agile Retrospectives — A Toolbox of Retrospective Exercises

Taking Actions Serious

A common mistake with actions is leaving them open. It’s too naïve to expect someone from a busy team will voluntarily drive an action just because the team agreed on a Sprint retrospective.

The more open you leave actions, the less you get done.

My tactic is simple:

1. Define one person to drive the action
2. Insert the action into the Sprint Backlog
3. Evaluate the status of the actions at the beginning of each Sprint retrospective (To do, In-progress, Done)
4. Encourage team members to call others out when actions are not taken seriously

When I worked in the office, I made the action items visible to our whole Scrum team. Everyone would see what we committed to, and the action responsible would ensure progress. Now we live in different times. I like the idea of keeping it simple. Put in the Sprint Backlog and navigate as part of your Daily Scrum.

You don’t need to overwhelm your teams with actions. Two or three actions done per Sprint will help the team grow exponentially within time. 

“With Agile retrospectives, the team drives their own actions!” ― Ben Linders, Getting Value out of Agile Retrospectives — A Toolbox of Retrospective Exercises

Using Action Items in GoRetro

For teams using a tool to run their retrospective meetings, I recommend ensuring a good action items mechanism. In GoRetro, a simple yet comprehensive mechanism enables the Scrum team to easily define action items and link them to a specific discussion/comment from the Sprint retrospective (to keep the context of the action). Action Items from previous Sprints are visible to the team in each retrospective session until they are done, which helps the team track and ensure things get done.

Final Thoughts

I used to be the first to find excuses to skip Sprint retrospectives. They were just not my cup of tea, and I wanted to get more work done. I missed the point. 

Without stepping back from our busy routine to reflect, we cannot evolve as a team.

Today, Sprint retrospectives are non-negotiable to me. Take it seriously, and do not skip sessions to get more work done. Taking the time to grow as a team and getting better results will be a side effect. I’m glad I could experience the impact good Sprint retrospectives bring to teams.