How to Run Amazing Scrum Retrospective Agile Meetings… Part 1

What if I told you most retros suck?

I wouldn't be lying. 

And the reason for that is because... damn... just thinking back on all those retros I've been sitting though during the last 10-15 years. Lol!

So yeah. Well, let's just say that some retros are worse than others, right 🙂

This is part one of a mini course about agile scrum retrospective meetings (and agile meetings in general). So if you're into this stuff, please hang around so you don't miss the next parts. Coming up real soon!

Anyway, let's kick off this thing and talk about retrospectives and what they're good for.


Now that is a great goal... only there is a teeny-tiny problem...

Perfection can't be achieved. Big surprise there, right? But if you think about it, perfection is like trying to reach the speed of light. No matter how hard you try, you can't really get there. That's the bad news.....

The good news is that perfection is more like an ongoing process. It's the journey that counts, not the destination. A bit on the cheesy side, but still... true enough.

Get part two of this series here ---->

The same goes for improving stuff: you can’t just improve, and then be done with it. You gotta keep doing it, and never stop. That’s the path to perfection.

Hey dad, I just learned something! I think I'll stop now.

Nope, that's not how we do things.

Or as my uncle once said "Knowledge is easy to carry" (it loses something from the Swedish original "Kunskap är inte tungt att bära"...)

The way to improve is getting feedback. Without feedback, you’re blind. Each time you get some feedback is also a chance to improve how you work. So you want to get feedback as early as possible, as often as possible.

The idea is to get some feedback and then using that feedback to improve how you work. Or, in this case, how your team works.

In other words: you look back at what happened and decide how to change (improve) based on that. 

And that's the whole point of agile scrum retrospective meetings!

Alriiiiight... That's not actually the point of retros.

The goals is to the goal is to make your team more productive....... to get more work done in less time. You want to produce stuff faster (and earn more money). And that's the point of retros. Feedback and learning are just how you get there.

The scrum retrospective meeting is probably the most important part of any improvement process. In fact, if you're bold enough, you can even begin your process without any rules whatsoever... except one: run a retro each week. 

The retrospective meeting is the most important part of any improvement process.

Click to Tweet

The retro meeting is also an opportunity for the team to set aside some time to reflect on their work.Aand to take small, incremental steps forward.

So... you’re looking for things to improve. And what you end up with at the end of the meeting is, well, a list of improvements! (I'll call them actions from now on). Simple enough.

One important thing to keep in mind, is that all actions are owned by the team members. The team looks at what happened, finds the actions, and then the TEAM implement them. This is much more effective than forcing change down from above.

Speaking of forcing change…

The idea with retros is to find problems and then turning them into valuable improvements. This essentially means that the team adapts how they work.

Now, it’s crucial that your team are allowed to do that (change how they work). I can’t stress that enough: The team MUST BE ALLOWED TO CHANGE.

"Sure, do whatever you want.... as long as you follow our process in detail"

I know from experience that many organisations allow its teams to ”play agile” and even encourage them to run retros. But when push comes to shove, teams aren’t really allowed to make any real changes... 

It usually goes like this:​

There is a certain blessed document (”The Development Process”) detailing how teams should work. Or maybe there is a process police patrolling running around, lecturing teams what’s best for them. (It's no joke! I've seen it!)

What happens next is that the organisation tells the team:

We want you to be agile…”, while simultaneously holding them back, saying ”… as long as you follow our extremely detailed development process”. 

This is a recipe for disaster. At best, it causes confusion and waste. At worst, it brings distrust, conflicts and apathy in the team. Don't go there. Instead, make absolutely sure your team is allowed to organize how they work.

When Should You Hold the Meeting?

You hold this meeting regularly. Usually at the end of each week, month or sprint. You can also hold it at the end of a project, or when you do a release, or when you need it.

Mark it in your calendar. It doesn't have to be thursdays though...

Best is if you run them using fixed intervals. Say, every other Thursday. This creates a natural improvement pace and helps it becoming an integral part of the development cycle.

The Scrum guide (if you’re into that) says you should run retros at the end of each sprint. And I think that’s a great suggestion!

But then, again, remember, retrospectives are not just for Scrum or even for development teams: you can use retros in any organisation or setting.

Who Should You Invite to the meeting?

Well, the entire team of course!

For a developer shop, that means all developers + the product manager and, of course, yourself, the facilitator.

You shouldn’t invite any observers (like your manager). Doing that will make the meeting a bit awkward. Having to think of what you say when your manager is hovering about will certainly hold back discussions…

How Long Should the Meeting Be?

It really depends on when you last ran it, but one to two hours per week is a good rule. So a meeting for a two-week sprint should be between two and four hours. That’s not a hard rule, but you should use at least an hour each time.

It’s better to hold short meetings more often, rather than long meetings more rarely. The reason for that is -- you guessed it! -- getting feedback quickly! After a month or so, no one will even remember what they did four weeks ago.


  • ​Perfection is the goal, but the journey is what counts
  • Retrospectives are owned by the team
  • Teams must be allowed to change how they work
  • Use retros to get feedback from the sprint
  • Feedback is turned into solutions (actions) to be implemented next
  • Keep running them... at regular intervals
  • Invite the entire team (avoid observers)
  • Spend one/two hours per week, but at least one hour

To get the most out this meeting, you need to know how to keep it on track, how to keep it energised and to make sure the team actually gets something out of it. Not to mention, you need to learn how to manage the group so everyone gets heard and much more.

You’ll get into all those details in the next part (and more!).

In the next part (part two) of this series, you'll learn a super effective retrospective recipe. This framework is a tried and tested method (in five steps) for running these meetings. I'll show you, step by step, all the way from kicking off the meeting and how to wrap it up properly. So don't miss this!


Learn the secrets to Agile Scrum Retrospectives!

About the Author Martin Wickman

I'm a developer, running my consulting business while raising two daughters. The little one is 9 months and the big one four years. Yikes, time flies! Wish I had more time to spend with them.

follow me on: